On 10/25/2016 01:46 PM, Chris Albertson wrote: > 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.
Your machine, your money. Do what you wish. What looks good in theory doesn't always hold true in practice. Been there, done that for almost the last 30 years as a system and network admin. For the price of a dual NIC card and a crossover cable vs a relatively expensive switch which minimizes but doesn't eliminate the collision problem as I and others have pointed out, I know which direction I'd go. Packet length and bandwidth do not eliminate collisions. They happen on a network. If you are going to use UDP for a critical function, then you need to find a way to practically eliminate the chance of that happening. The reliability of depending on a switched network versus a direct connection from the computer's NIC to the device isn't even close. You are already going to have the issue of what's on the back side of the ethernet port on the ARM SBC whether you use a switch or a direct connection. Now you've added another layer between the computer and the device. Ever have a switch hiccup while nothing else in the network does? Kinda tuff for a crossover patch cord to hiccup unless it's damaged. Correct - not very much data is being passed around if it's only UDP. Toss in TCP to the mix, along with other stuff, and you can end up with a relatively busy network. You do realize layer three switches route too, right? Guaranteed slower to route that traffic than the traffic being done on the NIC. Lookup table on a dual NIC is usually smaller than the one on the layer three switch. Is the ethernet controlled by the RTOS for machine control? If so, the mouse, keyboard and any other extraneous interrupts should be handled under that. There's a reason for some of those "old wive's tales." In this case, they are true. ------------------------------------------------------------------------------ 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
