I hate to say it but, a lot of old wives tales here.  What is the
latency added by a cut through switch?  It's the packet header length
divided by the Ethernet bit rate.   If you are worried about this kind
of stuff them you might as well start using shortened cables and wire
because of speed or light delays of one foot per nanosecond.    The
switch latency translated into movement of the mill comes out to
micrometers or nanometers.

If you are worried about a switch, then you really need to worry about
what is on the back side of the Ethernet port on an ARM SBC like the
Pi.   The USB system and the Ethernet are sharing a serial bus.   So
Ethernet and all the USB ports share bandwidth. Even  with a second
ethernet port your UDP packets get queued and have to wait for buss
access.   You r keyboard, mouse, web surfing packets and UDP data
going to the mill are all on that same bus.  This s a much bigger deal
and there is no way around it

But you know what?   The amount of data being send is not very much
and it works just fine.

Next question yo have two network ports, now the software has to look
up which port to send each packet, there is now a routing problem the
software networking stack has to deal with.  Does this added lookup
add more time and latency?  Of course, typically routing is about 10x
slower then switching.



On Tue, Oct 25, 2016 at 9:54 AM, Mark <wendt.m...@gmail.com> wrote:
> On 10/25/2016 12:16 PM, Nicklas Karlsson wrote:
>>> True dat.  But why take the chance and not use a direct connection with
>>> a cross-over cable?  Typical UDP traffic in a switched LAN is fairly
>>> fast but not necessarily totally reliable.  And over the years I've seen
>>> plenty of collisions on a switched network for both TCP and UDP.  The
>>> difference being TCP has error correction and will resend the packet.
>> The most usual in real time systems is packets are sent periodically and 
>> receiver know it will receive packets. If bandwidth should be used to the 
>> limit UDP is a better choice but with plenty of bandwidth left over TCP 
>> might be a better choice.
>>
>> Then I do real time systems usually I tolerate some lost packets. Usually 
>> the old value is not useful then new value is received but if there is 
>> enough time request resend would be good.
>>
>>
>> I guess the answer is it depend on available bandwidth and delay. You also 
>> need a mechanism to queue up old data no more needed.
>>
>> In real time systems a queue is usually not good because if there is not 
>> enough time it will start grow. If newest available data is used perfomance 
>> may degrade but software will continue to run.
>>
>>
>> Nicklas Karlsson
> Under UDP, the receiver will receive packets, however under the protocol
> it doesn't know if it receives "all" the packets.  UDP is kind of a send
> and forget protocol.  If you want to make sure that all packets are
> received, the only way to go is TCP.  UDP uses less bandwidth than TCP,
> though in reality the difference is quite small.
>
> A queue is not real time.  Real time is *now* not when the queue decides
> to send.  Losing packets in a critical environment is not a good thing.
> Let's suppose a limit is hit and the controller calls for a stop in one
> packet.  Oops, that packet got dropped.  And the machine bangs into the
> physical stops.  Not a good thing.  If you are going to use UDP for
> critical situations, you're best off using a direct connect, getting rid
> of the latency of the LAN and talking directly to the Mesa card.
>
> Mark
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to