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
