| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Yair,
At the last meeting you mentioned that you had tested
100BASE-T with inline power on the data pairs and found no problems. During an
offline discussion, we discussed performing testing with maximum length cables
and the "Killer Packet" to ensure that your testing did not miss the impact of
baseline wander on your testing. To assist, I sent you a copy of the Killer
Packet (zipped binary) to enhance your testing.
Have you had an opportunity to evaluate the impact of
inserting power into the data pairs using the Killer Packet since our discussion
and do you plan to present on this?
I think it would be important to ensure that we fully
characterize the exposure of inserting any additional low-frequency poles into
the channel on 100BASE-T signal impairments.
Thanks, Dan From: owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Darshan, Yair Sent: Monday, January 07, 2008 1:37 AM To: STDS-802-3-POEP@LISTSERV.IEEE.ORG Subject: Re: [8023-POEP] Baseline Bucket ad hoc Hi
Matt, Probably you didn’t see
my email which I ask not to have meetings on Friday. Friday and Saturday are a
non working days here like Saturday and Sunday' in Any way, please find
below my comments/opinion regarding the base line bucket:
Comment
#141: Comment #141 deals with
" The commenter state
that this column has no value and I disagree with
him. This column has value
in which it specifies the range of maximum for better power
management. It is true that when
you are using L2 you may not need this information however when using only L1,
this information has value. Regarding the argument
that it confuses the average reader with the minimum power required to keep the
port ON, I don’t see how it confused since the text is clear and if it still
confuse we can add clarification but it is not justifying changing the level of
information contained in this column. I suggest rejecting
this comment or ad clarification for the use of it in respect to
33.3.6. Comment
#124: The commenter is basing
his argument on the following assumptions:
The change
it or modify it we need to td feasibility and economical tests/simulations. Non
of it has been shown or demonstrated.
Rational: The
current specification required to meet Rpd_d together with Cpd_d<0.15UF. This
is possible and proven feasible. Requiring
meeting Rpd_d with Cpd_d>>0.15UF is technically problematic due to long
time constants and false positive detection risks. There is a way to overcome
this problem by using ac signals with source and sink capabilities however it
requires technical and economical feasibility tests which if somebody present
such it will be easier to consider and asses its technical and economical
aspects.
I suggest
rejecting this comment unless serious technical work will be presented to backup
the changes suggested. Comment
#13: This
comment is similar in principle to comment #124. Figures
33-8 and 33-9 are not mandating implementations. It
guarantees interoperability. Figure 33-8:
Figure 33-9:
The implementer can use any Thevenin equivalent of figures 33-8 or 33-9 which
allows the flexibility which we are looking for. In order
to allow such big changes it is requires proving feasibility with different PSEs
using different methods complying to the suggested
remedy……!!! Unless
such proofs made I suggest to reject this comment. Yair
From:
owner-stds-802-3-poep@IEEE.ORG [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of Please find attached
material for discussion during this morning's baseline bucket ad
hoc. On Dec 11, 2007 11:53 AM, Colleagues - |