<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 23.07.2021 23:11, Roman Haefeli wrote:<br>
</p>
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">When we overhauled the networking code, I noticed that the TCP and
UDP functions would both read up to N bytes (where N is currently
4096) in a single recv() call. With TCP the buffer can contain
several FUDI (or other) messages, but with UDP it would only contain
a single packet. So UDP was effectively much more rate limited than
TCP.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I think, it _does_ make sense to treat TCP and UDP differently. With
TCP, you probably want to consume only as much as you can eat at the
time while keeping the rest buffered for later. OTOH, it's questionable
whether "surplus" UDP packets should be stored for later. Rather - I
think - they should be simply discarded. </pre>
</blockquote>
<p>What do you mean with "surplus" UDP packets? It's totally natural
that the UDP receive buffer contains more than one packet at a
given time... Packets might arrive in bulks and/or several hosts
can send to the same socket. Why should we intentionally discard
them?</p>
<p>I think the fundamental problem is this: <br>
</p>
<p>We we want to<br>
</p>
<p>a) drain the UDP receive buffer as fast as possible to avoid
packet loss</p>
<p>b) avoid blocking the audio thread by processing too many
messages</p>
<p>If we only have a single thread (like in Pd), there's a conflict
of interest.<br>
</p>
<p>A better design is to receive packets on a dedicated thread and
put them on a (ideally unbounded) queue. The audio thread can then
take packets and process them at its own pace. This is what the
Supercollider Server does, for example. It is also how I
personally write UDP server applications.
<a class="moz-txt-link-freetext" href="https://github.com/pure-data/pure-data/pull/1261">https://github.com/pure-data/pure-data/pull/1261</a> also goes into
this direction. <br>
</p>
<p>---<br>
</p>
<p>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.</p>
<p>---<br>
</p>
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">It would be nice, if more than
one packet could be received per tick, of course, but then to buffer
could simply be flushed, so that only "fresh" packets are considered in
the next tick. I _think_ that's what network devices do as well: send
it now or forget it. </pre>
</blockquote>
Sorry, I don't understand this paragraph at all...
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">With blocksize=64, ideally one packet per tick is received. On macOS,
it seems each tick without a packet delays the processing of the
subsequent packets by one DSP block. After a few seconds on a bad
connection (Wifi, for instance), the delay settles at 200-500ms and
there is a very clean signal afterwards (which is not surprising with
such a large buffer). On Linux, the latency stays in the range set by
the receive buffer and late packets are perceived as drop out. It looks
like not processed packets are flushed on Linux, but are not macOS.</pre>
</blockquote>
<p>Hmmm... usually incoming UDP packets are discarded if the UDP
receive buffer is full. Are you saying that this is not the case
on macOS? That would be very interesting. Maybe the buffer can
automatically grow in size? Unfortunately, I couldn't find any
information on this.</p>
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">Assuming the relevant poll functions you mentioned are the same for the
same backend (JACK) on both platforms (macOS, Linux), why is the
behavior still different?
</pre>
</blockquote>
I guess because of the different behavior/size of the UDP receive
buffer.<br>
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">Thanks a lot, Christof, for your time and effort in explaining the
details. You already helped a lot. I'm somewhat relieved that the issue
has an explanation.</pre>
</blockquote>
You're welcome :-)<br>
<blockquote type="cite"
cite="mid:32ba64cc5c7dc1d5d89d145e33e9b2f7f11b122d.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">
Roman
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>