On May 23, 2021, at 5:18 PM, Wayne S <wayne.sudol
at hotmail.com> wrote:
ISTR That the 2 main issues hindering wide spread adoption of TR was cost and and not
knowing where TR development was headed.
The Type 1 cabling needed to each port on the hub was expensive vs thick/thin Ethernet
with taps (as were the hubs). Also, there was no second source for TR chips so everyone
who wanted to make TR hardware was at the mercy of the IBM chip pricing so there weren?t
too many TR cards being manufactured by anyone other than IBM. I recall the Madge TR cards
for IBM ps/2 machines being about $400 ea circa 1992.
So you had a lot of cost standing in the way if you were thinking about going/staying
with TR and had hundreds of workstations.
There was also the bogus addressing and strange bridging.
As for development, there was an ethernet roadmap (
don?t remember the group that put it together) stating that 100 mbit was next running over
shielded twisted pair then unshielded tp. And 1000 mbit was possible.
For TR, No one knew if IBM would up the speed past 16 mb and allow TR chips to be made
cheaply.
Also the fact that token passing is inherently slower than CSMA/CD did not help to sell
TR.
The analogy was that if you had a long street with many stop lights, using TR would be
like having every light be red and having to stop at each light, where using Ethernet some
of the lights would be green and no stop required.
IBM tried to use that to their advantage and use to say since the amount of time it takes
to token pass could be measured precisely that the network response as a whole could be
determined and capacity planning was more deterministic using TR than Ethernet.
While at DEC in the network architecture group I contributed to a DEC marketing document
that was a detailed point by point reply to an IBM document. IBM tried to claim TR was
superior, we demolished that in detail. The deterministic argument was in there;
unfortunately for IBM it is true that the network is deterministic -- has an upper bound
on transmit latency -- but that upper bound is so crazy large that the property has no
practical value whatsoever. BTW, this is where FDDI is vastly better, since it uses 802.4
timed token protocol rather than 802.5 token passing.
paul