3

I am using tcpdump to capture UDP packets and analyze network latency between a UDP broadcaster and my server. To calculate latency I compare the source host timestamps reported in UDP application data to the tcpdump local "kernel" timestamps.

The two server clocks are synchronized to millisecond precision and a latency of up to 2 or 3 milliseconds is acceptable. My machine is a dual 6 cores Intel X5670 @2.93Ghz with 10Gb Mellanox NICs and coalescing disabled.

The problem is that I am observing greater than 10 milliseconds delay between the 2 hosts when data frequency picks up, although always well below the 10Gb bandwidth. I have 5 tcpdump jobs running at the same time as:

tcpdump -c 0 chrt -f 80 -q -i eth1 net 232.xxx.xxx.xxx and udp port 22456 -s 0 -w myfile

I had better success in the past writing my own dump program with 2 threads: one high priority network reader thread and a low priority disk writer asynchronous thread, but I'd really like to use a standard linux solution this time.

What can I do to minimize the tcpdump UDP read delay?

Robert Kubrick
  • 143
  • 1
  • 7

1 Answers1

4

I would suggest you try to renice the tcpdump process , and dump the trace to a file on a tmpfs filesystem Also you can add the -p option to tcpdump in order to not put the interface in promiscuous mode, which might reduce the parasitic traffic.

  mkdir /tmpfs
  mount -t tmpfs -o size=128m none /tmpfs
  nice -n -10 tcpdump ... -w /tmpfs/yourfile
Olivier S
  • 2,739
  • 1
  • 14
  • 14
  • Can you capture broadcast traffic without promiscuous mode? Apart from that **/dev/shm** should be already mounted with tmpfs. – Nils Jan 28 '12 at 20:37
  • thanks, will try this. Any reason why 'nice -n -10' would be more efficient than 'chrt -f 80'? – Robert Kubrick Jan 28 '12 at 23:51
  • I did not see the chrt, you are right, adujsting a real time priority is certainly more efficient than the nice -n 10. – Olivier S Jan 29 '12 at 07:42