Re: [8023-POEP] Baseline Bucket ad hoc
Hi Yair,
I think we are in alignment on the fundamental point as we both agree that
whatever approach is taken it has to be based on a worst case analysis.
Best regards,
David
"Darshan, Yair" <YDarshan@microsemi.com> wrote on 10/01/2008 17:56:15:
> 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]