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]