Binary protocol design: TLV, LTV, or else?

Horrible idea of putting office Windows machines in the same network as some real process control. These days firewalls are used between the networks and often even special gateways in a DMZ.

Repeat the exercise with *shared* fabric scaled back to 10Mb speeds (to compare fairly with 4Mb TR). Or, switched fabric. How big will the packet buffer need to be in that switch? What admission policies will it exhibit? How will a node know a priori how long it must wait to be *sure* the message it sends will get delivered? What happens if one (or 199!) of the other nodes decides it has "a lot more to say" while the node is waiting for its packet to be delivered? Will those other nodes *appear* to be conspiring to lock out that node?

Scale TR up to today's speeds. Pick a comparable ethernet switch and try to come up with a definitive answer. Without being able to characterize the rest of the traffic on that network...

I.e., token passing strategies inherently implement a concept of fairness and equal access. You have to *hope* your ethernet switch does -- and try to get the vendor to provide you with quantitative details of its (current!) implementation. Then, pray they never discontinue it! *And* hope the rest of the nodes on YOUR network behave equitably.

I've been through this exercise before. Getting deterministic behavior from ethernet -- WITHOUT PROTOCOL MODIFICATIONS -- is a real hassle. Witness the assortment of automation protocols "over ethernet"...

I don't see a reference to "Windows" anywhere in the above... Regardless, it doesn't change the idea conveyed.

You are stating the obvious "swings", and not mentioning the "roundabouts".

If you want *guaranteed* behaviour, you have to consider: - What are the guarantees if a node inserts a second token? - What are the guarantees the token gets dropped?

And, of course, there are other failure modes that are more of an issue in token rings, e.g. partitioning, subtle incompatibility between different vendor's protocol stacks etc.

In practice CSMA/CD is usually more robust than token ring.

Sure CSMA/CD has well-understood limitations which need to be worked around. But the workarounds for token ring deficiencies are very similar to those for CSMA/CD deficiencies, so there's no added disadvantage to just using CSMA/CD.

So VLANs... and 802.11Q or other CoS/QoS ....

Or hie down t' the Wally World and buy a Netgear switch or two and leave Betty's print job alone ...

I didn't say that TRN didn't provide stronger guarantees than Ethernet (it did), rather that the guarantees were sufficiently weak that they were mostly useless.

TRN was going switched too. And the guarantees on TRN are impossible to quantify "without being able to characterize the rest of the traffic on that network."

Plenty of switches implement enough VLAN and traffic shaping support to deal with almost all applications' requirements. TRN might have nominally better fairness (OK, you'll *definitely* get a chance to send a packet in the next several seconds some time), but you could still see packet losses and that did nothing for a receiver being too busy to pick up a packet. So you basically still have all the same problems to deal with. I'm not saying switched Ethernet solves all (or even any) of the problems, just that TRN really didn't either.

As strange as it may sound, Ethernet is used on Airbus A350 and A380 planes. Of course the devices have strict throughput control mechanisms in the form of the AFDX protocol

It all depends on your application. You pay for better service.

Sure. So don't run them at high utilization unless you have to. If you have to, get your checkbook out.

NO, they do not. TDM has timeslots; token passing { ARCnet, Token Ring } work differently for different switch topologies. Classic coax* Token Ring is a ring, and each NIC forwards on behalf of its neighbor unless the destination address is the NIC's address.

Latter day Token Ring switches look just like Ethernet switches. Indeed, products would allow layer 2 switching between Ethernet and Token ring. At the very least they'd route.

TDM is *a way*, but it's not *THE* way. If you can deal with retransmission, then Ethernet provides a lot from bandwidth for a lot less money.

that "guarantee" is a holdover from the cognitive dissonance from the largely now-abandoned COTs network. I can sympathize with the desire to run a clock from Maine to San Diego, but ....

what that cognitive dissonance was grounded in was the sure and certain knowledge that telecomms wasn't quite a market product, and some sort of central dogma was needed...

It was all fine when a T1 was all the backhaul you'd ever need.

OOf. That gets ugly.

They're *all" blocking past some limit.

So just how low of a latency do you *need*? By "need", I mean "will negatively affect performance by this cost measure that relates to dollars."

SO go gitcha a big ole ATM switch, and do that if it turns out that way. Maybe MPLS, other stuff.

You will run into much larger timers in an IP stack than in the media, anyway.

Meanwhile, *one* half-duplex RS485 link and...

But bit errors...

Even RS232 over six inches will have a potential BER of more than (1/10^9th).

I was once looking for using 68360 and PPC QUICC communication processor TSA for TDMA multiplexing a low number of bits from a large number of nodes, but it did not materialize.

One interesting alternative using at least some Ethernet hardware is the Ethernet Powerlink

Jut to pick a nit... "Token-Ring" is both a general name for a networking scheme, and a particular networking technology, popularized by IBM and standardized as 802.5.

In the case of the latter, there never was any coax support for TRN, although other token passing systems did support coax. The old thick cables were *shielded* twisted pair, but definitely not coax. IBM made provisions for using the "IBM Cabling System" (mainly all the STP from wall ports to the patch panels to transport the "Category A" (aka coax) 3270 terminal connections over STP, (you needed appropriate baluns*) and twinax (5250) stuff**, as well as a bunch of other things (blue for loops, LSCs for 8100 MCL loops, adapters for WE-404 connectors for the store systems, adapters for async/serial devices). It was quite a menagerie.

IBM did offer a networking option for 3174 (3270 terminal controllers), that allowed you to use a 3270 coax card in a PC as a network adapter - the 3174 bridged that onto the TRN it was connected to, but that was pretty removed from actual TRN.

There's nothing strange about it.

Yep.

The collision domain is now the destination port(s) in the switch. Switch buffering can impose (bounded but) arbitrary latency or drop packets entirely if buffer capacity is exceeded.

The trend has been to place more and more memory into switches so that vendors can claim "no dropped packets". But that has resulted in a pervasive latency problem commonly known as "bufferbloat".

George

CDDI ran over copper wire 8-) At up to 200Mbps - until GbEthernet came along, it was the fastest (standard) copper in town.

George

For hard real time applications, the value is useless, if it arrives after the deadline. On the other hand, loosing some sample values now and then is usually not a big deal, as long as the loss is detected (serial numbers etc.).

A lot of buffer space (either in the TCP/IP stack or in the transmission queue in an Ethernet switch) can be quite harmful, if a message has been obsoleted while in queue. When the frame has finally been forwarded, it is obsolete, since no one is interested in it any more, but still it floats around the network, potentially causing congestion in an other switch along the path.

So when designing a large realtime system, you have to think what traffic is transported in which way, such as TCP/IP pipes vs. MAC/UDP frames, various QoS assignments in switches etc. so that the whole system behaves gracefully even when approaching an overload situation.

I was busy for a few days and unable to be present for the discussion.

To my shock, you people have produced way more content then I expected and than I can consume right now, so it'll take me a few days to catch up to everything (especially, just like my device, I am also resource constrained - trying to run a full time job and two non-trivial projects at the same time (this being one of those two) is quite taxing, to say the least).

Everywhere I've ever been on four different continents, "office equipment" means "Windows".