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. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
RS485 CSMA/CD protocol
Started by ●September 22, 2005
Reply by ●September 23, 20052005-09-23
Reply by ●September 23, 20052005-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. > >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. > >ReneMay 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 ]
Reply by ●September 23, 20052005-09-23
On Fri, 23 Sep 2005 09:00:04 -0400 Roberto Waltman <usenet@rwaltman.net> wrote:> 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/
Reply by ●September 23, 20052005-09-23
On 2005-09-23, rziak <news@ziak.com> wrote:>> 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...
Reply by ●September 23, 20052005-09-23
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. -- Grant Edwards grante Yow! My vaseline is at RUNNING... visi.com
Reply by ●September 23, 20052005-09-23
> 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.
Reply by ●September 23, 20052005-09-23
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. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Reply by ●September 23, 20052005-09-23
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. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Reply by ●September 23, 20052005-09-23
Rene Tschaggelar wrote:> 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> > > Rene
Reply by ●September 23, 20052005-09-23
Roberto Waltman <usenet@rwaltman.net> writes:> 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.one of the things we did in the hsdt http://www.garlic.com/~lynn/subnetwork.html#hsdt in the 80s was design and deploy tdma earth stations ... we got a transponder on sbs-4 ... and even got to go to the launch party at the cape (complicated by the scrubs): http://www-pao.ksc.nasa.gov/kscpao/chron/sts41-d.htm slightly related post (at the very bottom mentioning AT&T) http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits we were getting into some fancy dynamic bandwidth re-allocation on superframe boundary. the stations were also capable of agile frequency hopping. a little topic drift ... may wife is listed as co-author on early token-passing patent http://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office. http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration there is even a tie-in between the rios chip design work going on in austin and the lsm & eve out in the valley http://www.garlic.com/~lynn/subtopic.html#801 for even more drift: http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed? http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?) http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004o.html#25 CKD Disks? http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware? http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
