| Author |
Message |
John Hudak
Guest
|
 Posted:
Fri Sep 23, 2005 4:15 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
Rene Tschaggelar wrote:
| Quote: | Tim Shoppa wrote:
And if you have
multiple masters, then better implement a token
protocol. IMO, this collision protocol was one of
the biggest mistakes in history of IT.
The token ring advocates always pointed out how certain circumstances
could lead to collision detection not working nicely. They were also
extremely unconfortable with the lack of guaranteed bandwidth for each
master etc.
The point is the behaviour under load. A token protocol doesn't
require a token ring. A bus is sufficient, ARCnet works on
twisted pair and over coax.
Tokenring failed for commercial reasons. It was single source
and the price was beyond reasonable.
When you have a network and it should work under heavy load,
eg all nodes want to transfer huge binaries at the same time,
then a token protocol distributes the bandwidth of the medium
over the nodes while the colision detect system just detects
endless collisions and does endless retries.
It is less that the tokenring advocates were uncomfortable.
A realtime system requires a defined response time that suits
the physical installation this system should control.
A car control system requires responsetimes in the millisecond
region and you wouldn't want your cars cpu to retry some bullshit while
you want the car to stop. Realtime response has nothing
to do with being comfortable, it has to do with lives.
|
Exactly, so for this type of application, it may be a wise engineering
choice NOT to use Enet for communication. THis does not make it bad! I
don't think a blanket statement about it being the worst decision ever
is warranted. If you used Ethernet in a hard RT system and did not
design it properly, thats your fault, not the protocols.....
John
|
|
| Back to top |
|
 |
Roberto Waltman
Guest
|
| Posted:
Fri Sep 23, 2005 4:15 pm Post subject:
Ethernet, Aloha and CSMA/CD - (was: RS485 CSMA/CD protocol) |
|
|
Rene Tschaggelar <none@none.net> wrote:
| Quote: | therion wrote:
Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my
new AVR project for home automation.
This collision protocol only makes sense with multiple
masters, not in a master-slave setup. And if you have
multiple masters, then better implement a token protocol.
IMO, this collision protocol was one of the biggest
mistakes in history of IT.
Rene
|
May be, but it also may have been an unavoidable mistake - I can not
think of a better approach for Hawaii's original ALOHA radio network
on which Ethernet/CSMA/CD where partially based. (Especially when you
consider the technology available at the time.)
Each station in the Aloha network could not listen to the others, both
because of the terrain of the island and because the antennas were
directed to the "common medium", the satellite, so they had to
broadcast blindly and wait for the satellite to echo it back to all
the stations + acknowledge, as an indication that there was not
collision.
Of course the satellite or a dedicated ground station could have
worked as masters distributing tokens, allocating time slots, etc. but
that would have required them to adjust to changing network
configurations and use some of the available bandwidth. (9.6
Kbits/sec!!)
Again, think of the hardware available on the early 70's...
Excerpts from the paper "Ethernet: Distributed Packet Switching for
Local Computer Networks"
Robert M. Metcalfe and David R. Boggs
Xerox Palo Alto Research Center
CACM July 1976 (almost 30 years!)
".....
3. Design Principles
Our object is to design a communication system which can grow smoothly
to accommodate several buildings full of personal computers and the
facilities needed for their support.
Like the computing stations to be connected, the communication system
must be inexpensive. We choose to distribute control of the
communications facility among the communicating computers to eliminate
the reliability problems of an active central controller, to avoid
creating a bottleneck in a system rich in parallelism, and to reduce
the fixed costs which make small systems uneconomical.
Ethernet design started with the basic idea of packet collision and
retransmission developed in the Aloha Network [1]. We expected that,
like the Aloha Network, Ethernets would carry bursty traffic so that
conventional synchronous time-division multiplexing (STDM) would be
inefficient [1, 2, 21, 26]. We saw promise in the Aloha approach to
distributed control of radio channel multiplexing and hoped that it
could be applied effectively with media suited to local computer
communication. With several innovations of our own, the promise is
realized.
Ethernet is named for the historical luminiferous ether through which
electromagnetic radiations were once alleged to propagate. Like an
Aloha radio transmitter, an Ethernet transmitter broadcasts
completely-addressed transmitter- synchronous bit sequences called
packets onto the Ether and hopes that they are heard by the intended
receivers. The Ether is a logically passive medium for the propagation
of digit signals Is and can be constructed using any number of media
including coaxial cables, twisted pairs, and optical fibers.
3.1 Topology
We cannot afford the redundant connections and dynamic routing of
store-and-forward packet switching to assure reliable communication,
so we choose to achieve reliability through simplicity. We choose to
make the shared communication facility passive so that the failure of
an active element will tend to affect the communications of only a
single station. The layout and changing needs of office and laboratory
buildings leads us to pick a network topology with the potential for
convenient incremental extension and reconfiguration with minimal
service disruption.
....."
A few highlights:
"to accommodate several buildings full of personal computers..."
Several buildings, not a city, not the Internet, not the world.
"We expected that, like the Aloha Network, Ethernets would carry
bursty traffic so that conventional synchronous time-division
multiplexing (STDM) would be inefficient [1, 2, 21, 26]. "
Not teleconferencing, video-streaming, etc.
"we choose to achieve reliability through simplicity"
And that was indeed achieved.
(x-posted to alt.folklore.computers - I'm sure somebody will have
something interesting to comment over there, before drifting off-topic
for the next 3000 follow-ups... ;-) )
Roberto Waltman.
[ Please reply to the group,
return address is invalid ] |
|
| Back to top |
|
|
Grant Edwards
Guest
|
| Posted:
Fri Sep 23, 2005 4:15 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
On 2005-09-23, rziak <news@ziak.com> wrote:
| Quote: | My hint would be...Don't.
I've been curious about this sort of thing myself, and as far as I can
tell from web research no one out there has ever got it working
satisfactorily for real, as opposed to demonstration projects.
AFAIK it's just not feasible to reliably detect collisions on a
real-world bus with "standard" UART and RS485 hardware.
This is what CANBus is for.
I got to the same conclusion.
|
Too bad the frames in CAN are so tiny.
Yes, I know the reason why, and in some applications it does
make sense. In applications where higher latencies can be
tolerated, having an option to use 256 or 512 byte frames would
cut way down on the overhead.
--
Grant Edwards grante Yow! The FALAFEL SANDWICH
at lands on my HEAD and I
visi.com become a VEGETARIAN... |
|
| Back to top |
|
|
Grant Edwards
Guest
|
| Posted:
Fri Sep 23, 2005 4:15 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
On 2005-09-23, Rene Tschaggelar <none@none.net> wrote:
| Quote: | therion wrote:
Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my
new AVR project for home automation.
Any link, hint or help for the similar source code?
This collision protocol only makes sense with multiple
masters, not in a master-slave setup. And if you have
multiple masters, then better implement a token protocol.
IMO, this collision protocol was one of the biggest
mistakes in history of IT.
|
Why? It works brilliantly for Ethernet. In my experience,
token passing is horribly complex.
--
Grant Edwards grante Yow! My vaseline is
at RUNNING...
visi.com |
|
| Back to top |
|
|
Steve O'Hara-Smith
Guest
|
| Posted:
Fri Sep 23, 2005 4:15 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - (was: RS485 CSMA/CD protoc |
|
|
On Fri, 23 Sep 2005 09:00:04 -0400
Roberto Waltman <usenet@rwaltman.net> wrote:
| Quote: | The Ether is a logically passive medium for the propagation
of digit signals Is and can be constructed using any number of media
including coaxial cables, twisted pairs, and optical fibers.
|
Indeed I once saw an ethernet installation where the medium was
the open air via a number of stubby ariels. It was a warehouse robot
control system with a number of robots and a control computer communicating
by ethernet with no wires.
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/ |
|
| Back to top |
|
|
Tim Shoppa
Guest
|
| Posted:
Fri Sep 23, 2005 4:16 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - (was: RS485 CSMA/CD protoc |
|
|
| Quote: | And if you have
multiple masters, then better implement a token
protocol. IMO, this collision protocol was one of
the biggest mistakes in history of IT.
|
The token ring advocates always pointed out how certain circumstances
could lead to collision detection not working nicely. They were also
extremely unconfortable with the lack of guaranteed bandwidth for each
master etc.
But the token ring vs collision detection wars for general-purpose
networking were fought and token ring lost. In real life the concerns
that the token ring advocates had about collisions just don't happen,
even on highly saturated ethernets.
Now, you can make up some really stupid collision detection/back-off
algorithms that just don't work. CSMA/CD can be stupidly implemented
such that it doesn't work well. Usually these implementations were
done by committees who thought too hard about a simple problem and
worked hard to come up with an insane list of requirements. I think
the original poster was looking to avoid such mistakes by asking for
example code that does things the right (not wrong) way.
Curiously I've seen CSMA/CD done the "wrong way" most often when the
committee designing it has a lot of token ring advocates on it. They
add all sorts of arbitrary and unnecessary requirements about
guaranteed bandwidth etc. and make the result useless.
Token ring still lives on in many special-purpose protocols, not
necessarily because collision detection won't work but just because it
wasn't used.
Tim. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
|
| Back to top |
|
|
Grant Edwards
Guest
|
| Posted:
Fri Sep 23, 2005 9:34 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
On 2005-09-23, Rene Tschaggelar <none@none.net> wrote:
| Quote: | IMO, this collision protocol was one of the biggest
mistakes in history of IT.
|
You _must_ be trolling...
| Quote: | Why? It works brilliantly for Ethernet. In my experience,
token passing is horribly complex.
No it doesn't work brilliant. It is crap. It doesn't have a
deterministic responsetime.
|
So what? The vast, vast majority of applications don't _need_
a deterministic response time. What is needed is simple,
cheap, and high peak transfer rates.
If you're doing some sort of hard-realtime stuff, then use a an
appropriate protocol. Use CAN or ARCnet or whatever. The
choice of inappropriate tools isn't the tool's fault.
| Quote: | The token protocol such as in Arcnet is much better. Each node
gets a slot time every 150ms or so. At the time the two
battled, the Ethernet was 10MBit, and ARCNet was 2.5MBit. But
under load Arcnet performed much better. While Arcnet was
standing at somewhat below 2.5MBit over the bus, independent
on the number of nodes and traffic, Ethernet went right down
to zero with increasing load.
|
For the past 15 years, Ethernet has worked great for everything
I've ever used it for. What more can a guy ask?
| Quote: | But the marketing guys just saw the 10MBit vs 2.5MBit.
Too bad. Ethernet improved the bandwidth but the responsetime
is still not deterministic, unless all nodes are connect
to a switch. The switch avoids collisions, of course.
|
Besides, everybody uses switches these days. Ethernet is, for
all practical purposes, a point-to-point protocol used between
two endpoints.
--
Grant Edwards grante Yow! Somewhere in DOWNTOWN
at BURBANK a prostitute is
visi.com OVERCOOKING a LAMB CHOP!! |
|
| Back to top |
|
|
Anton Erasmus
Guest
|
| Posted:
Fri Sep 23, 2005 9:53 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
On Fri, 23 Sep 2005 17:06:18 +0200, Rene Tschaggelar <none@none.net>
wrote:
| Quote: | Grant Edwards wrote:
On 2005-09-23, Rene Tschaggelar <none@none.net> wrote:
therion wrote:
Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my
new AVR project for home automation.
Any link, hint or help for the similar source code?
This collision protocol only makes sense with multiple
masters, not in a master-slave setup. And if you have
multiple masters, then better implement a token protocol.
IMO, this collision protocol was one of the biggest
mistakes in history of IT.
Why? It works brilliantly for Ethernet. In my experience,
token passing is horribly complex.
No it doesn't work brilliant. It is crap. It doesn't have a
deterministic responsetime. The token protocol such as in
Arcnet is much better. Each node gets a slot time every 150ms
or so.
At the time the two battled, the Ethernet was 10MBit, and
ARCNet was 2.5MBit. But under load Arcnet performed much
better. While Arcnet was standing at somewhat below 2.5MBit
over the bus, independent on the number of nodes and traffic,
Ethernet went right down to zero with increasing load.
But the marketing guys just saw the 10MBit vs 2.5MBit.
Too bad. Ethernet improved the bandwidth but the responsetime
is still not deterministic, unless all nodes are connect
to a switch. The switch avoids collisions, of course.
|
A protocol that can be used with RS485 buffers, at high bit rates
is SDLC. This is a superset of HDLC. It also uses token passing.
Each nodes transmits one bit time later what it receives.
Regards
Anton Erasmus |
|
| Back to top |
|
|
Paul Keinanen
Guest
|
| Posted:
Fri Sep 23, 2005 10:40 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
On Fri, 23 Sep 2005 17:16:42 +0200, Rene Tschaggelar <none@none.net>
wrote:
| Quote: | It is less that the tokenring advocates were uncomfortable.
A realtime system requires a defined response time that suits
the physical installation this system should control.
|
When well defined response times are needed, I would not mess with any
tokens but use a traditional fixed single master multiple slave
system.
| Quote: | A car control system requires responsetimes in the millisecond
region and you wouldn't want your cars cpu to retry some bullshit
while you want the car to stop. Realtime response has nothing
to do with being comfortable, it has to do with lives.
|
For applications, in which the need is for some high priority
emergency messages and ordinary messages, I would use CAN and not mess
with tokens that would require lost token handling etc.
Paul |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Sat Sep 24, 2005 12:10 am Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
ref:
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD
the whole saa & terminal emulation forever
http://www.garlic.com/~lynn/subnetwork.html#emulation
overflowed into a number of areas.
romp/pcrt
http://www.garlic.com/~lynn/subtopic.html#801
had done a customer 16bit 4mbit/sec t/r card ... and then the
group was mandated that they had to use the PS2 microchannel
16mbit/sec t/r card for RIOS/6000.
the problem was that the PS2 card had the SAA and terminal emulation
design point where configurations had 300 PCs per t/r lan; bridged,
sharing common theoritical 16mbit (but in acutally much less), not
routers, no gateways, etc. SNA didn't have a network layer ... just
table of physical mac addresses ... modulo when APPN was introduced.
We use to kid the person responsible for APPN that he should stop
wasting his time trying to further kludge up SNA (the SNA group had
non-concurred with even announcing APPN, there was a several week
escalation process and the APPN announcement letter was rewritten to
not imply any relationship between APPN and SNA).
In any case, the pc/rt & rios market segment was supposedly
high-performance workstations, client/server, and distributed
environment. The custom pcrt 16bit 4mbit/sec t/r card actually had
higher per card thruput than the PS2 32bit 16mbit/sec t/r card (again
the saa terminal emulation paradigm.
the pcrt/rios market segment required high per card thruput for high
performance workstations and servers (in client/server environments
where traffic is quite asymmetrical).
in this period, a new generation of hub/spoke enet cards were
appearing (with new generation of enet controller chips like the 16bit
amd lance), where each card was capable of sustaining full 10mbit (aka
a server could transmit 10mbit/secs serving a client base having
aggregate 10mbit/sec requirements).
by comparison, the microchannel 16mbit t/r environment actually had
lower aggregate thruput and longer latencies ... AND the available
cards had per card thruput designed to meet the terminal emulation
market requirements (and one could say that the lack of high thruput
per card also inhibited the evoluation of client/server ... as well as
the 3-tier middle-layer/middleware paradigm that we were out pushing).
my wife had co-authored and presented a response to a gov. request for
high integrity and operational campus-like distributed environment ...
in which she had originally formulated a lot of the 3-tier principles.
http://www.garlic.com/~lynn/subtopic.html#3tier
we then expanded on the concepts and were making 3-tier and "middle
layer" presentations at customer executive seminars ... heavly laced
with high-performance routers aggregating large number of enet
segments. instead of having 300 machines bridged, sharing single
16mbit t/r, you had 300 "clients" spread across ten or more enet
segments ... with servers having dedicated connectivity to the
high-speed routers. other components then were used to stage and
complete the 3-tier architecture. a couple of past posts in answer
to question on the origins of middleware
thtp://www.garlic.com/~lynn/96.html#16 middle layer
thtp://www.garlic.com/~lynn/96.html#17 middle layer
this also contributed to the work that we did coming up with
the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Peter Flass
Guest
|
| Posted:
Sat Sep 24, 2005 12:15 am Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
Rene Tschaggelar wrote:
| Quote: | It is less that the tokenring advocates were uncomfortable.
A realtime system requires a defined response time that suits
the physical installation this system should control.
A car control system requires responsetimes in the millisecond
region and you wouldn't want your cars cpu to retry some bullshit while
you want the car to stop. Realtime response has nothing
to do with being comfortable, it has to do with lives.
|
Oops, sorry officer. I was tuning my radio and I guess I caused the
brakes to stop working for a while... |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Sat Sep 24, 2005 12:15 am Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> writes:
| Quote: | in this period, a new generation of hub/spoke enet cards were
appearing (with new generation of enet controller chips like the
16bit amd lance), where each card was capable of sustaining full
10mbit (aka a server could transmit 10mbit/secs serving a client
base having aggregate 10mbit/sec requirements).
|
.... and the street price of the new generation of 16bit enet cards
capable of sustaining 10mbit/sec/card was heading towards $49
.... while the ps2 microchannel 16mbit t/r cards (where you were lucky
to get much more 1mbit/sec/card, aks the per card sustained thruput
was less than the pc/rt 16bit 4mbit/sec t/r card) were holding in at
over $900.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Paul Marciano
Guest
|
| Posted:
Sat Sep 24, 2005 12:15 am Post subject:
Re: RS485 CSMA/CD protocol |
|
|
therion wrote:
| Quote: | Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my
new AVR project for home automation.
Any link, hint or help for the similar source code?
|
I have implemented a multi-master packet oriented framework over RS485
using HDLC-style framing and byte stuffing, checksums and positive
acknowledgement.
It didn't use receive monitoring during transmit, instead it waited for
the line to become idle (inactivity in the receiver) for a short
sustained period, then transmitted into the wilderness and used timers,
random backoffs and retries upon non-receipt of an ACK.
Collisions were actually quite rare, and when they did happen the
checksums and ACKs took care of them.
I doubt it would win any awards, but it was trivial to implement and
worked well enough for the environment it was in.
Regards,
Paul. |
|
| Back to top |
|
|
Rene Tschaggelar
Guest
|
| Posted:
Sat Sep 24, 2005 3:33 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
Grant Edwards wrote:
| Quote: | On 2005-09-23, Rene Tschaggelar <none@none.net> wrote:
IMO, this collision protocol was one of the biggest
mistakes in history of IT.
You _must_ be trolling...
|
Sure. Always.
| Quote: | Why? It works brilliantly for Ethernet. In my experience,
token passing is horribly complex.
No it doesn't work brilliant. It is crap. It doesn't have a
deterministic responsetime.
So what? The vast, vast majority of applications don't _need_
a deterministic response time. What is needed is simple,
cheap, and high peak transfer rates.
|
Synchronizing databases, transfering audio and video, the usual.
| Quote: | But the marketing guys just saw the 10MBit vs 2.5MBit.
Too bad. Ethernet improved the bandwidth but the responsetime
is still not deterministic, unless all nodes are connect
to a switch. The switch avoids collisions, of course.
Besides, everybody uses switches these days. Ethernet is, for
all practical purposes, a point-to-point protocol used between
two endpoints.
|
Guess why the more expensive switch technology
overtook the cheap hubs ? Simply because it
is pretty useless witout them. 100MBit delivering
close to zero with 10 simultaneous nodes.
We experienced that once. Smalltalk was writing huge
files at that time. To avoid congestion, we had a
flag in the lab, and only the one with the flag was
allowed to start this particulat process.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in