Gary Lee Nelson

I have two machines connect via an Airport hub. The hub is connected to

Road Runner from Time Warner. I am sending very simple messages of the form

I am send them one per second and finding that 1 out of 20-30 messages is

I have also tried a computer-to-computer link using the built-in Airport

cards. Same deal. I don't think it is network latency because the messages

should not be leaving my house in any case. The IP addresses are all

Perhaps I missed a thread but are their known issues with udpsend/receive?

I have two machines connect via an Airport hub.  The hub is connected to
Road Runner from Time Warner.  I am sending very simple messages of the form

I am send them one per second and finding that 1 out of 20-30 messages is
dropped.

I have also tried a computer-to-computer link using the built-in Airport
cards.  Same deal.  I don't think it is network latency because the messages
should not be leaving my house in any case.  The IP addresses are all
10.0.1.x.

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

udpsend-and-udpreceive-dropping-messages

I get something similar. That is, every once in a while i receive a

message that my message sent through udp has been delayed 16 or 17

msec. I haven't actually tested that they are not getting there, but I

have latencies i have to optimize all over the place, Olaf Mathes

wrote at some point that the object was complaining too much.

Don't know if this helps, but if anyone knows why this is happening

i'd love to get rid of those occasional 17 msecs...

> I have two machines connect via an Airport hub. The hub is connected to

> Road Runner from Time Warner. I am sending very simple messages of the form

> I am send them one per second and finding that 1 out of 20-30 messages is

> I have also tried a computer-to-computer link using the built-in Airport

> cards. Same deal. I don't think it is network latency because the messages

> should not be leaving my house in any case. The IP addresses are all

> Perhaps I missed a thread but are their known issues with udpsend/receive?

I get something similar. That is, every once in a while i receive a
message that my message sent through udp has been delayed 16 or 17
msec. I haven't actually tested that they are not getting there, but I
have latencies i have to optimize all over the place, Olaf Mathes
wrote at some point that the object was complaining too much.

Don't know if this helps, but if anyone knows why this is happening
i'd love to get rid of those occasional 17 msecs...

On 3/19/07, Gary Lee Nelson  wrote:
> I have two machines connect via an Airport hub.  The hub is connected to
> Road Runner from Time Warner.  I am sending very simple messages of the form
>
> n 60 96 1000 1 (note pit vel dur chan)
>
> I am send them one per second and finding that 1 out of 20-30 messages is
> dropped.
>
> I have also tried a computer-to-computer link using the built-in Airport
> cards.  Same deal.  I don't think it is network latency because the messages
> should not be leaving my house in any case.  The IP addresses are all
> 10.0.1.x.
>
> Perhaps I missed a thread but are their known issues with udpsend/receive?
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
>
>


> I get something similar. That is, every once in a while i receive a

> message that my message sent through udp has been delayed 16 or 17

> msec. I haven't actually tested that they are not getting there, but I

> have latencies i have to optimize all over the place, Olaf Mathes

> wrote at some point that the object was complaining too much.

Well, bur Gary was talking about udpsend and udpreceive and not 

> Don't know if this helps, but if anyone knows why this is happening

> i'd love to get rid of those occasional 17 msecs...

I oculd compile you a version that just doesn't warn you but would block 

anyway if this makes you sleep any better. :-)

Jaime Oliver wrote:
> Hi Gary
>
> I get something similar. That is, every once in a while i receive a
> message that my message sent through udp has been delayed 16 or 17
> msec. I haven't actually tested that they are not getting there, but I
> have latencies i have to optimize all over the place, Olaf Mathes
> wrote at some point that the object was complaining too much.

Well, bur Gary was talking about udpsend and udpreceive and not 
netsend/netreceive.

> Don't know if this helps, but if anyone knows why this is happening
> i'd love to get rid of those occasional 17 msecs...

I oculd compile you a version that just doesn't warn you but would block 
anyway if this makes you sleep any better. :-)

thank you for the offer, but I'll survive with those 17msecs and

prefer to be warned, its just that i'm not sure if it's actually doing

> > I get something similar. That is, every once in a while i receive a

> > message that my message sent through udp has been delayed 16 or 17

> > msec. I haven't actually tested that they are not getting there, but I

> > have latencies i have to optimize all over the place, Olaf Mathes

> > wrote at some point that the object was complaining too much.

> Well, bur Gary was talking about udpsend and udpreceive and not

> > Don't know if this helps, but if anyone knows why this is happening

> > i'd love to get rid of those occasional 17 msecs...

> I oculd compile you a version that just doesn't warn you but would block

> anyway if this makes you sleep any better. :-)

thank you for the offer, but I'll survive with those 17msecs and
prefer to be warned, its just that i'm not sure if it's actually doing
it, so i suppose that is good!!

On 3/19/07, Olaf Matthes  wrote:
> Jaime Oliver wrote:
> > Hi Gary
> >
> > I get something similar. That is, every once in a while i receive a
> > message that my message sent through udp has been delayed 16 or 17
> > msec. I haven't actually tested that they are not getting there, but I
> > have latencies i have to optimize all over the place, Olaf Mathes
> > wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not
> netsend/netreceive.
>
> Olaf
>
> > Don't know if this helps, but if anyone knows why this is happening
> > i'd love to get rid of those occasional 17 msecs...
>
> I oculd compile you a version that just doesn't warn you but would block
> anyway if this makes you sleep any better. :-)
>
> Olaf
>


I just tried jit.net.send/recv and net.maxhole. Both are much worse than

udpsend/receive. The later at least keeps tempo. Just leaves note out now

On 3/19/07 3:03 PM, "Olaf Matthes" wrote:

>> I get something similar. That is, every once in a while i receive a

>> message that my message sent through udp has been delayed 16 or 17

>> msec. I haven't actually tested that they are not getting there, but I

>> have latencies i have to optimize all over the place, Olaf Mathes

>> wrote at some point that the object was complaining too much.

>> Don't know if this helps, but if anyone knows why this is happening

>> i'd love to get rid of those occasional 17 msecs...

I just tried jit.net.send/recv and net.maxhole.  Both are much worse than
udpsend/receive.  The later at least keeps tempo.  Just leaves note out now
and then.  Should I try netsend/receive?

On 3/19/07 3:03 PM, "Olaf Matthes"  wrote:

> Jaime Oliver wrote:
>> Hi Gary
>>
>> I get something similar. That is, every once in a while i receive a
>> message that my message sent through udp has been delayed 16 or 17
>> msec. I haven't actually tested that they are not getting there, but I
>> have latencies i have to optimize all over the place, Olaf Mathes
>> wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not
> netsend/netreceive.
>
> Olaf
>
>> Don't know if this helps, but if anyone knows why this is happening
>> i'd love to get rid of those occasional 17 msecs...
>
> I oculd compile you a version that just doesn't warn you but would block
> anyway if this makes you sleep any better. :-)
>
> Olaf

I suppose this is slightly off-topic. Has anyone added an outlet to udpsend? This is really necessary when requesting information from SuperCollider's scsynth.

>From the SuperCollider command reference:

/notify                    register to receive notifications from server

    int - one to receive notifications, zero to stop receiving them.

If argument is one, server will remember your return address and send you notifications. if argument is zero, server will stop sending you notifications.

The "return address" that the documentation refers to is the ip and port of the original /notify command. Thus the client to scsynth must read as well as write to the same port. Since it is not possible to simultaneously bind udpsend and udpreceive to the same port (at least the last time I tried), there's no way to get information from scsynth via the /notify command...

> Subject: Re: [maxmsp] Udpsend and udpreceive dropping messages

> Well, bur Gary was talking about udpsend and udpreceive and not 

> I oculd compile you a version that just doesn't warn you but would 

> block anyway if this makes you sleep any better. :-)

/notify					register to receive notifications from server
	int - one to receive notifications, zero to stop receiving them.

If argument is one, server will remember your return address and send you notifications. if argument is zero, server will stop sending you notifications. 

> ----- Original Message -----
> From: "Olaf Matthes" 
> Subject: Re: [maxmsp] Udpsend and udpreceive dropping messages
> Date: Mon, 19 Mar 2007 20:03:16 +0100
>
>
> Jaime Oliver wrote:
> > Hi Gary
> >
> > I get something similar. That is, every once in a while i receive a
> > message that my message sent through udp has been delayed 16 or 17
> > msec. I haven't actually tested that they are not getting there, but I
> > have latencies i have to optimize all over the place, Olaf Mathes
> > wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not 
> netsend/netreceive.
>
> Olaf
>
> > Don't know if this helps, but if anyone knows why this is happening
> > i'd love to get rid of those occasional 17 msecs...
>
> I oculd compile you a version that just doesn't warn you but would 
> block anyway if this makes you sleep any better. :-)
>
> Olaf

besides that ocassional delay it works very well, i think you should

try it... let me know which one works better for you.

> I just tried jit.net.send/recv and net.maxhole. Both are much worse than

> udpsend/receive. The later at least keeps tempo. Just leaves note out now

> and then. Should I try netsend/receive?

> On 3/19/07 3:03 PM, "Olaf Matthes" wrote:

> >> I get something similar. That is, every once in a while i receive a

> >> message that my message sent through udp has been delayed 16 or 17

> >> msec. I haven't actually tested that they are not getting there, but I

> >> have latencies i have to optimize all over the place, Olaf Mathes

> >> wrote at some point that the object was complaining too much.

> > Well, bur Gary was talking about udpsend and udpreceive and not

> >> Don't know if this helps, but if anyone knows why this is happening

> >> i'd love to get rid of those occasional 17 msecs...

> > I oculd compile you a version that just doesn't warn you but would block

> > anyway if this makes you sleep any better. :-)

besides that ocassional delay it works very well, i think you should
try it... let me know which one works better for you.

On 3/19/07, Gary Lee Nelson  wrote:
> I just tried jit.net.send/recv and net.maxhole.  Both are much worse than
> udpsend/receive.  The later at least keeps tempo.  Just leaves note out now
> and then.  Should I try netsend/receive?
>
>
>
>
> On 3/19/07 3:03 PM, "Olaf Matthes"  wrote:
>
> > Jaime Oliver wrote:
> >> Hi Gary
> >>
> >> I get something similar. That is, every once in a while i receive a
> >> message that my message sent through udp has been delayed 16 or 17
> >> msec. I haven't actually tested that they are not getting there, but I
> >> have latencies i have to optimize all over the place, Olaf Mathes
> >> wrote at some point that the object was complaining too much.
> >
> > Well, bur Gary was talking about udpsend and udpreceive and not
> > netsend/netreceive.
> >
> > Olaf
> >
> >> Don't know if this helps, but if anyone knows why this is happening
> >> i'd love to get rid of those occasional 17 msecs...
> >
> > I oculd compile you a version that just doesn't warn you but would block
> > anyway if this makes you sleep any better. :-)
> >
> > Olaf
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
>
>


I just did a benchmark on udpsend/receive. I am sending messages like these

n 60 64 250 1 (for makenote in the receiver)

Every 250 ms. I am measuring the interval between the arrival of messages

and find +/- 5-6 ms deviation. Pretty good considering most conductors are

happy with 50 ms. Still, it's the dropped notes that are bothering me. I

put counters on both ends and find that 4-5 notes are dropped out of a

thousand sent sigly at 250 ms intervals. Again, pretty good considering

that guy on the tird stand in the second violin section.

Where do I get netsend/receive? I'll be happy to run a comparison. Is it

UB? One of my machines in Intel and the other is PPC. Both Max 4.6.

On 3/19/07 4:06 PM, "Jaime Oliver" wrote:

> besides that ocassional delay it works very well, i think you should

> try it... let me know which one works better for you.

>> I just tried jit.net.send/recv and net.maxhole. Both are much worse than

>> udpsend/receive. The later at least keeps tempo. Just leaves note out now

>> and then. Should I try netsend/receive?

>> On 3/19/07 3:03 PM, "Olaf Matthes" wrote:

>>>> I get something similar. That is, every once in a while i receive a

>>>> message that my message sent through udp has been delayed 16 or 17

>>>> msec. I haven't actually tested that they are not getting there, but I

>>>> have latencies i have to optimize all over the place, Olaf Mathes

>>>> wrote at some point that the object was complaining too much.

>>> Well, bur Gary was talking about udpsend and udpreceive and not

>>>> Don't know if this helps, but if anyone knows why this is happening

>>>> i'd love to get rid of those occasional 17 msecs...

>>> I oculd compile you a version that just doesn't warn you but would block

>>> anyway if this makes you sleep any better. :-)

I just did a benchmark on udpsend/receive.  I am sending messages like these

Every 250 ms.  I am measuring the interval between the arrival of messages
and find +/- 5-6 ms deviation.  Pretty good considering most conductors are
happy with 50 ms.  Still, it's the dropped notes that are bothering me.  I
put counters on both ends and find that 4-5 notes are dropped out of a
thousand sent sigly at 250 ms intervals.  Again, pretty good considering
that guy on the tird stand in the second violin section.

Where do I get netsend/receive?  I'll be happy to run a comparison. Is it
UB?  One of my machines in Intel and the other is PPC.  Both Max 4.6.

On 3/19/07 4:06 PM, "Jaime Oliver"  wrote:

> besides that ocassional delay it works very well, i think you should
> try it... let me know which one works better for you.
>
> J
>
> On 3/19/07, Gary Lee Nelson  wrote:
>> I just tried jit.net.send/recv and net.maxhole.  Both are much worse than
>> udpsend/receive.  The later at least keeps tempo.  Just leaves note out now
>> and then.  Should I try netsend/receive?
>>
>>
>>
>>
>> On 3/19/07 3:03 PM, "Olaf Matthes"  wrote:
>>
>>> Jaime Oliver wrote:
>>>> Hi Gary
>>>>
>>>> I get something similar. That is, every once in a while i receive a
>>>> message that my message sent through udp has been delayed 16 or 17
>>>> msec. I haven't actually tested that they are not getting there, but I
>>>> have latencies i have to optimize all over the place, Olaf Mathes
>>>> wrote at some point that the object was complaining too much.
>>>
>>> Well, bur Gary was talking about udpsend and udpreceive and not
>>> netsend/netreceive.
>>>
>>> Olaf
>>>
>>>> Don't know if this helps, but if anyone knows why this is happening
>>>> i'd love to get rid of those occasional 17 msecs...
>>>
>>> I oculd compile you a version that just doesn't warn you but would block
>>> anyway if this makes you sleep any better. :-)
>>>
>>> Olaf
>>
>>
>> Cheers
>> Gary Lee Nelson
>> Oberlin College
>> www.timara.oberlin.edu/GaryLeeNelson
>>
>>
>>

On 19 mars 07, at 21:51, Gary Lee Nelson wrote:

> I just did a benchmark on udpsend/receive. I am sending messages 

> n 60 64 250 1 (for makenote in the receiver)

> Every 250 ms. I am measuring the interval between the arrival of 

> and find +/- 5-6 ms deviation. Pretty good considering most 

> happy with 50 ms. Still, it's the dropped notes that are bothering 

> put counters on both ends and find that 4-5 notes are dropped out of a

> thousand sent sigly at 250 ms intervals. Again, pretty good 

> that guy on the tird stand in the second violin section.

- if you want better timing, using an Ethernet cable will help a lot! 

I know it's sometimes difficult, but you'll really get better 

- UDP may lost packets. Using TCP is much better when you need to be 

sure that the data arrives (You may have a look to [mxj net.tcp.send] 

> I just did a benchmark on udpsend/receive.  I am sending messages  
> like these
>
> n 60 64 250 1 (for makenote in the receiver)
>
> Every 250 ms.  I am measuring the interval between the arrival of  
> messages
> and find +/- 5-6 ms deviation.  Pretty good considering most  
> conductors are
> happy with 50 ms.  Still, it's the dropped notes that are bothering  
> me.  I
> put counters on both ends and find that 4-5 notes are dropped out of a
> thousand sent sigly at 250 ms intervals.  Again, pretty good  
> considering
> that guy on the tird stand in the second violin section.

I've too remarks:
- if you want better timing, using an Ethernet cable will help a lot!  
I know it's sometimes difficult, but you'll really get better  
performances
- UDP may lost packets. Using TCP is much better when you need to be  
sure that the data arrives (You may have a look to [mxj net.tcp.send]  
and [mxj net.tcp.recv]).

On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:

> I am send them one per second and finding that 1 out of 20-30 

...which is exactly what it says on the tin. UDP does not guarantee 

delivery (nor does it guarantee that the same transmitted packet will 

I've never noticed UDP packets being dropped when doing OSC-over-UDP, 

but then it's either been cabled (through decent-quality switches), 

or the OSC has been streaming sensor readings, in which case the 

occasional dropped packet doesn't matter.

If you want reliable transmission, use TCP.

> I am send them one per second and finding that 1 out of 20-30  
> messages is
> dropped.

...which is exactly what it says on the tin. UDP does not guarantee  
delivery (nor does it guarantee that the same transmitted packet will  
not arrive more than once). More info at

I've never noticed UDP packets being dropped when doing OSC-over-UDP,  
but then it's either been cabled (through decent-quality switches),  
or the OSC has been streaming sensor readings, in which case the  
occasional dropped packet doesn't matter.

so udp is faster, but tcp is more reliable??

http://www.maxobjects.com/?PHPSESSID=6b60bdf5913b5f058c95a5372eb6db02&PHPSESSID=6b60bdf5913b5f058c95a5372eb6db02&request=netsend&operateur=AND&id_plateforme=0&Submit=OK

> On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:

> > I am send them one per second and finding that 1 out of 20-30

> ...which is exactly what it says on the tin. UDP does not guarantee

> delivery (nor does it guarantee that the same transmitted packet will

> not arrive more than once). More info at

> I've never noticed UDP packets being dropped when doing OSC-over-UDP,

> but then it's either been cabled (through decent-quality switches),

> or the OSC has been streaming sensor readings, in which case the

> occasional dropped packet doesn't matter.

> If you want reliable transmission, use TCP.

On 3/19/07, Nick Rothwell  wrote:
>
> On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:
>
> > I am send them one per second and finding that 1 out of 20-30
> > messages is
> > dropped.
>
> ...which is exactly what it says on the tin. UDP does not guarantee
> delivery (nor does it guarantee that the same transmitted packet will
> not arrive more than once). More info at
>
>         http://www.faqs.org/rfcs/rfc768.html
>
> I've never noticed UDP packets being dropped when doing OSC-over-UDP,
> but then it's either been cabled (through decent-quality switches),
> or the OSC has been streaming sensor readings, in which case the
> occasional dropped packet doesn't matter.
>
> If you want reliable transmission, use TCP.
>
>         -- N.
>
>


> I just did a benchmark on udpsend/receive. I am sending messages like these

> Every 250 ms. I am measuring the interval between the arrival of messages

> and find +/- 5-6 ms deviation. Pretty good considering most conductors are

> happy with 50 ms. Still, it's the dropped notes that are bothering me. I

> thousand sent sigly at 250 ms intervals. Again, pretty good considering

others that UDP is not 100% loss-free. Use TCP if you need 100% perfect 

delivery. But the drawbackis that it will take longer to deliver the 

data since there is more communication going on between receiver and sender.

Gary Lee Nelson wrote:
> I just did a benchmark on udpsend/receive.  I am sending messages like these
>
> n 60 64 250 1 (for makenote in the receiver)
>
> Every 250 ms.  I am measuring the interval between the arrival of messages
> and find +/- 5-6 ms deviation.  Pretty good considering most conductors are
> happy with 50 ms.  Still, it's the dropped notes that are bothering me.  I
> put counters on both ends and find that 4-5 notes are dropped out of a
> thousand sent sigly at 250 ms intervals.  Again, pretty good considering
> that guy on the tird stand in the second violin section.
>
> Where do I get netsend/receive?

http://www.akustische-kunst.org/maxmsp/ - But I have to agree with the 
others that UDP is not 100% loss-free. Use TCP if you need 100% perfect 
delivery. But the drawbackis that it will take longer to deliver the 
data since there is more communication going on between receiver and sender.

>> I am send them one per second and finding that 1 out of 20-30

I'm quite surprised by the bad results described here.

I recently built for a project a system of sensors sending information over

WiFi (11g) and sending UDP packets of 70 useful bytes every 8ms (not

I programmed a 7-bit a counter on the microprocessor part that allows me to

monitor lost packets and I noticed a drop of usually less than 1 packet per

1000. Generally about only 1 per 2000, but some movements of the performer

might increase temporarily the percentage of dropped packets. This was at

about 30m distance in the concert hall, receiving with the built-in antenna

Maybe there are too many Wifi networks around and you should change the

And there are some cases where dropped packets may be an issue, even with

sensors: I do for example integrate the angular speed of gyroscopes to

_________________________________________

>
> On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:
>
>> I am send them one per second and finding that 1 out of 20-30
>> messages is
>> dropped.
>
> ...which is exactly what it says on the tin. UDP does not guarantee
> delivery (nor does it guarantee that the same transmitted packet will
> not arrive more than once). More info at
>
> http://www.faqs.org/rfcs/rfc768.html
>
> I've never noticed UDP packets being dropped when doing OSC-over-UDP,
> but then it's either been cabled (through decent-quality switches),
> or the OSC has been streaming sensor readings, in which case the
> occasional dropped packet doesn't matter.
I'm quite surprised by the bad results described here.
I recently built for a project a system of sensors sending information over
WiFi (11g) and sending UDP packets of 70 useful bytes every 8ms (not
counting header and checksum).
I programmed a 7-bit a counter on the microprocessor part that allows me to
monitor lost packets and I noticed a drop of usually less than 1 packet per
1000. Generally about only 1 per 2000, but some movements of the performer
might increase temporarily the percentage of dropped packets. This was at
about 30m distance in the concert hall, receiving with the built-in antenna
of my Alu G4 1.5 GHz.
Maybe there are too many Wifi networks around and you should change the
channel of your Wifi network?

And there are some cases where dropped packets may be an issue, even with
sensors: I do for example integrate the angular speed of gyroscopes to
compute the angular position...

Best,
Todor
_________________________________________
Web: http://compositeurs.be/Todoroff.html


Thanks ej. Your two remarks were right on. I did have a look at [mxj