Hi,
If I send a few hundreds packed OSC messages with [udpsend], it blocks for about 100-200 milliseconds or more (I see the message "udpsend blocked for xxx milliseconds" in the console, and I notice the effects).
I know that this is a lot of messages and I can (and have to) optimize things by avoiding sending unnecessary data, but:
I have replaced [udpsend] with a [netsend 1] (this is by no means a workaround, just a test to compare performance) and if I send the very same messages (which actually means sending much more bytes), netsend does _not_ block for such a long time. It doesn't print any such message (and netsend does print it if it blocks for a significant time) and I don't notice any delay. I have verified that it is actually sending the data.
So I wonder, is there an intrinsic reason why udspend takes much more time than netsend to send a certainly smaller amount of data? Or is udpsend simply implemented in a less efficient way? Does anybody know where the bottleneck is and if there is a way to eliminate it?
thanks m.
On 2011-05-08 13:48, Matteo Sisti Sette wrote:
Hi,
If I send a few hundreds packed OSC messages with [udpsend], it blocks for about 100-200 milliseconds or more (I see the message "udpsend blocked for xxx milliseconds" in the console, and I notice the effects).
I know that this is a lot of messages and I can (and have to) optimize things by avoiding sending unnecessary data, but:
I have replaced [udpsend] with a [netsend 1] (this is by no means a workaround, just a test to compare performance) and if I send the very same messages (which actually means sending much more bytes), netsend does _not_ block for such a long time. It doesn't print any such message (and netsend does print it if it blocks for a significant time) and I don't notice any delay. I have verified that it is actually sending the data.
So I wonder, is there an intrinsic reason why udspend takes much more time than netsend to send a certainly smaller amount of data? Or is udpsend simply implemented in a less efficient way? Does anybody know where the bottleneck is and if there is a way to eliminate it?
[udpsend] uses almost the same code as [netsend] to send the data. I guess the bottleneck is in the way you load the hundreds of messages into [udpsend]. Are you receiving one packet per message at the other end?
Martin
On 05/09/2011 04:54 AM, Martin Peach wrote:
[udpsend] uses almost the same code as [netsend] to send the data. I guess the bottleneck is in the way you load the hundreds of messages into [udpsend]. Are you receiving one packet per message at the other end?
What do you mean by one packet per message?
On 2011-05-09 01:45, Matteo Sisti Sette wrote:
On 05/09/2011 04:54 AM, Martin Peach wrote:
[udpsend] uses almost the same code as [netsend] to send the data. I guess the bottleneck is in the way you load the hundreds of messages into [udpsend]. Are you receiving one packet per message at the other end?
What do you mean by one packet per message?
If you send a message through [udpsend] it will be packaged into a UDP packet. A UDP packet can be up to 32768 bytes. Sending lots of small packets adds a lot of overhead compared to sending the same data as one packet.
Martin
If you send a message through [udpsend] it will be packaged into a UDP packet. A UDP packet can be up to 32768 bytes. Sending lots of small packets adds a lot of overhead compared to sending the same data as one packet.
Ah, ok. Yes, I am sending each message in a separate packet (I have no choice since these are OSC messages that I send to an iPad that runs touchosc).
Anyway that applies equally to udpsend and to [netsend 1], doesn't it? So it still doesn't explain why udpsend blocks for a much longer time...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-05-08 19:48, Matteo Sisti Sette wrote:
Hi,
If I send a few hundreds packed OSC messages with [udpsend], it blocks for about 100-200 milliseconds or more (I see the message "udpsend blocked for xxx milliseconds" in the console, and I notice the effects).
hi.
you could try iemnet's implementation of [udpsend] as this is specifically targetted at doing a better job when sending/receiving large number of data. apart from that it should be quite compatible with mrpeach's implementation.
fmgard IOhannes
Some follow-up on this:
- By bundling the data into few large packets instead of many small
packets (hence decreasing the overhead), indeed the blocking occurs much less frequently as Martin suggested, though it still occasionally occurs every once in a while. I am sending an OSC bundle of 100 osc messages every 20 milliseconds. This means less than 10 kB per packet, a packet every 20 milliseconds. It occasionally blocks for more than 2000 milliseconds
- The exact same bundle of OSC messages (i.e. the exact same UDP
packet to be sent) sometimes blocks and sometimes (most of the time) doesn't block, randomly.
you could try iemnet's implementation of [udpsend] as this is specifically targetted at doing a better job when sending/receiving large number of data.
Thank you, I'll give it a try
On 2011-05-12 07:59, matteo sisti sette wrote:
Some follow-up on this:
- By bundling the data into few large packets instead of many small
packets (hence decreasing the overhead), indeed the blocking occurs much less frequently as Martin suggested, though it still occasionally occurs every once in a while. I am sending an OSC bundle of 100 osc messages every 20 milliseconds. This means less than 10 kB per packet, a packet every 20 milliseconds. It occasionally blocks for more than 2000 milliseconds
- The exact same bundle of OSC messages (i.e. the exact same UDP
packet to be sent) sometimes blocks and sometimes (most of the time) doesn't block, randomly.
Is this a wired connection? Does it still do that if you send to 127.0.0.1? (Just trying to figure out where it's blocking.)
Martin
-
IOhannes m zmoelnig -
Martin Peach -
Matteo Sisti Sette -
matteo sisti sette