[En-Nut-Discussion] Industrial interfaces (Modbus TCP, Profinet, etc.)

[Thiago A. Corrêa]

Hi Philipp,

On Thu, Jul 17, 2014 at 2:59 PM, Philipp Burch <phip at hb9etc.ch> wrote:
> Hi Thiago!
>
> If I'm not mistaken, the collision resolution mechanism with the random
> delays only kicks in if there is a hardware collision on the bus, i.e.
> two drivers active at the same time. This can't happen in a switched
> network, as there are only point-to-point connections with full duplex
> capability. At least in 10BASE-T and faster, but I've never seen a coax
> network installation in the last years. A switch could probably actively
> generate a collision when it can't handle the received data, but that
> would seem stupid to me. Just dropping an undeliverable frame should be
> the easiest and safest way.

You are probably right about the collision due to full-duplex. But
there are no "undeliverable frames" in Ethernet AFAIK. If the switch
doesn't know the target address (because it's not in it's address
tables) then it must forward to all ports in the hope that one of them
is connected to the target host.

Sure I'm not an expert on industrial ethernets (or normal ethernet) so
it might be an entierely different reason, but it's not because it's
switches instead of hubs :)

Also notice switches doesn't split the boardcast domain, and
broadcasts are replicated to all ports (on the same vlan). A normal
network will have a lot of broadcasts. Windows machines in particular
broadcast a lot on it's own. The same process you describe of store
and forward and in particular if a switch were to drop a 1500 byte
frame it would create a lot wait time in the message from the
application layer perspective, since it will require retransmissions,
and the worst part, figuring out that the data was lost in the first
place.
Anyway, realtime depends on what you define to be realtime. Normal
ethernet might be enough for some applications, but lacking for
others.