| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Rich – I’d be interested in your data, as it seems quite relevant. I think we may benefit from 1 more significant figure if we are going down to per meter numbers. I’ve been looking into the history of the delay spec, and my fingerprints seem to be on the genesis of it, simply for filing a comment on the initial WG ballot of 802.3bp (1000BASE-T1) asking them to put in
a specification on the maximum link segment delay. (not saying what it was). The group responded with 94 ns for 15m. The number seems to have been based (based on recollection at the time and a little looking at the contributions) thoughts that .3bp might use UTP cabling derived from
cat6a designs + ~10% margin for automotive environmental considerations. (note that the base spec for cat6a already has margin built into it… but that’s not my point here) Whatever the reason, that number has stuck ever since, got carried into .3ch without a thought (even though measurements showed it was overkill , likely because there was still thinking of at least 2.5G using
UTP cabling based on the 1000BASE-T1 spec), and we carried it over into .3cy D2.0, and just scaled it by 11/15 in D2.1. The question is, are the underlying assumptions good? Probably not. As far as I can tell and remember, they are not. The cabling constructions
we have been considering for our application are quite different from UTP based on Cat6a with 600 MHz bandwidth. With multi-GHz bandwidths needed, the data I’ve seen all point towards less-tightly-twisted, shielded cabling designs – parallel or barely-twisted cabling. The noise levels needed drive us towards well-shielded
designs at the longer reaches. So, the UTP cat6a model, if it ever was an issue, seems to be out of the question. Dielectrics and twist pitch will be different, and both impact prop delay significantly. Let’s get a spec based on real data, and I agree with what I think you are suggesting, that we build in a little margin for good measure. It sounds like the worst case you’ve seen would be 50.6 ns. The difference
between 55 and 50.6 is still almost 9%. Question for you and the cabling folk is whether it’s reasonable to put 9% on top of the worst cable you’ve seen to date. If so, I’d say going with 55 might be reasonable, but I’m concerned that we haven’t included
loading from inliners at all – let’s not cut it too close, as that would be fatal – but I think we agree, 69 is definitely too big. I’d be interested in your data to help us set a good spec. Not quite sure what the right number is yet. -george From: Boyer, Rich <000012e205f410df-dmarc-request@xxxxxxxxxxxxxxxxx>
Hello All, For the propagation delay, the measurements I have made to date result in ~4.6 ns/m maximum. That maximum accounts for ~100 ps/m of uncertainty. The measurements were performed on all samples
at temperatures of -40 °C, +23 °C, and +105 °C. Note, I have only had limited sample sizes from limited number of cable suppliers.
I would feel comfortable with changing 69 ns to 55 ns for the maximum propagation delay. This will allow for the maximum of 11 meter link segments as defined in IEEE 802.3cy. I would not be comfortable with any value less than 55 ns for maximum propagation delay for the IEEE 802.3cy link. I am open to discuss in more detail if needed.
Bye, - Rich Boyer From: Hossein Sedarat <000008c7cb0e9f44-dmarc-request@xxxxxxxxxxxxxxxxx>
Dear 802. 3cy colleagues, I am considering proposing a smaller limit on the maximum propagation delay of the channel. With this email, I outline my motivation and
justification for this new limit and seek your opinion on this change.
ZjQcmQRYFpfptBannerStart ZjQcmQRYFpfptBannerEnd Dear 802.3cy colleagues, I am considering proposing a smaller limit on the maximum propagation delay of the channel. With this email, I outline my motivation and justification for this new limit and seek your opinion
on this change. Motivation: A maximum on propagation delay also provides a limit on the round trip delay of the echo signal. This, in turn, provides a limit on the length of echo pulse response and the span of the echo
canceller. A reduction in maximum propagation delay is beneficial as it results in reduced complexity of the echo canceller. Justification: The limit on maximum propagation delay was updated to 69 ns in the last review cycle. Since then, I have looked into a relatively large number of cable measurements and calculated the propagation
delay. These measurements are from a diverse set of link-segments: - a variety of cable lengths from very short to very long - different segment lengths and various number of connectors - cold/room/hot temperatures - different cable manufacturers - both 802.3ch and 802.3cy-grade cable types My observation from this data set is that the propagation delay never exceeds 4.4 ns/m, and never exceeds 48 ns for all 11 m cable assemblies. Proposal: Given this, I think a limit of
55 ns for maximum propagation delay should be a reasonable number. It provides roughly 15% headroom and margin with respect to my data set. It also results in 20% reduction with respect to the current number in the draft which is a significant reduction
in echo canceller span. I have already contacted some of our colleagues representing cable and connector manufacturing. So far, I have not heard anybody objecting to this proposed number. I would like
to open up this proposal to everybody in the group to check if there is any objection to this proposal. Look forward to hearing your opinion on this matter. Regards, -Hossein To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 |