Re: [8023-POEP] Baseline Bucket ad hoc
Hi Stephen,
Yes we did. They met the Midspan requirements in clause 33 (802.3af).
In addition they met interoperability tests as well.
For the last years which the Midspans are in the Market we didn't
received (and some other vendors as well as far as I know) reports from
the field that data was infringed due to a presence of a Midspan in the
channel.
From a channel point of view the margins are big enough for 1MHz and up
for a 100BT operation.
For behavior below 1MHz, there is no 802.3 definitions for it or other
standard that I am aware of, however also in this low frequency band, we
didn't received any inputs of bad data due too the effects of BLW.
I guess the reason for it is a mix of very low probability to happen
with adequate design margins and modern compensation techniques.
We are trying now to define channel requirements for frequencies below
1MHz. It is not clear to me yet how much it is important and if really
we have issue that need to be addressed due to a very low probability
for data corruption however it is interesting from engineering point of
view to quantify these issues with numbers and then to decide what to do
with it.
Yair
-----Original Message-----
From: Stephen Sedio [mailto:steve0703@vcweb.org]
Sent: Thursday, January 10, 2008 8:43 PM
To: Darshan, Yair; STDS-802-3-POEP@LISTSERV.IEEE.ORG
Subject: Re: [8023-POEP] Baseline Bucket ad hoc
Yair,
Have you taken your midspan designs through an interoperability test
with a
wide range of equipment?
I would interested in seeing link parameters with, and without, a
midspan in
the link, and with different lengths of CAT5 cable between the switch
and
midspan.
I expect the results would provide some useful data for this discussion.
Enjoy,
Steve Sedio
Foxconn
(760) 751-1645, forwards to cell
----- Original Message -----
From: "Darshan, Yair" <YDarshan@MICROSEMI.COM>
To: <STDS-802-3-POEP@LISTSERV.IEEE.ORG>
Sent: Thursday, January 10, 2008 9:56 AM
Subject: Re: [8023-POEP] Baseline Bucket ad hoc
> Hi David,
>
> In any method that we will take, we will have to define a worst case.
> -Transfer Function method: we will have to find a transfer function
with
> a gain/frequency dependence so any compliant Midspan will have a
minimum
> gain/frequency above the worst case transfer function.
> - Worst case system approach:
> Every component in the system has min/max value. Determine the worst
> case value in each component and connect all components in series will
> give the worst case system
> Example 1: A compliant IEEE802.3 data transformer has to meet 350uH at
> 100KHz for 8Madc. These are minimum requirements therefore the worst
> worst case.
> Example 2: Connectors and Cables has minimum requirements for all RF
> parameters. In our case it is even easier due to the fact that the
> bandwidth is below 1MHz so most of the parasitic elements are out of
the
> equation.
> Example 3: Our standard 802.3af is based on worst case min/max numbers
> otherwise it was not a standard i.e. PSE numbers are min/max while PD
> numbers are max/min and vise versa.
>
> It is not a simple task I admit however I am still looking in parallel
> for alternatives to develop simple pass/fail criteria.
> Transfer function is a good approach (and may be it is the best) but
it
> is not as simple as BER tests. Transfer function tests required unique
> knowledge which may be a source for arguments and debates after
standard
> is done during compliance tests and we need to find a way to make
tests
> simple and clear. Any way it is too early to judge and evaluate the
> concepts prior to have some data. I hope to present some next meeting.
>
> Regarding a worst case receiver and transmitter I meant to use a
> standard equipment such Smartbit w/o compensation techniques or
superior
> transformers. It is possible to design magnetics that meet the minimum
> requirements. The rest is easier since the cables and connectors at
1MHz
> and down is much simpler to derive.
>
> Yair
>
> -----Original Message-----
> From: owner-stds-802-3-poep@ieee.org
> [mailto:owner-stds-802-3-poep@ieee.org] On Behalf Of David Law
> Sent: Thursday, January 10, 2008 7:04 PM
> To: STDS-802-3-POEP@LISTSERV.IEEE.ORG
> Subject: Re: [8023-POEP] Baseline Bucket ad hoc
>
> Hi Yair,
>
> I think the problem with such an approach is that it will requires a
> worse
> case system - a worse case transmitter - a worse case received - and
> worse
> case channel - to confirm that no matter what the system the Midspan
> under
> test will not impact the BER of the link. Finding all these worse case
> components will be real difficult since most components are typical.
As
> an
> example I believe that many 100BASE-T receivers will be able to cope
> with
> more BLW than the older ones - and therefore support a link distance
in
> excess of the minimum required by the standard. Even if you can find
> older
> devices I'm not sure how you establish it is a worse case receiver -
at
> a
> minimum I suspect that would require detailed knowledge of its
> implementation that may not even be available - and even then it may
> well
> be a typical part.
>
> Now a better way to do the above would be to use a set of test
equipment
>
> to produce a worse case waveform - define a model for the worse case
> channel - and a set of specifications for the required output from
this
> mode using the test waveform - regardless if a Midspan was present or
> not.
> I believe this is the same approach as above but without the need to
> find
> worse case examples of components. This however seems somewhat overly
> complex.
>
> Instead I believe a specification that applies just to the Midspan -
> such
> as a transfer function - that can be tested by test equipment is the
> approach that should be used.
>
> Best regards,
> David
>
>
> "Darshan, Yair" <YDarshan@microsemi.com> wrote on 10/01/2008 16:03:56:
>
>> Hi David and all,
>
>> Among the other test method for Midspan ALT A that my team is
> developing
>> now to check the BLW effect, I am checking the following approach
too:
>
>> Step 1: Measure the BER for a standard compliant 100BT system without
>> compensation techniques. (Just what is specified in 802.3 (
>> Step 2: Transmit "killer packets" per Dan's input. Measure the BER
>> again.
>
>> The BER resulted in step 2 is the worst case acceptable BER.
>> If Midspan ALT A is inserted, the BER measured in step 2 shall not
>> exceed the result in step 2.
>
>> Rational:
>
>> In standard compliant system including standard components (Switch
> with
>> 350uH magnetics that meets the requirements + Channel+PD) the system
> is
>> required to operate under the "killer packets" which was described in
>> the past and treated in 802.3.
>
>> Now if a Midspan is inserted, if anything is wrong e.g. lower
> impedance
>> or inductance etc. it will affect the BER worst case number defined
in
>> the REFERENCE compliant channel under the operating conditions if
>> "killer packets"
>
>> Yair
>
>>
>> -----Original Message-----
>> From: owner-stds-802-3-poep@IEEE.ORG
>> [mailto:owner-stds-802-3-poep@IEEE.ORG] On Behalf Of David Law
>> Sent: Thursday, January 10, 2008 3:38 PM
>> To: STDS-802-3-POEP@LISTSERV.IEEE.ORG
>> Subject: Re: [8023-POEP] Baseline Bucket ad hoc
>
>> Hi Yair,
>
>> I agree that the aim with all this is to ensure that inserting a ALT
A
>> Midspan into any 100BASE-T link has no impact on the BER of the link.
> To
>
>> me the question is how to specify this requirement in an
interoperable
>> and
>> testable way. The approach of specifying a transfer function from
1MHz
>> down to TDB Hz was what we came up with when talking about this on
the
>> 350uH call - I guess because there was a belief that reference to
>> cabling
>> standards can be used to provide specification of the ALT A Midspan
>> performance above 1MHz.
>
>> Regards,
>> David
>>
>> owner-stds-802-3-poep@LISTSERV.IEEE.ORG wrote on 10/01/2008 12:24:38:
>
>> > Hi Dan and all,
>
>> >
>> > My team is working on the following action items:
>
>> >
>> > 1. Checking ALT A with the "killer packet" to check the impact of
>> > BLW on the BER.
>> > 2. To generate a Transfer function for a Midspan between TBDHz to
>> > 1MHz.
>
>> >
>> > We started with item 2 and I hope to present data by next meeting.
>
>> > Regarding Item 1 we are designing now the test setup for having
> enough
>> > data for recommending the best course of action.
>
>> >
>> > I would like to have your opinion on the following:
>
>> >
>> > The reason we are checking the behavior of a channel containing ALT
> A
>> > Midspan is because we assume that it will affect the channel
> behavior
>> at
>> > frequencies lower then 1MHz when we suppose to find the BLW
>> frequencies.
>
>> > My question is: If our ultimate goal per the 350uH Ad Hoc is to
> ensure
>> > meeting the minimum BER required so implementation will be
> transparent
>> > i.e. 350uH minimum inductance will be only one way to achieve it
and
>> > other ways are possible, THEN meeting BER means also the effect on
> BER
>> > due too BLW.
>
>> > If this is true, then why we care what is the Midspan transfer
>> function
>> > at this low frequency band. If inserting the Midspan to a compliant
>> > Switch+channel+PD (i.e. a channel designed according 802.3
> guidelines
>> > without compensation techniques etc. such as using 100BT SmartBit
>> > generator and standard channel and load) and the BER test pass
> then
>> > the Midspan is compliant if it fails it is not compliant hence how
> the
>> > Midspan did it we don't care and we don't have to specify anything
>> new.
>
>> > Please let me know your opinion.
>
>> >
>> > Thanks
>
>> >
>> > Yair
>
>> >
>> > ________________________________
>
>> > From: Dove, Dan [mailto:dan.dove@hp.com]
>> > Sent: Wednesday, January 09, 2008 8:00 PM
>> > To: Darshan, Yair; STDS-802-3-POEP@LISTSERV.IEEE.ORG
>> > Subject: RE: [8023-POEP] Baseline Bucket ad hoc
>
>> >
>> > 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 North America.
>
>> > Any way, please find below my comments/opinion regarding the base
> line
>> > bucket:
>
>> >
>> > Comment #141:
>
>> > Comment #141 deals with "Range of Maximum power used by the PD".
>
>> > 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:
>
>> > 1. The existing PD detection section requires specific design
>> > requirements that are not necessary to ensure interoperability:
This
>> is
>> > not accurate statement. All the requirements in the specification
> are
>> a
>> > result of extensive analysis and tests. Each of the requirements
> came
>> to
>> > ensure interoperability.
>
>> > The change it or modify it we need to td feasibility and economical
>> > tests/simulations. Non of it has been shown or demonstrated.
>
>> > 2. Pointing out to presentation made in September 2005: This
>> > presentation was "rejected in principle" by the audience at that
>> meeting
>> > since it failed to accommodate false positive detection due to the
>> time
>> > constant issue. Specifically, the standard recommend to take
>> > measurements after 5tau=1% of steady state in order to reduce the
>> chance
>> > for false positive detection. So this presentation is a good
example
>> for
>> > what we should not do. There are other detection concepts that were
>> > discussed such as capacitor detection, AC coupled diode and other
> and
>> > the resistor concept was chosen as the preferred one which meets
all
>> > objectives at low cost and high reliability.
>> > 3. Figure 33-10 is no the PD model so it is not clear why it is
>> > related to detection issues as stated in the Suggested Remedy.
>> > 4. Requiring PSE to detect values of Rpd_d for all permissible
>> > values of Cpd_d as specified in Table 33-2 is not practical and it
> is
>> > not required by the standard today. It adds unnecessary burden to
> the
>> > implementers with increased time constant problems.
>
>> > 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.
>
>> > 5. To delete the requirement of two point detection it requires to
>> > show that you can detect Rsig with out errors within single
>> measurement.
>> > This is not an implementation issue. It is clear interoperability
>> issue.
>> > If somebody can technically and economically prove that it can be
> done
>> > in other ways he is welcome.
>
>> >
>> > 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:
>
>> > 1. Zsource>45K: Limiting energy backwards to PSE.
>> > 2. Zsource>45K : Preventing 25K signature if two PSEs are connected
>> > together
>> > 3. Vdetect and Zsource>45K allows meeting 30V open loop and 2.8-10V
>> > during valid signature with adequate resolution
>> > 4. D1: Prevents two PSEs connected together in opposite voltage
>> > polarity to generate 25K signature
>> > 5. D1: Prevents two PSEs connected together in opposite voltage
>> > polarity to generate 120V on the port/chips.
>
>> >
>> > Figure 33-9:
>
>> > 6. Zsource not limited, with series diode D2: Limiting energy
>> > backwards to PSE.
>> > 7. D1: Prevents two PSEs connected together in opposite voltage
>> > polarity to generate 25K signature
>> > 8. D1: Prevents two PSEs connected together in opposite voltage
>> > polarity to generate 120V on the port/chips.
>
>> >
>> > 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 D. Matthew
> Landry
>> > Sent: Friday, January 04, 2008 4:16 PM
>> > To: STDS-802-3-POEP@LISTSERV.IEEE.ORG
>> > Subject: Re: [8023-POEP] Baseline Bucket ad hoc
>
>> >
>> > Please find attached material for discussion during this morning's
>> > baseline bucket ad hoc.
>
>> > Note in the meeting notice below, the 11:00AM starting time is
> Central
>> > Standard Time.
>
>> > -matt
>
>> > On Dec 11, 2007 11:53 AM, D. Matthew Landry < dmlandry@ieee.org>
>> wrote:
>
>> > Colleagues -
>
>> > This message is announcing a comment resolution adhoc to discuss
the
>> > remaining comments classified in the baseline bucket. This meeting
>> will
>> > be administered by teleconference. Required materials will be sent
>> prior
>> > to commencement of the meeting. The bucket of comments can be found
> at
>> > the following URL:
>
>> >
>>
>
http://www.ieee802.org/3/at/comments/D1.0/P802d3at_D1p0_postmtg_bucket_b
>> > aseline.pdf
>
>> > Please take some time to review the IEEE-SA PatCom slides prior to
> the
>> > start of the telecon. I will ask if anyone has not reviewed the
> slides
>> > at the beginning of the call. If any attendees indicate that they
> have
>> > not reviewed the slides, time will be made available for such
> review.
>> > The slideset can be found at the following URL:
>
>> > http://standards.ieee.org/board/pat/pat-slideset.pdf
>
>> > The dial-in information is found at the end of this email. If you
> plan
>> > to attend, I ask that you RSVP no later than the day before so
that
> I
>> > can ensure that enough dial-in slots are available.
>
>> > Thank you.
>
>> > - matt
>
>> >
>> > TELECONFERENCE DETAILS
>
>> > Subject:
>> > IEEE 802.3at baseline bucket
>> > Meeting ID:
>> > 802302
>> > Date/time:
>> > 01/04/2008, 11:00 AM (US: Central (CST/CDT))
>> > 01/11/2008, 11:00 AM (US: Central (CST/CDT))
>> > Duration:
>> > 1 hrs 30 minutes
>> > Dial-in:
>> > International: 1.512.532.5999
>> > USA: 1.866.781.8274
>> >
>> > [attachment "C.htm" deleted by David Law/GB/3Com]