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.
I don't have access to a Linux machine right now, but I *think* on many systems the default is much higher, something around 64 kB. You can check the system wide default receive buffer size with "sysctl net.core.rmem_default". It's possible to override it per socket with setsockopt() + SO_RCVBUF.
I see. I get:
$ sysctl net.core.rmem_default net.core.rmem_default = 212992
That is not consistent with the maximum 'lag' of 236 packets the udp- rate-test patch measures. The patch sends FUDI messages with a size 12 bytes.
Decreasing the buffer size and using the resulting packet loss as some kind of rate limiting sounds like a bad idea to me.
[...]
Thanks for the detailed explanation. I agree on all points. The thing is that if the incoming rate exceeds that processing capacity, there is no other way for a patch than to look at already quite old packets. There is no way for a patch to say: "From all available packets in the buffer, give me the most recent one".
OTOH, maybe once the incoming rate is not "artificially" limited to one-packet-per-tick anymore, this might be a non-issue.