One second delay before tcpdump returns packets

Using Ubuntu, I'm trying to sync tcpdump sniffing with self-identifying "pings" from a client device. The problem is that getting precise starts and stops is made difficult by what looks like a built-in delay in tcpdump. Here's the key line from my script:

sudo timeout .5s tcpdump -i wlan0 -e

When I set timeout to stop tcpdump after, say, half a second (as in my example), no packets are returned. In fact, any value lower than 1.1s fails to return packets (while 1.1 and longer work wonderfully).

I've tried adding the -n argument to suppress DNS but that made no difference. I also tried this with two entirely different wifi cards (Intel Centrino and TP-Link N900) to make sure that it wasn't just a hardware "feature".

I'm not a developer, but I grep-ed the tcpdump source code for "delay", "latency", and "timeout" but nothing came up that seemed responsible.

Any ideas?

gnu coreutils timeout.c has a fallback for systems without timer_settime() - it will revert to single-second resolution:

/* timer_settime() provides potentially nanosecond resolution.
setitimer() is more portable (to Darwin for example),
but only provides microsecond resolution and thus is
a little more awkward to use with timespecs, as well as being
deprecated by POSIX.  Instead we fallback to single second
resolution provided by alarm().  */

perhaps thats your issue. i don't run ubuntu so i can't check firsthand, but for example my openbsd machine only has setitimer(), so it would only use full-second timeouts for me

--edit: on second look it still should wait atleast 1 second, unless its rounding down...or somehow tcpdump is getting an early sigterm ...and maybe there are just no packets during the interval?

Does adding -l to tcpdump options help? It makes the standard output of tcpdump line buffered, so that every line is output as soon as it is received, instead of buffering more data before output.