| General > General Technical Chat |
| Ethernet as System Comm Link |
| << < (3/5) > >> |
| nctnico:
--- Quote from: fourfathom on March 06, 2022, 01:35:49 am ---Yeah, I had some time before that designed VHF radios and I thought that was high speed tech. All too soon our digital bit rates were way faster than my VHF carrier freqs. --- End quote --- Same here! A couple of decades ago I started out with a 4MHz home computer and nowadays I'm designing circuits / boards with memory busses running at 1.6GHz and high speed interconnects running at several GHz. It boggles my mind that it works despite the fact that the math, simulations and practical trials confirm it works. Interesting times for sure :) |
| mansaxel:
--- Quote from: Cerebus on March 05, 2022, 10:26:25 pm --- --- Quote ---Your colleagues back then would probably not have used the term "unreliable", but rather "non-deterministic". And that's a fair characterization of Ethernet. --- End quote --- Firstly I suspect that he knows what his colleagues said and putting words into their mouths that suit your argument ought to be a bit infra dig. Secondly this is a custom build of a switched ethernet network inside a product, it isn't a general network. It can be made as deterministic as one wishes, if deterministic is even a necessary property for this particular network application. --- End quote --- I think we should read that as 'Your colleagues back then would probably have used the term "unreliable", as meaning "non-deterministic"' in the interest of fairness. That was what the circuit switching people told us IP people back in those days, so I think it fair to assume. (This text below is not trying to lecture people who know better, I'm just trying to not make too many errors in describing to the audience the problem at hand, as I understand it. And perhaps learn something when I'm told how wrong I am.) On the second point, determinism is just a matter of how much PDV (that which sales people call "jitter") one tolerates in packet delivery, as long as there is no packet loss. (A switch will be able to drop packets; it probably won't do it, but the frequency if you've done your homework likely will be about as service affecting in terms of frequency as bit errors in a well maintained PDH/SDH circuit.) The core question of course is where the queues are. The synchronous case will not admit packets/frames at edge faster than forwardable end-to-end, whereas the switched Ethernet will accept line rate regardless of provisioning level upstream. As long as data rates are compatible with system bandwidth the Ethernet will be as deterministic as the synchronous net. Where Ethernet (or any hop-by-hop technology with varying speeds) has problems, is when line speed is decreasing. If you're feeding your wiring closet switch with 10GE and it's got data hungry clients connected at 1GE, and the server is connected to the core switch in the machine room with 10GE (all-in-all not an unrealistic situation) the quality of the wiring closet switch is going to be much more critical than the core switch. Because the downconversion is going to create a queue of packets waiting to go out on the slow interface. Such queues must use special memory called (TCAM) in order to not slow down the packet forwarding. If the TCAM buffers are full, the switch will drop outgoing packets. Such memory is expensive which means it is a scarce resource, and needs careful management. This is one of the things that sets switches apart, and why some switches are more expensive than others. From this it is trivial to deduce that a single-speed Ethernet is much easier to make almost-deterministic. And, if that was the case, it mostly proves that the original idea would have been feasible, and as has been mentioned, this was already proven by Juniper. |
| m k:
I had once an Ethernet to Centronics dongle for a printer and it didn't work with big files. It didn't know how to wait. One other case was a 10baseT network of Apple machines. It didn't work since Macs at the time didn't localize practically anything opened over the network. Something like sucking the operation through the network like a processing terminal. But if Ethernet is completely encapsulated inside something deterministic is it still Ethernet? I'd say it's just a wire with a capacity. |
| fourfathom:
--- Quote from: mansaxel on March 06, 2022, 06:56:33 am ---From this it is trivial to deduce that a single-speed Ethernet is much easier to make almost-deterministic. And, if that was the case, it mostly proves that the original idea would have been feasible, and as has been mentioned, this was already proven by Juniper. --- End quote --- I think you've missed the essence of my original question. The control-plane (configuration and management of the various boards in the chassis) doesn't require a deterministic interconnection, and I wasn't looking for one. My goal, and apparently Juniper's, was to provide a reliable comms path. We didn't need the equivalent of a timeslotted protocol, or even the fixed-size cell of ATM. Variable frame-length ethernet and varying (but reasonable) delays would have been just fine. My approach would have guaranteed no collisions and in-order frame delivery, but the software guys were fixated on "UNRELIABLE", which was not the case here. I think UNRELIABLE became the mantra during the original thick and thin-wire coaxial ethernet implementations, where we had a shared physical medium and relied on collision-detect, jamming and backoff to make it work. And of course RELIABLE comms are carried over UNRELIABLE networks everywhere and everyday, thanks to higher-level protocols. This control-plane was completely independent of the timesliced data-plane switching system. These days we have somewhat eliminated the need for a traditionally deterministic data-plane and network. Instead we rely on speed, statistics, and protocol. The days of having to use every single bit to within a nanosecond of its life are largely behind us, at least in telecoms (*). (* More reminiscences:) Thin-wire ethernet: During my first start-up we pulled the thin-wire ethernet out of the walls to go with 10BASE-T (and of course faster, later). I ended up with boxes of RG-58 BNC jumpers, TEEs and terminators. Twenty years (thirty?) later I'm still using these (for RF work) in my home lab. Multiplexing, Bit-Stuffing, Floating Payloads, Synchronization, Plesiochronous Networks, Metastability, and Clock Synthesis, Prime Numbers: Well, too much, and off the subject at hand, but lots of fun. I would love to talk about this and share some of what I learned if anyone cares (hint). |
| mansaxel:
--- Quote from: fourfathom on March 06, 2022, 03:31:18 pm --- --- Quote from: mansaxel on March 06, 2022, 06:56:33 am ---From this it is trivial to deduce that a single-speed Ethernet is much easier to make almost-deterministic. And, if that was the case, it mostly proves that the original idea would have been feasible, and as has been mentioned, this was already proven by Juniper. --- End quote --- I think you've missed the essence of my original question. The control-plane (configuration and management of the various boards in the chassis) doesn't require a deterministic interconnection, and I wasn't looking for one. My goal, and apparently Juniper's, was to provide a reliable comms path. We didn't need the equivalent of a timeslotted protocol, or even the fixed-size cell of ATM. Variable frame-length ethernet and varying (but reasonable) delays would have been just fine. My approach would have guaranteed no collisions and in-order frame delivery, but the software guys were fixated on "UNRELIABLE", which was not the case here. --- End quote --- I think we agree more than you think ;-) I fully appreciate your original approach. That is what we've got TCP for! The gut reaction of the TDM people likely is, as you write in the part I snipped, based on a hubbed Ethernet, on which CSMA/CD was the norm, and that very clearly required every bell and whistle of TCP to deliver traffic. On a well-behaved modern Ethernet link, these problems are gone. I run audio and video over Ethernet, uncompressed, without retransmissions (no time for them!) at work, and it works out just nicely, if you do your design right. On timing, as you write; if we can hold packet delay variation well below the timeout value for various control function timeouts, we're good. And the extra energy spent in teaching the control program to accept data when it arrives, and not to crash/hang if it does not arrive exactly when it should (according to the TDM clock), is well invested, because it makes the control system resilient. |
| Navigation |
| Message Index |
| Next page |
| Previous page |