[PD] JACK affects UDP rate

[Roman Haefeli]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210728/019d7862/attachment.sig>