On 28.07.2021 13:42, Roman Haefeli wrote:
On Wed, 2021-07-28 at 03:51 +0200, Christof Ressi wrote:
On Linux, the receive buffer seems to be ~4kB, you as you already stated.
Where did I state that? :-)
From: https://lists.puredata.info/pipermail/pd-list/2021-07/129893.html
"Back to TCP vs UDP: let's say you are sending 32-byte FUDI messages at a high rate. With the old behavior, TCP allowed to receive and dispatch 128 messages in a row (4096 bytes in total), but UDP only allowed a single message. For me, this didn't make any sense. With the new behavior you get the same number of messages."
I thought that 4096 bytes applied to the receive buffer of both, TCP and UDP, but that's probably not what you meant.
Yes, I was rather referring to the buffer used for the recv() call, which currently has a size of 4096 bytes. This is the limit of how many data we can receive per socket in a single sys_pollgui() / sys_microsleep() call, otherwise these functions might block indefinitely during heavy incoming network traffic. The exact value of the throttle limit is somewhat arbitrary. In practice it doesn't matter too much if the poll functions are called repeatedly, like in the portaudio backend. In the Jack backend, however, the poll function is called only once per DSP tick, so the throttle limit becomes noticable. Anyway, it is completely independent from the UDP receive buffer.
OTOH, maybe once the incoming rate is not "artificially" limited to one-packet-per-tick anymore, this might be a non-issue.
Yes, I think so too. Of course, it is still possible to flood Pd with more messages than it can handle. One thing to watch out is the combination of a large hardware buffer size and a small UDP receive buffer, because Pd might be busy computing audio for several milliseconds - during which only a few packets can be received. If many packets arrive in this time window, the UDP receive buffer can overflow, leading to packet loss.
Another potential source of temporary packet loss are long blocking operations, like reading a large file from disk, during which no packets can be received, either.
Maybe it could also be helpful to allow users to tune the UDP receive buffer size for [netsend -u] resp. [netsend -u -b]. If you had a Pd patch that expects very high incoming UDP traffic, you could then increase the buffer size accordingly.
Christof