Why CSMA/CD is not suitable for real time applications??

I question the premise; I designed and shipped shared-media Ethernet (CSMA/CD) products for real-time factory automation applications 20 years ago.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

In article , levin wrote: :Why CSMA/CD is not suitable for real time applications??

Sounds like a homework question to me...

Suppose you have a frame ready to send. What is the minimum time before the recipient receives it? And presuming it doesn't get lost or discarded, what is the maximum time before the recpient receives it?

For the same reason why homework questions are not suitable on technical newsgroups.

Levin wrote: > Why CSMA/CD is not suitable for real time applications??

Walter Roberson replied:

and Rich Seifert wrote:

In general, you can take anything Rich says and consider it gospel (at least I do) but I've got to side with Walter on this one.

I think there is a lot of misunderstanding (or maybe different understandings) about what is really meant by real-time. Most seem to think that real-time means high speed or high performance. What it really means is *guaranteed* performance. At least that's the case for what people commonly refer to as hard real-time. When Walter asks "What is the minimum time before the recipient receives it?", that is really the crux of the matter because may recollection is that max delivery time is unbounded even for a correctly operating ethernet network (at least for the non-trivial case with more than one node offering load). You can't guarantee performance when you don't know the worst case performance.

Having said that, very few real-time applications are that stringent. Most are soft real-time systems that can (or should) easily tolerate an occasional dropped packet. I, like a lot of developers, successfully use ethernet for real-time applications every day. Most of the time using something like token ring for deterministic performance just ain't worth the hassle. You can add a software layer on top of the ethernet network layer to implement deterministic performance (something along the lines of MIL-STD-1553 command/response) but again it usually isn't worth the effort.

If you're designing a Space Shuttle Main Engine controller then by all means use a network with deterministic performance. Other than that, at least go in with your eyes open and understand the limitations.

Just my $0.02 worth and I hope Rich doesn't flog me too bad. ;-)

Bob Baggerman Georgia Tech

A lot of those issues disappeared, with the use of switches, in place of hubs or shared cable. In the days of collisions, you really couldn't put hard numbers on some things. With switches, a lot of that ambiguity disappears.

I do too!

Only literally true. Real life is all a question of probabilities. There's no sense in hardening the network if it is surrounded by weaker links in the performance chain.

Ethernet is probabilistically suitable for some real-time apps.

-- Robert

If by "guaranteed" you mean 100.0%, then no communications system in the real world can meet the criterion. If you are willing to live with less than "guaranteed," then the question becomes what level of imperfection is acceptable (i.e., "how many nines?").

Not "can" or "should", but *must*. Since communication errors are inevitable (ultimately, it comes down to thermal noise), there will always be some residual level of packet loss.

Which was exactly my point. To say that Ethernet and CSMA/CD are not suitable for real-time communications is belied by the fact that we use it for such purposes all the time.

Ignoring for the moment the implied assumption that somehow "deterministic performance" is a requirement of a real-time application, there is a common misconception that Token Ring is in fact deterministic, in that one can predict its delay and/or throughput in advance of frame transmission. This is pure propaganda once used by IBM (and others) to try to dissuade users from deploying Ethernet networks, under the claim that somehow you would get more reliable and predictable macro-performance from Token Ring (i.e., performance as seen by the user of an application).

Token Ring is "deterministic" only in a theoretical, abstract sense, using "textbook-style" assumptions. In reality, what an application cares about is the time delay between queueing a frame for transmission on the LAN, and reception of that frame by the intended recipient. Just as with Ethernet, Token Ring cannot put any "guaranteed bound" on this time, due to a number of factors:

(1) As discussed above, frames will always be discarded due to communications errors. The error rate on a Token Ring LAN is essentially the same as for an Ethernet LAN, as they use similar encoding, cables, etc.

(2) While textbooks all discuss the "bounded time" for circulation of a token, they rarely discuss the disruption caused by insertion/removal of stations on the ring. Since any practical network will have workstations regularly powering up/down during operation, there will be numerous disruptions of the ring during application execution. Each such disruption will normally require a "ring recovery", whereby a token must be regenerated, and perhaps a selection of a new Active Monitor, etc. This will incur a delay orders of magnitude greater than the "expected" token rotation time.

(3) Token Ring advocates like to tout the availability of low-level priority access mechanisms, whereby certain stations or applications can assert a higher claim to use a token than others. Of course, any application that is not running at the highest priority level can never ensure that it will *ever* see a free token, much less one within some bounded time. That is, "deterministic" behavior exists (if it exists at all) only for the highest priority level. Since *everyone* wants high priority (who ever says that their network application is less important than someone else's?), the result is that all applications always run at the highest priority, making the entire priority scheme moot.

(4) Finally (and perhaps the most important), it is rarely the case that a given station has only *one* active application using the network at any time. All network applications running on the station are placing frames into the transmit queue for the network interface, independently from each other. Thus, even if: (a) there are no errors, (b) the ring is not disrupted, and (c) the application is running at the highest priority, putting a frame on the transmit queue does NOT ensure that it will be transmitted (much less received) within the "bounded" token rotation time. All of the frames ahead of it in the queue (placed there by other applications) will be transmitted first.

It becomes clear that any "determinism" theoretically present in Token Ring is useless in a practical sense, since applications cannot use such characteristics to their advantage. It may make for nice classroom discussions, but the effects are lost in real-world systems.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Begin On 2005-01-20, Rich Seifert wrote: [snip!]

``802.4''.

Anyway, my point and pet-peeve is that it is still useful to have native support like what ATM provides. Too bad that ATM is chock full of assumptions that don't make much sense outside of the teleco world, and otherwise is dead already. The effect is that we're now rolling out ethernet(-like) stuff everywhere, with the nicer extras bolted on, as it were. I can't help but think that it'd be nicer if such'd been designed in from the start. But, you know, that's simply not how the world works.

On a different tangent; 802.12. Sure it isn't dead, just resting. But did it, in fact, improve on deterministic-ness compared to ethernet, in practice?

We're still getting requests from customers for new ATM equipment, mostly because of the requirement to interwork with the intstalled base. I expect this segment of the market will move to GbE over the next few years.

ATM is old and grey, but it's not dead yet.

Regards, Allan

agreed - the ATM backbone at work has increasing load even now, although a lot of the frame relay ports it used to feed are going as corporates move to MPLS.

UK DSL is 95% or more ATM based. i believe the same is true in some other countries.

and the incumbent carrier (BT) recently launched a national Ethernet service - but the underlying WAN is actually ATM - i suppose they have to keep all those switches busy somehow.

| > In Norway 1 is very common (but not ubiquitous - the provider I work for | > also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne | > equipment). 2 is not nearly as common. | | Steinar, what protocol are they running over SHDSL instead of ATM? Is it | pure Ethernet, as in 2BASE-TL? Or is there some other kind of (proprietary) | encapsulation involved?

A proprietary encapsulation (essentially Ethernet encapsulated in HDLC). The advantage is significantly less overhead than ATM. The disadvantage is precisely the fact that it is proprietary, thus no competition and more expensive DSL modems.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

| UK DSL is 95% or more ATM based. i believe the same is true in some other | countries.

It's important to differentiate between 1. ATM used on the link from DSLAM to DSL "modem" at the customer location, and 2. ATM used from the DSLAM towards the backbone.

In Norway 1 is very common (but not ubiquitous - the provider I work for also sells SHDSL which is *not* ATM based, using Nettonet/Paradyne equipment). 2 is not nearly as common.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Steinar, what protocol are they running over SHDSL instead of ATM? Is it pure Ethernet, as in 2BASE-TL? Or is there some other kind of (proprietary) encapsulation involved?

Michael remove "filter" from email address