That was a great explanation David, thanks! Wasn't my question, but I certainly learned a lot. Thanks, Alexander Sent from my Galaxy S10+ On Fri, Oct 4, 2019, 19:08 David Schwartz wrote: > 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 > 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 – PLUG-discuss@lists.phxlinux.org To subscribe, > unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss