Reply by Ignatios Souvatzis●December 20, 20052005-12-20
On 2005-09-23, Roberto Waltman wrote:
> 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.
Only there wasn't any satellite.
Peripheral stations would broadcast uncoordinated toward the central
station; the central station would broadcast - on a different frequency
channel - acks to the peripherals (if reception was ok) and, of course,
packets for the peripherals.
On top of that, virtual serial lines were implemented that could address
RJE or printers or whatever either at another station or at the central
site, which included a gateway to a satellite link to ARPAnet at some
point - which might be the reason for the confusion.
But yes, many of the peripheral stations would not be able to hear one
another; so carrier sense was impossible, and explicit collision
detection wasn't done either. The central station (as any other) would
discard packets with wrong CRCs and send an ACK for good packets.
Regards,
-is
--
seal your e-mail: http://www.gnupg.org/
Reply by Henrik Johnsson●September 27, 20052005-09-27
therion <therion0@yahoo.com> wrote:
>
> "therion" <therion0@yahoo.com> wrote in message
> news:dgv8ou$smm$1@sunce.iskon.hr...
>> 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?
>>
>
> Ok, while most of you where elaborating about token vs. CSMA/CD , you forgot
> the Q... and I built a prototype network with 5 nodes - and it worrks very
> well! I will post C source code soon.
Over what distance have you tried this? In my experience it could work
fine on a short bus, but fail over longer distances. I've had buses
with about 20 nodes over a distance of 2-3 meters where collisions
occurred due to hardware failure. If the desired signal was input at
one end and a disturbing signal at the other then the nodes close to
the good transmitter would still reliably receive that signal, no
collision would have been detected in that end of the bus.
[snip]
> Like Tim Shoppa pointed
> " I think
> the original poster was looking to avoid such mistakes by asking for
> example code that does things the right (not wrong) way."
It's not a matter of using clever code, the electrical interface will
not work predictably in such a setup. To compensate you will have to
use a pretty complex protocol in addition to all the CSMA/CD stuff.
If you use the termination to hold the "high" level and only drive the
"low" level actively (or vice versa) you would probably stand a better
chance, It would perhaps require a lower data rate, but in home
automation I guess it could be fast enough.
> Please help in that direction!
>
Even if that direction is a dead end?
/Henrik
--
Reply by Paul Keinanen●September 26, 20052005-09-26
On Tue, 27 Sep 2005 01:15:38 +0800, prep@prep.synonet.com wrote:
>Anne & Lynn Wheeler <lynn@garlic.com> writes:
>
>> the big transition for ethernet was adding listen before transmit
>> (and adapting t/r cat5 hub/spoke)
>
>The big change was IMO, the DIX, DEC, Intel, Xerox, spec with 10Mb
>over coax, and the tightened up DIX II. The original cable was a
>special, and was changed to RG-forget. This also got rid of the small
>embarsment of the cable exceding Tempest specs and in theory being
>unexportable from the US. (The fix was to change the cable spec.)
As far as I remember, the only special thing about the yellow DIX
cable was the markers that dictated the minimum distance where you
could put your vampire taps. Quite a few installations used the
standard RG-8 (currently known as RG-213), but you had to measure the
minimum tap distance yourself.
Paul
Reply by ●September 26, 20052005-09-26
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> the big transition for ethernet was adding listen before transmit
> (and adapting t/r cat5 hub/spoke)
The big change was IMO, the DIX, DEC, Intel, Xerox, spec with 10Mb
over coax, and the tightened up DIX II. The original cable was a
special, and was changed to RG-forget. This also got rid of the small
embarsment of the cable exceding Tempest specs and in theory being
unexportable from the US. (The fix was to change the cable spec.)
> my vague recollection was early ethernet was 3mbit/sec, didn't do
> listen before transmit and had this big thick cables ... looked a
> lot like the pcnet cables (which i believe did 1mbit/sec but used a
> tv head-end type implementation).
There was a 3 Mb `Xerox Wire' that preceded DIX.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Reply by David Dyer-Bennet●September 25, 20052005-09-25
Rene Tschaggelar <none@none.net> writes:
> 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.
It was also *tremendously* more dificult to implement in routers and
such. The volume of code required to add token ring was phenomenal.
(and FDDI, which participate heavily in what we called "token ring
brain damage").
> 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.
Cheaper to buy a bit more network bandwidth and use a simpler
protocol, as it turns out. Ethernet works fine under even rather
heavy loads in the real world.
> 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.
"therion" <therion0@yahoo.com> wrote in message
news:dgv8ou$smm$1@sunce.iskon.hr...
> 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?
>
Ok, while most of you where elaborating about token vs. CSMA/CD , you forgot
the Q... and I built a prototype network with 5 nodes - and it worrks very
well! I will post C source code soon.
The aim of the project is to build a HOME AUTOMATION network, no video, no
brakes , not driving planes!!! just control of the light, HVAC and usual HA
stuff.
Like Tim Shoppa pointed
" I think
the original poster was looking to avoid such mistakes by asking for
example code that does things the right (not wrong) way."
Please help in that direction!
THX.
Reply by Rene Tschaggelar●September 24, 20052005-09-24
Grant Edwards wrote:
> 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.
>>>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.
>>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
Reply by Paul Marciano●September 23, 20052005-09-23
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?
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.
Reply by Peter Flass●September 23, 20052005-09-23
Rene Tschaggelar wrote:
> 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...
Reply by Anne & Lynn Wheeler●September 23, 20052005-09-23
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> 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/