Ethernet suggestions

[Michael Butash]

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.

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.

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.

-mb


On Fri, Oct 4, 2019 at 7:08 PM David Schwartz <newsletters at 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 at 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 at 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 at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20191005/5dee54b8/attachment.html>