Hi, there. I'm working with MobMuPlat in Android and PureData in Linux. I use my MEH-SYSTEM (*1) and I'm having issues with packets loss.
A buddy from a group suggested me to send "bursts of packets" instead only one packet... considering this packet as important. So, I imagine, if I send 10 messages with an unique ID (*2), instead of only one... I would know that even one message will arrive.
I never worked with "bursts of packets"... not even understand well this type of messages.
Could someone explain it to me... and/or give me some examples/patchs of how to do this?
Thank you very much.
PD: I'm using tablet to be wireless. That's the point.
(*1): http://mariomey.com.ar/show/meh-system/ (*2): I imagine a random number to be send with the message. If it arrives and then, it arrives again with the same number, it will be blocked... Any other technique?
Hi Mario,
On 18/02/16 05:07, Mario Mey wrote:
A buddy from a group suggested me to send "bursts of packets" instead only one packet... considering this packet as important.
If you need guaranteed, ordered delivery from one machine to another then you should use TCP sockets instead of UDP sockets. Since you seem to be sending directly between two machines this is ideal. In Pd it is trivial to set up a TCP connection with [netsend] and [netreceive]. TCP has slightly larger overhead than UDP because of the ACKs but I think over WiFi you will not notice the difference.
Cheers,
Chris.
On 18/02/16 07:33, Chris McCormick wrote:
On 18/02/16 05:07, Mario Mey wrote:
A buddy from a group suggested me to send "bursts of packets" instead only one packet... considering this packet as important.
If you need guaranteed, ordered delivery from one machine to another then you should use TCP sockets instead of UDP sockets. Since you seem to be sending directly between two machines this is ideal. In Pd it is trivial to set up a TCP connection with [netsend] and [netreceive]. TCP has slightly larger overhead than UDP because of the ACKs but I think over WiFi you will not notice the difference.
One issue with using a TCP socket is negotiating the initial connection. Pd requires you to enter the exact IP address which is a bit cumbersome, especially during set up for live performance with Pd. UDP packets on the other hand allow you to send in "broadcast" mode. If [netreceive] allowed you to obtain the source IP address of incoming broadcast packets then it would be possible to use that to negotiate a TCP connection back to the source address after doing a "discovery" broadcast & reply exchate - kind of like zeroconf/bonjour. I'll have a think about a patch to submit to Miller for accomplishing this - should be small and simple.
Cheers,
Chris.
On 2016-02-18 00:39, Chris McCormick wrote:
source address after doing a "discovery" broadcast & reply exchate - kind of like zeroconf/bonjour. I'll have a think about a patch to submit to Miller for accomplishing this - should be small and simple.
speaking of zeroconf: if the server announces it's name via zeroconf, you can also use "<hostname>.local" in the connection string. this of course only works if you know the hostname beforehand (e.g. it's not a good solution if you expect the patch to work on *any* device; but ok if it only needs to work on *those two* devices)
fgmsdr IOhannes
I read here//http://stackoverflow.com/questions/15060180/what-are-the-chances-of-losing-a... this: / /
/Packet loss happens for multiple reasons. Primarily it is caused by errors on individual links and network congestion.// Packet loss due to errors on the link is very low, when links are working properly. Less than 0.01% is not unusual.// Packet loss due to congestion obviously depends on how busy the link is. *If there is spare capacity along the entire path, this number will be 0%.* But as the network gets busy, this number will increase. When flow control is done properly, this number will not get very high. A couple of lost packets is usually enough that somebody will reduce their transmission speed enough to stop packets getting lost due to congestion./The text in bold caught my attention, because I use my router (I have a TP-LINK TL-MR3020 and a TP-LINK TL-WR841ND) only for this. Not internet, not other computer/device connected to it.
How do I config my router to do only this job and, in this way, make "spare capacity along the entire path"?
El 17/02/16 a las 20:39, Chris McCormick escribió:
On 18/02/16 07:33, Chris McCormick wrote:
On 18/02/16 05:07, Mario Mey wrote:
A buddy from a group suggested me to send "bursts of packets" instead only one packet... considering this packet as important.
If you need guaranteed, ordered delivery from one machine to another then you should use TCP sockets instead of UDP sockets. Since you seem to be sending directly between two machines this is ideal. In Pd it is trivial to set up a TCP connection with [netsend] and [netreceive]. TCP has slightly larger overhead than UDP because of the ACKs but I think over WiFi you will not notice the difference.
One issue with using a TCP socket is negotiating the initial connection. Pd requires you to enter the exact IP address which is a bit cumbersome, especially during set up for live performance with Pd. UDP packets on the other hand allow you to send in "broadcast" mode. If [netreceive] allowed you to obtain the source IP address of incoming broadcast packets then it would be possible to use that to negotiate a TCP connection back to the source address after doing a "discovery" broadcast & reply exchate - kind of like zeroconf/bonjour. I'll have a think about a patch to submit to Miller for accomplishing this - should be small and simple.
Cheers,
Chris.
On Thu, Feb 18, 2016 at 1:42 PM, Mario Mey mariomey@gmail.com wrote:
I read here http://stackoverflow.com/questions/15060180/what-are-the-chances-of-losing-a... this:
*Packet loss happens for multiple reasons. Primarily it is caused by errors on individual links and network congestion.*
- Packet loss due to errors on the link is very low, when links are
working properly. Less than 0.01% is not unusual.*
- Packet loss due to congestion obviously depends on how busy the link is.
If there is spare capacity along the entire path, this number will be 0%. But as the network gets busy, this number will increase. When flow control is done properly, this number will not get very high. A couple of lost packets is usually enough that somebody will reduce their transmission speed enough to stop packets getting lost due to congestion.*The text in bold caught my attention, because I use my router (I have a TP-LINK TL-MR3020 and a TP-LINK TL-WR841ND) only for this. Not internet, not other computer/device connected to it.
How do I config my router to do only this job and, in this way, make "spare capacity along the entire path"?
With WiFi, it's radio so there are usually other transmitters around which may reduce your bandwidth if they are on the same channel. You might be able to change the channel you are on to get better throughput. The user guide for the TL-MR3020 has this: Channel
- This field determines which operating frequency will be used. It is not
necessary to change the wireless channel unless you notice interference problems with another nearby access point. If you select auto, then the AP will select the best channel automatically.
Martin
El 18/02/16 a las 16:23, Martin Peach escribió:
With WiFi, it's radio so there are usually other transmitters around which may reduce your bandwidth if they are on the same channel. You might be able to change the channel you are on to get better throughput.
Martin, you made me learn about channels. One of the pages I saw was http://www.howtogeek.com/197268/how-to-find-the-best-wi-fi-channel-for-your-.... I relized that my router were one in channel 4 and the other in "auto" (*). 4 is not a good channel at all, neither "auto". In terminal I've got:
mario@circo3d:~$ sudo iwlist wlan0 scan | grep (Channel Frequency:2.427 GHz (Channel 4) Frequency:2.462 GHz (Channel 11) Frequency:2.462 GHz (Channel 11) Frequency:2.412 GHz (Channel 1) Frequency:2.462 GHz (Channel 11) Frequency:2.462 GHz (Channel 11) Frequency:2.437 GHz (Channel 6) Frequency:2.462 GHz (Channel 11)
So, the possible channels were 1 and 6. Then, I changed them one to 1, the other to 6. I'll test them tomorrow.
Thanks for the tip!
(*): I have 2 routers, but I use one at a time ;)
This night I'll start doing my spectacle again (the last perform like this was two years ago), where I use my MEH-SYSTEM. So... I don't have time to do some TCP tests right now...
However, I did a some of them! (anxiety) With no luck, no success. I have to use the MobMuPlat version that Daniel Iglesia sent me that can handle netreceive, netsend, oscparce and oscformat. But, as I said before, no success: I had some errors at the console. I maybe go on testing it tomorrow.
Now, I have some doubts about TCP:
Sometimes, when a packet is lost, some other packets are too, for a few seconds. If I send a message over TCP... I think there is guaranteed to arrive to destiny... but, if the situation is the same, will this packet arrive late? I mean, will this message wait to arrive to the server? Because, as I record/play loops... maybe it's better to lost the message and know about this... than the message arrives 1 second later.
I repeat, I didn't use the system over TCP, so there will be more tests and maybe they will resolve my doubt.
Thank you.
El 17/02/16 a las 20:33, Chris McCormick escribió:
Hi Mario,
On 18/02/16 05:07, Mario Mey wrote:
A buddy from a group suggested me to send "bursts of packets" instead only one packet... considering this packet as important.
If you need guaranteed, ordered delivery from one machine to another then you should use TCP sockets instead of UDP sockets. Since you seem to be sending directly between two machines this is ideal. In Pd it is trivial to set up a TCP connection with [netsend] and [netreceive]. TCP has slightly larger overhead than UDP because of the ACKs but I think over WiFi you will not notice the difference.
Cheers,
Chris.
-
Chris McCormick -
IOhannes m zmoelnig -
Mario Mey -
Martin Peach