On 14/01/14 00:35, Don Y wrote:> Hi Robert, > > On 1/13/2014 4:21 PM, Robert Wessel wrote: > >>>> reliable ... but that got fixed and TR's predictable timing made >>>> analyzing systems and programming reliably timed delivery - >>>> particularly across repeaters - easier even than on CAN. >>> >>> At one time, I did an analysis that suggested even 4Mb TR would >>> outperform 10Mb ethernet when you were concerned with temporal >>> guarantees. >> >> Which was one of the touted features of TRN. Unfortunately for TRN, >> approximately zero users actually cared about that. > > It's too bad that "fast" has won out over "predictable" (in > many things -- not just network technology).Token rings, e.g. FDDI and others, had config/management problems that largely negated predictability guarantees, e.g. dropped tokens, duplicated tokens, complexity (have a look at all the FSMs!) CSMA/CD is much easier to manage and faultfind.
Binary protocol design: TLV, LTV, or else?
Started by ●January 8, 2014
Reply by ●January 13, 20142014-01-13
Reply by ●January 13, 20142014-01-13
Hi Robert, On 1/13/2014 5:45 PM, Robert Wessel wrote:> On Mon, 13 Jan 2014 17:35:02 -0700, Don Y<this@isnotme.com> wrote: >> On 1/13/2014 4:21 PM, Robert Wessel wrote: >> >>>>> reliable ... but that got fixed and TR's predictable timing made >>>>> analyzing systems and programming reliably timed delivery - >>>>> particularly across repeaters - easier even than on CAN. >>>> >>>> At one time, I did an analysis that suggested even 4Mb TR would >>>> outperform 10Mb ethernet when you were concerned with temporal >>>> guarantees. >>> >>> Which was one of the touted features of TRN. Unfortunately for TRN, >>> approximately zero users actually cared about that. >> >> It's too bad that "fast" has won out over "predictable" (in >> many things -- not just network technology). >> >> IIRC, SMC was the only firm making TR silicon. (maybe TI had some >> offerings?) Not sure if they even offer any, currently. >> >> [I think I still have some TR connectors, NICs and even a "hub" >> stashed... somewhere] > > Heck, I've still got a ring running... > > I'm not sure how much presence SMC had in TRN, Thomas Conrad and Madge > were the big non-IBM players. IBM, of course, had its own chipsets, > and they did sell them to other vendors.Grrr... I misremembered! It was ARCnet that SMC supported. (cheaper)
Reply by ●January 13, 20142014-01-13
Hi Tom, On 1/13/2014 5:46 PM, Tom Gardner wrote:> On 14/01/14 00:35, Don Y wrote: >> On 1/13/2014 4:21 PM, Robert Wessel wrote: >> >>>>> reliable ... but that got fixed and TR's predictable timing made >>>>> analyzing systems and programming reliably timed delivery - >>>>> particularly across repeaters - easier even than on CAN. >>>> >>>> At one time, I did an analysis that suggested even 4Mb TR would >>>> outperform 10Mb ethernet when you were concerned with temporal >>>> guarantees. >>> >>> Which was one of the touted features of TRN. Unfortunately for TRN, >>> approximately zero users actually cared about that. >> >> It's too bad that "fast" has won out over "predictable" (in >> many things -- not just network technology). > > Token rings, e.g. FDDI and others, had config/management > problems that largely negated predictability guarantees, > e.g. dropped tokens, duplicated tokens, complexity (have > a look at all the FSMs!) > > CSMA/CD is much easier to manage and faultfind.The problem is you have to layer a *different* protocol onto those media if you want deterministic behavior. AND, prevent any "noncompliant" traffic from using the medium at the same time. E.g., you could have "office equipment" and "process control equipment" sharing a token-passing network and *still* have guarantees for the process control subsystems. Not the case with things like ethernet (unless you create a special protocol stack for those devices and/or interpose some bit of kit that forces them to "behave" properly).
Reply by ●January 13, 20142014-01-13
On Mon, 13 Jan 2014 17:54:42 -0700, Don Y <this@isnotme.com> wrote:>Hi Robert, > >On 1/13/2014 5:45 PM, Robert Wessel wrote: >> On Mon, 13 Jan 2014 17:35:02 -0700, Don Y<this@isnotme.com> wrote: >>> On 1/13/2014 4:21 PM, Robert Wessel wrote: >>> >>>>>> reliable ... but that got fixed and TR's predictable timing made >>>>>> analyzing systems and programming reliably timed delivery - >>>>>> particularly across repeaters - easier even than on CAN. >>>>> >>>>> At one time, I did an analysis that suggested even 4Mb TR would >>>>> outperform 10Mb ethernet when you were concerned with temporal >>>>> guarantees. >>>> >>>> Which was one of the touted features of TRN. Unfortunately for TRN, >>>> approximately zero users actually cared about that. >>> >>> It's too bad that "fast" has won out over "predictable" (in >>> many things -- not just network technology). >>> >>> IIRC, SMC was the only firm making TR silicon. (maybe TI had some >>> offerings?) Not sure if they even offer any, currently. >>> >>> [I think I still have some TR connectors, NICs and even a "hub" >>> stashed... somewhere] >> >> Heck, I've still got a ring running... >> >> I'm not sure how much presence SMC had in TRN, Thomas Conrad and Madge >> were the big non-IBM players. IBM, of course, had its own chipsets, >> and they did sell them to other vendors. > >Grrr... I misremembered! It was ARCnet that SMC supported. (cheaper)And Arcnet still exists too... (Although Arcnet was token-bus, not token-ring).
Reply by ●January 14, 20142014-01-14
Don Y wrote:> Hi Tom, > > On 1/13/2014 5:46 PM, Tom Gardner wrote: >> On 14/01/14 00:35, Don Y wrote: >>> On 1/13/2014 4:21 PM, Robert Wessel wrote: >>> >>>>>> reliable ... but that got fixed and TR's predictable timing made >>>>>> analyzing systems and programming reliably timed delivery - >>>>>> particularly across repeaters - easier even than on CAN. >>>>> >>>>> At one time, I did an analysis that suggested even 4Mb TR would >>>>> outperform 10Mb ethernet when you were concerned with temporal >>>>> guarantees. >>>> >>>> Which was one of the touted features of TRN. Unfortunately for TRN, >>>> approximately zero users actually cared about that. >>> >>> It's too bad that "fast" has won out over "predictable" (in >>> many things -- not just network technology). >> >> Token rings, e.g. FDDI and others, had config/management >> problems that largely negated predictability guarantees, >> e.g. dropped tokens, duplicated tokens, complexity (have >> a look at all the FSMs!) >> >> CSMA/CD is much easier to manage and faultfind. > > The problem is you have to layer a *different* protocol onto those > media if you want deterministic behavior. AND, prevent any > "noncompliant" traffic from using the medium at the same time. > > E.g., you could have "office equipment" and "process control > equipment" sharing a token-passing network and *still* have > guarantees for the process control subsystems. Not the case > with things like ethernet (unless you create a special > protocol stack for those devices and/or interpose some bit of > kit that forces them to "behave" properly).As you are no doubt aware, what happened there was Ethernet switching and it well and truly solved the collision problem. Most, if not all packets live on a collision domain with exactly two NICs on it - except for 802.11>x< , where just about any concept smuggled form the other old standards doubtless lives in the air link. -- Les Cargill
Reply by ●January 14, 20142014-01-14
On Mon, 13 Jan 2014 22:40:40 -0600, Les Cargill <lcargill99@comcast.com> wrote:>Don Y wrote: >> Hi Tom, >> >> On 1/13/2014 5:46 PM, Tom Gardner wrote: >>> On 14/01/14 00:35, Don Y wrote: >>>> On 1/13/2014 4:21 PM, Robert Wessel wrote: >>>> >>>>>>> reliable ... but that got fixed and TR's predictable timing made >>>>>>> analyzing systems and programming reliably timed delivery - >>>>>>> particularly across repeaters - easier even than on CAN. >>>>>> >>>>>> At one time, I did an analysis that suggested even 4Mb TR would >>>>>> outperform 10Mb ethernet when you were concerned with temporal >>>>>> guarantees. >>>>> >>>>> Which was one of the touted features of TRN. Unfortunately for TRN, >>>>> approximately zero users actually cared about that. >>>> >>>> It's too bad that "fast" has won out over "predictable" (in >>>> many things -- not just network technology). >>> >>> Token rings, e.g. FDDI and others, had config/management >>> problems that largely negated predictability guarantees, >>> e.g. dropped tokens, duplicated tokens, complexity (have >>> a look at all the FSMs!) >>> >>> CSMA/CD is much easier to manage and faultfind. >> >> The problem is you have to layer a *different* protocol onto those >> media if you want deterministic behavior. AND, prevent any >> "noncompliant" traffic from using the medium at the same time. >> >> E.g., you could have "office equipment" and "process control >> equipment" sharing a token-passing network and *still* have >> guarantees for the process control subsystems. Not the case >> with things like ethernet (unless you create a special >> protocol stack for those devices and/or interpose some bit of >> kit that forces them to "behave" properly). > >As you are no doubt aware, what happened there was Ethernet >switching and it well and truly solved the collision problem. > >Most, if not all packets live on a collision domain with exactly >two NICs on it - except for 802.11>x< , where just about >any concept smuggled form the other old standards doubtless lives in >the air link.And given that most 100Mb and faster (wired) Ethernet links are full duplex these days, there's effectively no collision domain at all. OTOH, that doesn't prevent the switch from dropping packets if the destination port is sufficiently busy.
Reply by ●January 14, 20142014-01-14
Hi Les, On 1/13/2014 9:40 PM, Les Cargill wrote:> Don Y wrote:>>>>>>> reliable ... but that got fixed and TR's predictable timing made >>>>>>> analyzing systems and programming reliably timed delivery - >>>>>>> particularly across repeaters - easier even than on CAN. >>>>>> >>>>>> At one time, I did an analysis that suggested even 4Mb TR would >>>>>> outperform 10Mb ethernet when you were concerned with temporal >>>>>> guarantees. >>>>> >>>>> Which was one of the touted features of TRN. Unfortunately for TRN, >>>>> approximately zero users actually cared about that. >>>> >>>> It's too bad that "fast" has won out over "predictable" (in >>>> many things -- not just network technology). >>> >>> Token rings, e.g. FDDI and others, had config/management >>> problems that largely negated predictability guarantees, >>> e.g. dropped tokens, duplicated tokens, complexity (have >>> a look at all the FSMs!) >>> >>> CSMA/CD is much easier to manage and faultfind. >> >> The problem is you have to layer a *different* protocol onto those >> media if you want deterministic behavior. AND, prevent any >> "noncompliant" traffic from using the medium at the same time. >> >> E.g., you could have "office equipment" and "process control >> equipment" sharing a token-passing network and *still* have >> guarantees for the process control subsystems. Not the case >> with things like ethernet (unless you create a special >> protocol stack for those devices and/or interpose some bit of >> kit that forces them to "behave" properly). > > As you are no doubt aware, what happened there was Ethernet > switching and it well and truly solved the collision problem.It's not collisions that are the problem. Rather, it is timeliness guarantees. A node on an ethernet switch has no guarantee as to when -- or *if* -- its packets will be delivered. Switches have fixed size memories. There are no guarantees that packets sent to the switch ever *go* anywhere. By contrast, token passing networks gave assigned timeslots. You *knew* when your "turn" to use the media would come along. And, were *guaranteed* this by the basic design of the network itself (not some other protocol layered on top of it). Ever seen any timing guarantees for a generic network switch? It's left as an exercise for the user: look at the packet buffer size in the switch, determine whether it is a store-and-forward switch or whether it can exploit cut-through technology, whether it is blocking/nonblocking, *and* the datacomm characteristics of all the other nodes on your network (will they cooperate with each other's needs? Or, blindly use as much as they can get??) and then try to come up with a hard-and-fast number to determine the expected latency for a specific packet on a specific node. Repeat the exercise for a token passing network. [If you think that ethernet makes those guarantees, then you can elide all the acknowledgements in the protocols and still be VERY CONFIDENT that everything STILL works properly :> ]> Most, if not all packets live on a collision domain with exactly > two NICs on it - except for 802.11>x< , where just about > any concept smuggled form the other old standards doubtless lives in > the air link.
Reply by ●January 14, 20142014-01-14
Hi Robert, On 1/13/2014 9:55 PM, Robert Wessel wrote: [attrs elided]>>> The problem is you have to layer a *different* protocol onto those >>> media if you want deterministic behavior. AND, prevent any >>> "noncompliant" traffic from using the medium at the same time. >>> >>> E.g., you could have "office equipment" and "process control >>> equipment" sharing a token-passing network and *still* have >>> guarantees for the process control subsystems. Not the case >>> with things like ethernet (unless you create a special >>> protocol stack for those devices and/or interpose some bit of >>> kit that forces them to "behave" properly). >> >> As you are no doubt aware, what happened there was Ethernet >> switching and it well and truly solved the collision problem. >> >> Most, if not all packets live on a collision domain with exactly >> two NICs on it - except for 802.11>x< , where just about >> any concept smuggled form the other old standards doubtless lives in >> the air link. > > And given that most 100Mb and faster (wired) Ethernet links are full > duplex these days, there's effectively no collision domain at all. > > OTOH, that doesn't prevent the switch from dropping packets if the > destination port is sufficiently busy.Or for the actions of one node influencing the delivery of traffic from *another* node! ("Betty in accounting is printing a lengthy report -- the CNC machines have stopped as their input buffers are now empty...")
Reply by ●January 14, 20142014-01-14
On Mon, 13 Jan 2014 00:30:38 -0700, Don Y <this@isnotme.com> wrote:>> Since branches are not allowed in 10Base2, you have to run the bus via >> _all_ devices, one cable to the T-connector and an other cable back, >> quickly extending past the 200 m limit. > >I don't design aircraft carriers! :> 10m is more than enough to >run from one end of a piece of equipment to the other -- stopping >at each device along the way. 10Base2 was a win when you had lots of >devices "lined up in a row" where it was intuitive to just "daisy >chain" them together. E.g., imagine what a CAN bus deployment >would look like if it had to adhere to a physical star topology >(all those "nodes" sitting within inches of each other yet unable to >take advantage of their proximity for cabling economies -- instead, >having to run individual drops off to some central "hub/switch") > >[As we were rolling our own hardware, no need for T's -- two BNC's >on each device: upstream + downstream.]Did you by chance have one male and one female BNC on the device ? And what happens, when someone wants to pull out the device ? _All_ traffic in the net is disrupted, until the person finds how to join the two cables together, i.e. finds a female-female adapter after a 15 minute search :-)
Reply by ●January 14, 20142014-01-14
On Mon, 13 Jan 2014 22:49:53 -0700, Don Y <this@isnotme.com> wrote:>Hi Les, > >On 1/13/2014 9:40 PM, Les Cargill wrote: >> Don Y wrote: > >>>>>>>> reliable ... but that got fixed and TR's predictable timing made >>>>>>>> analyzing systems and programming reliably timed delivery - >>>>>>>> particularly across repeaters - easier even than on CAN. >>>>>>> >>>>>>> At one time, I did an analysis that suggested even 4Mb TR would >>>>>>> outperform 10Mb ethernet when you were concerned with temporal >>>>>>> guarantees. >>>>>> >>>>>> Which was one of the touted features of TRN. Unfortunately for TRN, >>>>>> approximately zero users actually cared about that. >>>>> >>>>> It's too bad that "fast" has won out over "predictable" (in >>>>> many things -- not just network technology). >>>> >>>> Token rings, e.g. FDDI and others, had config/management >>>> problems that largely negated predictability guarantees, >>>> e.g. dropped tokens, duplicated tokens, complexity (have >>>> a look at all the FSMs!) >>>> >>>> CSMA/CD is much easier to manage and faultfind. >>> >>> The problem is you have to layer a *different* protocol onto those >>> media if you want deterministic behavior. AND, prevent any >>> "noncompliant" traffic from using the medium at the same time. >>> >>> E.g., you could have "office equipment" and "process control >>> equipment" sharing a token-passing network and *still* have >>> guarantees for the process control subsystems. Not the case >>> with things like ethernet (unless you create a special >>> protocol stack for those devices and/or interpose some bit of >>> kit that forces them to "behave" properly). >> >> As you are no doubt aware, what happened there was Ethernet >> switching and it well and truly solved the collision problem. > >It's not collisions that are the problem. Rather, it is >timeliness guarantees. A node on an ethernet switch has >no guarantee as to when -- or *if* -- its packets will >be delivered. > >Switches have fixed size memories. There are no guarantees that >packets sent to the switch ever *go* anywhere. > >By contrast, token passing networks gave assigned timeslots. >You *knew* when your "turn" to use the media would come along. >And, were *guaranteed* this by the basic design of the network >itself (not some other protocol layered on top of it).Even without errors, the constraints weren't very tight - your node could well get the next available slot after the 200 other nodes waiting to transmit a 4K* frame, even with priority reservations (admittedly that could be limited by controlling the number of nodes on the ring). That would be the better part of two seconds. And if there was any sort of token recovery action going on, several seconds of disruption were normal. *4472 bytes for 4Mb TRN, 17800 for 16Mb
