<div dir="ltr">Just my two cents on these comments, you should never get collisions on a modern network if both switch port and host nic are running in full duplex.  Any collisions are a sign of a mismatch of negotiation or setting of the nic to end up in half-duplex on one side or the other, or some other physical crossing of wires occurring, usually indicated by other physical errors.<div><br></div><div>This is what CSMA/CD is for in Ethernet.  I've seen this on 10mb ethernet up to 100gb, and collisions simply don't occur without a config or cabling issue to go into half-duplex.  Anything above 100BaseT doesn't even allow for operation in half-duplex still.<br><div><br></div><div>That doesn't mean you won't get other drops, but drops are 99% of the time caused by buffer starvation of some kind, usually traffic sending faster than the switch (or host cpu) can forward.  These usually show as an interface or queue drop, but certainly not related to a collision occurring in full duplex.</div></div><div><br></div><div>-mb</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 4, 2019 at 7:08 PM David Schwartz <<a href="mailto:newsletters@thetoolwiz.com">newsletters@thetoolwiz.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>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.)</p>
<p>Loops may be a potential problem, for sure.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>-David Schwartz</p>
<blockquote><p>On Oct 4, 2019, at 3:34 PM, kelly stephenson <<a href="mailto:stephenson2773@gmail.com" target="_blank">stephenson2773@gmail.com</a>> wrote:</p>
<p>Looking for some networking advice from the group.</p>
<p>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?</p>
<p>Thanks Kelly --------------------------------------------------- PLUG-discuss mailing list – <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a> To subscribe, unsubscribe, or to change your mail settings: <a href="https://u2206659.ct.sendgrid.net/wf/click?upn=3cK2FVJjyu2N-2Bxco034fZirB8KjJB6TWmws3JQznod2-2BarXdgEBTyt3QzdhIH35ch-2BzFTkBm5yT6T6kXEEWvZQ-3D-3D_6lpMB7VLnN-2Fj9-2FEErg8-2F-2BMBpb5QxlByTgv2M3fbWD9ebvC-2BWrN3h7jImK8EVWYBeIbGa-2BKBEbw1XMJi4Hied-2BbhfzHiHagSWvCder4wfShE3vKdR7oWTBhY2ralrcfzZs4WLvuZgyAMCiwNtsSbuc-2BjjLDkyuxpexuMCBagdJ4uwMdvGvrJbXLpfUddEj4FJ2hDUR6LySuXu-2BpAKkevA5pmlYyUibyx6YohBcPSE0wk-3D" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></p></blockquote>

<img alt="" width="1" height="1" border="0" style="height: 1px; width: 1px; border-width: 0px; margin: 0px; padding: 0px;">
</div>
---------------------------------------------------<br>
PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></blockquote></div>