recvfrom() takes 20 ms to return?

pingswept · 05-23-2004, 07:15 PM

I'm writing a server which uses recvfrom() to read UDP packets. Each call to recvfrom() takes 20 ms to execute, even though I can ping the same interface and get a response in less than 1 ms.

The packets I am receiving frequently have bad checksums-- I suspect this may be what is causing the delay.

On to the question: how can I speed up recvfrom(), or at least disable checksumming to see if that makes a difference?

I'm writing in C on OpenBSD 3.4. I could also try it on Linux if it would make a difference.

Mara · 05-24-2004, 02:33 PM

From 'man recvfrom':

Quote:

If no messages are available at the socket, the receive calls wait for
a message to arrive, unless the socket is nonblocking (see fcntl(2)) in
which case the value -1 is returned and the external variable errno set
to EAGAIN.

I'd make it nonblocking and see what's the result. But if there are many packets comming you may come to scalability problems as shown in this test: http://bulk.fefe.de/scalability/. If you don't have all patches installed, do it.

pingswept · 05-25-2004, 03:03 AM

Unfortunately, I already have the socket set to non-blocking.

From the graphs you linked to, it looks like OpenBSD doesn't do so well with socket() or bind(), but I'm not sure how that relates to recvfrom().

I still have the suspicion that some error is occurring, followed by a 20 ms timeout.

In any case, I tried rewriting the server using libpcap, and it is faster. The latency is all over the map, but on average its 5 times faster than recvfrom(). Weird.

itsme86 · 05-25-2004, 03:18 AM

Do you have a loop with select() in it then? Maybe with a 20ms timeout? Maybe you don't have all the descriptors that you need added to FDSET. Or maybe your first arg to select() isn't correct (should be the highest descriptor +1).

Are you sure it's spending that entire 20ms inside recvfrom()?