I’d advise against it without finding someone who’s already done it and is willing to share the details about how they made it work, and what their throughput stats are like. (Their stats could be horrible, but they don’t know and don’t care simply because their needs are being met.)
Loops may be a potential problem, for sure. But a bigger potential problem is that Ethernet implements a "CSMA/CD with Binary Backoff” protocol. If you look into its origins with AlohaNet, you’ll see that it was designed to support maximum bandwidth under "random noise" conditions. That means the more random the packets are sent to the “ether" in relation to others on the line, the more likely they are to get delivered quickly. CSMA/CD is also considered an “unreliable” protocol at the Transport layer because in cases where there are packet collisions, there’s no guarantee that either of the packets will ever reach its destination in a timely fashion, if ever. Packets are not even guaranteed to arrive in the same order they were sent. The more that CSMA/CD traffic looks like it’s clocked, the more likely there will be collisions, and the more irregular the deliveries become because of that Binary Backoff strategy. To solve this problem, IBM invented the TokenRing architecture. In a TR network, there’s a bounded time for a packet to make it around the entire network. If a packet didn’t arrive in that time, you could be assured that it was lost. So if a sender didn’t get back an ACK within 2x the time since it was sent, it knew it had to send it again. In an Ethernet environment, you simply don’t know because there are no guarantees about timeliness at all. When you’ve got equipment sending out data at regular intervals, that looks like a “clock” to the network (like a heartbeat or drumbeat). As long as they’re all set to different intervals, it’s ok. But if any are coincident, there are bound to be more frequent collisions, causing delays or packet losses. If there are enough nodes all on the same schedule, your potential throughput could drop into the gutter. That’s exactly the scenario you’ll have if you daisy-chain a bunch of these things together. With a fast enough circuit (ie., gigabit Ethernet) and small enough packets, your risks will be minimized. But slower circuits and/or larger packets will lead to more collisions, which will tend to slow things down. Your best bet is to hook them up in a ’star’ configuration the way Ethernet was designed. Set up 8- or 16-port routers and drop a node on each port. The routers can be stacked hierarchically, and everything will work just fine. That’s in part because routers are “active" hubs (as opposed to regular “hubs” which are passive); ie, they have a CPU in them, and they help optimize the traffic flow to a certain extent. Again, I wouldn’t invest the time into this unless / until you can find someone who’s already built a similar-sized network and can share the pitfalls they encountered (if any). -David Schwartz > On Oct 4, 2019, at 3:34 PM, kelly stephenson <[email protected]> wrote: > > Looking for some networking advice from the group. > > The system I have has several devices connected in a ring configuration using > one Ethernet port IN and one Ethernet port out. The system uses RSTP for > loop free operation. The idea is simplicity for installation, you just > unplug and plugin a new device in the ring plus you gain redundancy, if one > Ethernet cable breaks you still have another one. This works but my client > has never had more then a half dozen devices on the network yet. > When I say devices just imagine very large machines. The number of devices > could be as many as 100 in the ring or network. Everything I've researched > on RSTP says over 8 devices and its not effective/efficient so I'm > researching other Ethernet failover/failsafe/redundant solutions. > So, the local network configuration needs to scale up to 100 devices, have > redundancy, and low latency for M2M control. Any thoughts? > > Thanks > Kelly > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: https://lists.phxlinux.org/mailman/listinfo/plug-discuss
