I have a setup wherein one "master" Linux system communicates with 3 "slave" systems also running Linux on a dedicated Ethernet interface(just the master & the 3 slaves). The slaves send data to the master via UDP every 5 ms or so. In addition, the master has apps that continuously pull files from all 3 slaves via FTP, SCP, etc. protocols.

The UDP packets need to be collected by the master as fast as possible, preferably within 3-4 ms. When I run the setup with just the UDP reception app running on the master, I see that this condition is easily met. However, when the FTP/SCP/etc. apps are also left running, there are spikes in the reception time. The size of the files being transferred is pretty less but a new file is retrieved from each slave about every second or so.

The fact that the results are good when running the setup without the file transfer apps active tells that Linux network "queuing/scheduling" seems to be giving similar priority to both UDP & the other protocols. Maybe it's even holding off UDP if a FTP is going on?

Is there a way to tell Linux (programmatically/commands) to give highest priority to UDP communication & "pause" other things like file transfer when a UDP message is ready for reception?

  • If I'm not mistaken the issue you could have from that description is that usually tcp is used on scp/ftp. So it could be that your tcp connection is causing packages being dropped that are coming in over udp. Why don't you check what's acutally happening with wireshark? Are your apps using the same ports for the udp connection as does ftp/scp? – Ziazis Oct 19 '17 at 10:49
  • I did check for packet drops & no, there weren't any. The UDP app too has logic to check if it lost a packet & it doesn't see any either. The problem is that it gets the packets but they're delayed when compared to the scenario wherein the FTP app isn't running. I'm using ports from 8880 to 8882. It seems more like Linux giving priority to FTP over UDP if the former is active when a new UDP message comes through. – John Smith Oct 19 '17 at 15:51
  • Could you have an switch fail, because if you say 3ms time it's alot in a local environment. You either have alot of firewalls/routers inbetween or the switch is really bad. If you have, try connecting them directly and see if it works better that way. – Ziazis Oct 20 '17 at 6:33
  • Nope. Think of this as 4 Linux machines connected to a single network switch. The connection is pretty good. No issues there. As I said, without the FTP process running, the UDP process has no delay problems. I'm now looking at the Linux traffic control option. lartc.org/howto . I think this might be with the way different types of traffic (UDP, FTP, etc.) is treated by Linux internally. – John Smith Oct 22 '17 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.