Steve & all –
I agree with TJ that connectors need to be considered. Usually they aren’t much, because usually we work with long links when we have 4 connector channels. Even as I’ve said before, it generally isn’t good practice to trim the link
segment delay spec too tightly,in those cases, a nanosecond or two for a connector isn’t a big deal, because you’re dealing with hundreds of nanoseconds - and, as such, the connectors don’t matter much. Further, other 802 standards often rely on these specifications
being controlled for cabling (cable + connectors) channel delay, which itself is often margined…
Looking into this, I don’t think simple measurements of a few samples or datasheets are going to do it for us. We need expertise from those who actually work with product. I’ve been finding is the NVP (net velocity of propagation) in
data sheets is usually a typical value, and can be lower or higher, particularly it can vary at least the peak-to-peak variation of impedance variation (so +/- 5% impedance means a 10% possible deviation from the NVP), unless the correlation of L and C in
the cable model terms are controlled to vary together – which isn’t guaranteed. At this point I, a PHY guy who spends a lot of time with media guys, have gone about as far out on a limb as I ought to.
One point of guidance - I think we need cabling experts to chime in, and then make sure we allow the broadest set of cables we think may be used. This parameter can not only constrain the types of constructions used, but also whether and
how an implementer using the standard can reach the corner case of a longer-reach system. We’ve got to give extra attention to what we are cutting out of the application space. I’m particularly sensitive to this, as some of you know that there is a bunch
of work going on right now in the LAN cabling area about ‘extended reach’ cabling. Such stuff makes for complex usage models which sometimes work – but sometimes don’t. Based on history of people always looking beyond for more applications, I caution – MARGIN
MATTERS.
Now, before I get all those emails about “but our objectives say…”, I’ll add that while it is nice to think about ‘the bulk of the market’ in setting our objectives, constraining this parameter to tightly fit our objectives creates problems
for the minority of use cases that end up inhibiting the success of the whole technology in the market. We all know how a small unreached niche can create openings for alternative solutions – and then the one that fits the most of those niches ends up winning.
If we don’t NEED to create a hole, we shouldn’t.
I look forward to hearing from cabling experts on the aged & configured propagation delay of full harnesses.
-george
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
310-920-3860
From: Steven Gorshe <0000115ee8839ca6-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, May 2, 2025 11:46 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Link Propagation Delay
Hi TJ,
Thanks for your good follow-up comments and questions.
I will need to consult with George and others regarding the delay contribution from connectors since none of the other IEEE 802.3 clauses that specify a maximum link segment delay mention them.
Regarding alternative cable types:
- As noted in my contribution, the TF needs input regarding which types of twisted pairs should be considered. The velocity factor among those specified
in other 802.3 clauses ranges between 0.532 and 0.611. Since Scott and I have been focused on coaxial cable, I would defer to others regarding the proper choices of twisted pair cables to consider.
- For alternative coax cables, my investigation when preparing the contribution indicated that all the alternatives had a faster velocity factor of at
least the 0.66 of CX31 and CX174, with several types being >0.8. That’s why I was comfortable recommending 76 ns for the cable delay. Per my concluding bullets, I welcome input from cable experts regarding how much delay overhead should be added.
Thanks, and best regards,
Steve
Steve Gorshe, Ph.D., IEEE Life Fellow
Associate Fellow-Architecture
---------------------------------------------------------------------
Microchip Technology
MS-1F
21015 SE Stark Street
Gresham, OR 97030
+1 503 669 6171
From: TJ Houck <thouck@xxxxxxxxxxx>
Sent: Friday, May 2, 2025 8:25 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Link Propagation Delay
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Steve,
Thanks for the presentation yesterday—it was very informative.
I have a follow-up question regarding the 76 ns propagation delay proposal. You referenced CX31 and CX174 as example cable types, assuming a 15-meter length. However, the proposal did not factor in the four inline connectors that have been
referenced in other task force discussions. From past measurements, these can contribute roughly 1–2 ns, which would bring the total closer to 80–84 ns in practice.
Given this, I was curious about your thoughts on:
- Including inline connector delay explicitly in the budget, mainly as most real-world systems include them.
- Allowing room for alternate cable types that may have slightly different velocity factors outside of CX31 and CX174 you referenced.
Best Regards,
TJ Houck
System Architect, Detroit
Mobile: +1-765-426-9832 | thouck@xxxxxxxxxxx
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1