The biggest problem with token passing systems is the cost of losing the token (machine holding it crashes) or failing to yield (when you then have a pope-antipope situation).
Ethernet has an immediately worse system (everybody has to do the backoff, and on a crowded network that can be painful) but on an amortized bases not-as-bad system. Also adding more hosts is pretty much automatic. Consider it a positive example of the "worse is better" paradigm.
> But Ethernet worked around that problem pretty quickly with switches. I'm sure Token Ring would have solved it the same way.
Perhaps, but "the problem" was shared access to a single piece of wire. Switches solved the problem by ending sharing - each piece of wire had exactly one computer.
So sure, a switch would have fixed Token Ring's lost token problem - by eliminating the token. I'm not sure it could be called "Token Ring" at that point as there is no token, and no ring.
Back in typing/HyperCard programming class in the mid 1990s, one of my friends jammed the Mac lab's AppleTalk network. He told me he did it by taking his computer off the network at the moment he held the AppleTalk token.
He didn't seem to be lying... he did something using mouse/keyboard on his machine and my machine couldn't use the network, and then after a couple kids complained about the network being down, he discretely did something on his machine and things were fixed.
I was always confused as to how he was fast enough or even that his computer having the token was user-visible without installing specialist tools on the school's computers. If he were to start a large file transfer, would that cause him to hold the AppleTalk token for a long time, and give him visibility via the progress bar?
I thought there was sub-second upper bound on how long the token would be held, even if your machine still had data to send. Am I mistaken about AppleTalk token ring networking?
This reminds me of anecdotes I’ve heard whereby MacOS’ lack of preemptive multitasking led to the situation whereby if somebody were to open and hold the apple menu on their machine it would receive but not yield the token (because network processing was essentially suspended while it followed the user’s every action with the GUI of that menu).
I think HyperCard and AppleScript were the only programming environments installed on those machines, and he was a big PC proponent, so I don't think he had a Mac at home. I don't think he used any specialized tools, and I don't think he was using AppleScript to bit-bang binaries into the network driver's region of memory.
That does remind me of a story I heard, that the zero page was mapped, and the first 64 bits of the zero page were initialized to zero at startup. So, if you derefernced or duble-dereferenced NULL as an *int, *float, *double, **int, **float, **double, etc., there would be no error and you'd get 0 or 0.0. Apparently, the Excel port for Macs had quite a few NULL double-dereferences, either intentionally taking advantage of this "feature" or by accident. Many developers installed a system extension that would set the first 32 bits of memory to a value larger than the amount of installed memory, guaranteeing an error if NULL were double-dereferenced.*
In the article I originally mentioned "worse is better" regarding Ethernet, but I figured it was too much of a tangent and deleted it. So it's interesting to see you mention it too. Maybe I should have left it in :-)
For the article itself, probably it is tangential and thus you were correct to excise it. I was commenting on a claim about IBM (hardly the only token passing network) which was itself tangential to the arrival topic.
Ethernet has an immediately worse system (everybody has to do the backoff, and on a crowded network that can be painful) but on an amortized bases not-as-bad system. Also adding more hosts is pretty much automatic. Consider it a positive example of the "worse is better" paradigm.