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]