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 <
newsletters@thetoolwiz.com>
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 <stephenson2773@gmail.com>
> 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
> <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>
>
> ---------------------------------------------------
> 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
(text/plain)