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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list