Re: [PD] thoughts on Pd's networking framework
well .. antennas are important btw .. but check how many networks are there in the area, then if you could find what channels they use try to use a channel with least number of networks ;) but if you still don't get it ..then something is crap. also try to setup a network between two machines ..but why do you need wireless anyway? it's not good for this application .. if you really wanna use it - try to disable all posible clients (make 300% sure that there is nothing going on the network appart form you pd thing). and as i've said - check for noise .. and may be try with bigger antennas ;) On Mon, May 24, 2010 at 10:51:09PM -0400, Ivica Ico Bukvic wrote: So, we've tried to do a series of tests using tcpserver/client as well as netserver/client and found the following: Using either off-the-shelf wifi hardware or an industrial strength wifi router (in our case Cisco), we get unexpected lag spikes on local WLAN with 16 clients at times even exceeding 2 seconds for some of the clients. Network connection in these tests was unencrypted. Packets tested were small to medium using both UDP and TCP (from a single number, up to a sentence, plus a couple numbers). When using off-the-shelf router we even had clients drop connections to the router in a high-traffic context. By using an industry strength router these took much longer to occur (but have still nonetheless occurred). So, with the router being less likely of a culprit I am wondering what is causing these spikes? Without looking closely at Pd's network code one suggested culprit by a CS colleague might be how Pd reuses ports and a possibility of it starving the router. Is this possible? The problem is apparent when sending sporadic TCP packets to all 16 machines as well as when using both UDP and TCP connections. One last thought is whether there might be something on the router settings that would make this an issue in both cases. Any thoughts on this would be most appreciated. Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] thoughts on Pd's networking framework
Hi all, from what i heard about experiences with the IEM CubeMixer system (with a lot of GUI-DSP communication between two PD processes) the fact that PD sends out network data packets in bursts seems to be problematic not only for WLAN but for the OS networking sockets (with limited buffer sizes) on a more general scale. If i were dependent on it, i would write a threaded networking external to circumvent PD networking functionality and find out whether this is the culprit. gr~~~ 2010/5/25 Ivica Ico Bukvic i...@vt.edu: So, we've tried to do a series of tests using tcpserver/client as well as netserver/client and found the following: Using either off-the-shelf wifi hardware or an industrial strength wifi router (in our case Cisco), we get unexpected lag spikes on local WLAN with 16 clients at times even exceeding 2 seconds for some of the clients. Network connection in these tests was unencrypted. Packets tested were small to medium using both UDP and TCP (from a single number, up to a sentence, plus a couple numbers). When using off-the-shelf router we even had clients drop connections to the router in a high-traffic context. By using an industry strength router these took much longer to occur (but have still nonetheless occurred). So, with the router being less likely of a culprit I am wondering what is causing these spikes? Without looking closely at Pd's network code one suggested culprit by a CS colleague might be how Pd reuses ports and a possibility of it starving the router. Is this possible? The problem is apparent when sending sporadic TCP packets to all 16 machines as well as when using both UDP and TCP connections. One last thought is whether there might be something on the router settings that would make this an issue in both cases. Any thoughts on this would be most appreciated. Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://g.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] thoughts on Pd's networking framework
On Mon, 24 May 2010, Ivica Ico Bukvic wrote: Using either off-the-shelf wifi hardware or an industrial strength wifi router (in our case Cisco), we get unexpected lag spikes on local WLAN with 16 clients at times even exceeding 2 seconds for some of the clients. Can you automate measurement of the lag time ? Then can you plot the lag time in function of the number of clients ? (add clients one at a time...) I don't know whether this will help, but it can make an unexpected a-ha. When using off-the-shelf router we even had clients drop connections to the router in a high-traffic context. By using an industry strength router these took much longer to occur (but have still nonetheless occurred). What's a high-traffic context here ? is it the 16 connections above, or more like 4000 connections ? how much data per connection ? you mean high-traffic to your ports, or high traffic for other matters ? Without looking closely at Pd's network code one suggested culprit by a CS colleague might be how Pd reuses ports and a possibility of it starving the router. Is this possible? no idea what that means. can you get a more complete explanation from that person ? The problem is apparent when sending sporadic TCP packets to all 16 machines as well as when using both UDP and TCP connections. oh, there are 16 machines... but how many [netreceive] are there per machine, and how many [netsend] are there per machine ? can this have any impact ? One last thought is whether there might be something on the router settings that would make this an issue in both cases. Are those computers next to each other and next to the router ? why didn't you use a wired network for them ? you don't have to use wires, but wires can be used to troubleshoot the problem, plus, they are more stable and predictable than microwaves. But before spending any money on this, I'd spend some time with the rest of the possible problems... _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] thoughts on Pd's networking framework
On 2010-05-25 16:38, Thomas Grill wrote: Hi all, If i were dependent on it, i would write a threaded networking external to circumvent PD networking functionality and find out whether this is the culprit. that's why there now is iemnet. first test showed that it is way faster than mrpeach's objects (back then when we tested), and both sending and receiving are fully threaded. (however, we have not deployed it with the CUBEmixer yet) fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] thoughts on Pd's networking framework
So, we've tried to do a series of tests using tcpserver/client as well as netserver/client and found the following: Using either off-the-shelf wifi hardware or an industrial strength wifi router (in our case Cisco), we get unexpected lag spikes on local WLAN with 16 clients at times even exceeding 2 seconds for some of the clients. Network connection in these tests was unencrypted. Packets tested were small to medium using both UDP and TCP (from a single number, up to a sentence, plus a couple numbers). When using off-the-shelf router we even had clients drop connections to the router in a high-traffic context. By using an industry strength router these took much longer to occur (but have still nonetheless occurred). So, with the router being less likely of a culprit I am wondering what is causing these spikes? Without looking closely at Pd's network code one suggested culprit by a CS colleague might be how Pd reuses ports and a possibility of it starving the router. Is this possible? The problem is apparent when sending sporadic TCP packets to all 16 machines as well as when using both UDP and TCP connections. One last thought is whether there might be something on the router settings that would make this an issue in both cases. Any thoughts on this would be most appreciated. Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
