> On May 23, 2021, at 5:18 PM, Wayne S <[email protected]> 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
