Hello,

I have a doubt about how the Linux kernel manages UDP sockets. I'm actually using an embedded Linux distribution (OpenWrt; I was actually redirected from their forums to a more Linux kernel related forum) with kernel 4.14.63, but the same behavior can be obsverved also on Linux equipped notebooks communicating over a wireless network.

In particular, I wrote a C application using sockets to periodically send UDP datagrams out (and a corresponding receiver application).

When sending data over the socket I can use sendto() or write(). I noticed that if I try to write over a full UDP buffer (for instance if I try to write too much data with respect to what the wireless network can deliver), these calls are actually blocking my application.

But the question is: how long does the blocking time last? As far as I was able to observe, these calls seems to block for much more time with respect to what is required to free the space for a single packet, letting the buffer get emptied much more. This seeems to influence the packet drop in the kernel, before the WNIC, when trying to offer a large amount of data.

Does this depend on the Linux kernel scheduler? Does it depend on internal operations that copy packets from the UDP buffer towards the WNIC, maybe in blocks only?

The same behavior was also observed, in a better manner, when using the network measurement program iPerf: when sending UDP packets of 1470 B each, I observed that a write() in front of a full buffer would block for much more time, allowing to free up space for around 159.64 KB!

Moreover, setting a reasonable timeout on the socket seems to make the write() call block for less time (depending on the timeout value), since the timeout seems to actually expire, but without generating any error, as, at the expiration time instant, the space for way more than one packet was freed up.

Do you know why this is happening? Is it possible to have a write() which is unblocked without generating any error when the related timeout expires (as it seems to happen)?

Thank you very much in advance.

It sounds like the the buffer is running out of space. You can try to increase the buffer tcpdump -B size-here-in-kilobytes.

Sorry, probably I explained my doubt is an unclear manner... my doubt is actually not whether the buffer runs out of space or not (I know that it should run out of space since I'm offering too much traffic with respect to what my WNIC can physically manage - for instance with a 3 Mbit/s modulation I'm trying to offer 10 Mbit/s) but it is related to better undestand what happens when a write() call is invoked in front of a buffer without any space left: how much time does it block? Why 159.64 KB are freed up during the block time, when each packet has only 1470 B inside (at least when using UDP)? Is it possible that a timeout set on the socket expires without any kind of error just beacuse, when it expires, there's enough free space on the buffer for a 1470 B packet?

Thank you for you reply, anyway!

I got ya. I wasn't aware of the kernel performing a timeout. I thought the timeout you were referring to was the buffer running out of space.

Yes, I actually meant the time in which the application is blocked (due to the blocking write()) when it encounters a full buffer (it blocks for much more time with respect to the one needed to free up the memory for a single packet, as far as I understood, but I don't know the exact factors, inside the kernel, that are influencing this "blocking time"). Then, if I set a reasonable socket timeout (for instance with SO_SNDTIMEO in setsockopt()), I noticed that this time seems to be reduced, but without ever getting any error when it expires, probably due to the fact that the buffer is still freed up for more than the space a single packet would require?