Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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?

share|improve this question

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
share|improve this answer
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 7:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.