Hacker News Reader

Comment by lttlrck | Hacker News Reader

Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof.

I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".

View on HN

The ideas behind token ring underlies DOCIS.

While not technically TR, it does use a token that moves from device to device.

It would be interesting to know if TR is better at contention management than broadcast ethernet - which nobody does anymore because everyone uses switches.

> The ideas behind token ring underlies DOCIS.

> While not technically TR, it does use a token that moves from device to device.

I assume you typo'd DOCSIS there, but no, DOCSIS does not use a token; it uses separate channels for down- & uplink, and the uplink channels are TDMA and/or CDMA depending on DOCSIS version.

Off topic, but clabretro did a series on Token Ring if you want to relive the nostalgia: https://www.youtube.com/@clabretro/videos

There were still using it for the desktops at IBM when I was there in 2001, although they were starting to phase it out.

What i know from the past is for realtime guarantees ethernet does not cut it. So you might be right.

AFAIK Ethernet is used for realtime audio distribution, so that can't be completely correct.

There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.

The usual terminology is hard, firm and soft realtime. In hard realtime, missing a deadline is a total failure and to be avoided at all cost, i.e. your reactor melts down, you car runs over someone, stuff like that. Firm realtime means that a missed deadline will not be a total catastrophic failure but it will make the result useless. E.g. when your printer control system mistimes the "fire ink now" in the printer, and the ink lands not on the page but somewhere else. Soft realtime means that your result will gradually degrade with missed deadlines, but not be totally useless.

Audio is usually soft realtime, sometimes, e.g. when doing studio recordings, firm realtime.

It should be noted these distinctions don't correlate with timing; you can have a hard realtime system that needs some network packets at 50ms±10ms intervals, and a soft realtime system that needs packets at 500µs±5µs.

Some audio setups are run quite "close to the metal", both because it needs less buffering, but also the lower human threshold for noticing latency seems to be around 10ms. And having audio not get out of phase with multiple sources/sinks gets added on top of that.

Correct. If you imagine having a dam overflow, the release valves are a hard realtime system. If the dam overflows for more than a few minutes, damage will occur, so the release valves need to be opened within, say, overflow plus 5mins. A generous deadline for any computer, but still a deadline that needs to be kept at all cost.

Digital audio distribution over Ethernet for a stadium PA is definitely hard realtime. Glitches are very noticeable, unlike video.

AVB and TSN are relatively new addition to Ethernet, and specifically designed for realtime AV use. Traditional Ethernet is not really intended for tight real-time use.

The chemical factory I did an internship at in 2001 was sticking with Token Ring at the time.

It was eye-opening.

Reply on news.ycombinator.com