Retro networking / WAN communities

Paul Koning paulkoning at comcast.net
Tue Apr 12 15:35:44 CDT 2022



> On Apr 12, 2022, at 3:45 PM, John-Paul Stewart via cctalk <cctalk at classiccmp.org> wrote:
> 
> 
> On 2022-04-12 09:49, Paul Koning via cctalk wrote:
>> 
>> Does anyone still remember the other 100 Mb Ethernet-like proposal, I
>> think from HP, which added various types of complexity instead of simply
>> being a faster Ethernet?  
> 
> HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry
> Token Ring frames in addition to Ethernet.

Ah, that would certainly be one part of the explanation why it didn't go anywhere.  Supporting Token Ring would add a vast amount of complexity for no real benefit.

I noticed the Wikipedia article has a wrong and misleading description of the supposed "deterministic" behavior of token rings.  It speaks of "consistent performance no matter how large the network became".  That, of course, is nonsense.  What is true is that, in the absence of errors, token rings have a hard upper bound on the time required to transmit the first frame in the NIC transmit queue.  What is always unstated in the marketing documents making that claim is how large that upper bound is.  

I remember an IBM document that spent 30 or so pages saying "token ring good, ethernet bad".  DEC, with some help from 3Com, wrote a detailed paragraph by paragraph refutation of that; I participated in creating that and have a copy somewhere.  One of the points IBM made was that determinism claim.  So we calculated the worst case transmit latency for a max size 802.5 ring.  I don't remember the answer exactly; I'm pretty sure it was over a minute.

FDDI is an entirely different protocol, with dramatically better latency at high load than 802.5.  (Its ancestor is 802.4, not 802.5.)  But even there, the max latency is surprisingly long.  

Ethernet, on the other hand, is nondeterministic (in the half duplex shared bus topology) but except at insanely high loads is much lower than the latency of any token ring.

	paul



More information about the cctech mailing list