i need to correct myself: that p3 notebook is a 650MHz. i've done some load testing (sending to the pd side from max) with simple loops and to summarize:
with a light pd, i see 40,000 bytes/sec with small packets and up to 127,000 bytes/sec with large packets. this is the maximum lossless rate--there's a significant packet loss mode just above these rates.
with a heavier pd doing something approximating useful work (no dsp running, although i did start pd with two channels of sound out enabled) i measure 20,000 bytes/sec as the cpu rises to 100%.
i'm expressing this in terms of databytes only (i haven't looked closely enough at the protocol yet to understand what the overhead really is, but the packet-size effects seem quite normal to me).
so the packet loss mode appears closely tied to cpu rather than tcp bandwidth issues. when the cpu nears the limit, i'm seeing wish83.exe using ~~49% of the cpu, and pd.exe the other 49%.
why does such a lame little patch put such a load on wish83? the only graphic updates during these tests were two of the four number boxes spinning away (the packet count displays). could i be missing some kind of optimization?
regards, ______________________ | b o b f a l e s c h | www.zeggz.com/raf/
Bob Falesch wrote:
i've ported cxc's pd-fication of OSC to win-32. the dll is here:
http://207.208.254.239/pd/w32_osc.zip
so far i've had success sending in both directions between these two systems:
-- g3 250 Mhz powerbook macos 8.5.1 max 4.0.7 osc-for-max 2.4 (m.wright's current distro)
-- p3 850 Mhz notebook win-2k pd 0.34.4
...using a cheap, lightly loaded hub, and also directly with a cross-cable. i've tested it so far only with relatively low bandwidth control types of data, and probably won't get to anything real strenuous for a while, although i will soon cobble together some tight load-loops to determine at what point it might drop packets. if anyone has a stress-test patch i'd be grateful to try it out.
i intend to test with pairs of win32 systems (i should say w2k+, as i've no plans to try w98/me etc), and also with linux, but that will not be soon. i can put the source and the vc6.0 project files up there when i fold it more elegantly into the original source (2-3 days, i'd guess).
if anyone is sufficiently reckless with free time to test this, i'd be happy to hear about your results. if on the other end you use the equivalent of wright's latest version (with time and type-tags), such as i did with the max version listed above, remember to put it in the reduced feature mode. with that max version, you prime the [OpenSoundControl] with the message "writetypestrings 0" ...you'll save some headscratching (i wasted a half-hour before waking up to that one). also, see OSCroute-help.pd, which teases with some parsing ideas that should result in elegant midi-fying and other nifty data-fying.
if anyone wishes to try this with the peewee win-32s (98, etc) and it fails, i would definitely look into it (i still have access to a w98 dual boot here). if it fails i should think a fix would be trivial (famous last words...)
cheers, ______________________ | b o b f a l e s c h | www.zeggz.com/raf/
On Wed, 10 Apr 2002, Bob Falesch wrote:
i need to correct myself: that p3 notebook is a 650MHz. i've done some load testing (sending to the pd side from max) with simple loops and to summarize:
with a light pd, i see 40,000 bytes/sec with small packets and up to 127,000 bytes/sec with large packets. this is the maximum lossless rate--there's a significant packet loss mode just above these rates.
with a heavier pd doing something approximating useful work (no dsp running, although i did start pd with two channels of sound out enabled) i measure 20,000 bytes/sec as the cpu rises to 100%.
Could you express this numbers in messages/sec? What do you exactly mean with small and large packets? What kind of transport protocol are you using? Is PD's implementation of OSC based on OSC-Kit?
The weak spot of OSC is parsing the address and descending the namespace tree. Since with "small packets" you get a lower maximum rate, you could have reached this limit.
I don't use PD but I'd like to understand how many messages this implementation can dispatch per second.
Thanks, Maurizio Umberto Puxeddu.
i'm using udp over the standard tcp/ip stacks in the mac (open transport 2.02) and winsock2 under win2k. yes, cxc started from the cnmat OSC-kit.
my "small" packet is a message of 20 bytes, the "large" is 58 bytes, and i used something like "/abcedfg/ /hijklmno/ ..." etc to force a kind of string literal message so that i'd see on the receiving end exactly what was staged in the transmit side (not having studied the protocol i'm really not sure my messages had as meaningful an effect on the resultant packets as i'd hoped). anyway, with the "small" i got up to about 2480 messages/sec, and with the large i got about 2180 messages/sec. i did not use the OSC "message bundling" mechanism in these tests and my buffers on the client-side were small and numerous (60 @ 128 bytes per), so this wasn't a rigorous attempt at maximum efficiency. also note that i disabled time/type tags on the sender (the mac) as cxc's pd port doesn't yet cross that bridge. i hope that's helpful, ______________________ | b o b f a l e s c h | www.zeggz.com/raf/
Maurizio Umberto Puxeddu wrote:
On Wed, 10 Apr 2002, Bob Falesch wrote:
i need to correct myself: that p3 notebook is a 650MHz. i've done some load testing (sending to the pd side from max) with simple loops and to summarize:
with a light pd, i see 40,000 bytes/sec with small packets and up to 127,000 bytes/sec with large packets. this is the maximum lossless rate--there's a significant packet loss mode just above these rates.
with a heavier pd doing something approximating useful work (no dsp running, although i did start pd with two channels of sound out enabled) i measure 20,000 bytes/sec as the cpu rises to 100%.
Could you express this numbers in messages/sec? What do you exactly mean with small and large packets? What kind of transport protocol are you using? Is PD's implementation of OSC based on OSC-Kit?
The weak spot of OSC is parsing the address and descending the namespace tree. Since with "small packets" you get a lower maximum rate, you could have reached this limit.
I don't use PD but I'd like to understand how many messages this implementation can dispatch per second.
Thanks, Maurizio Umberto Puxeddu.
for my port to win32, i used the OSC sources on http://barely.a.live.fm/pd/OSC/ dated 28-Jan-2002, but there's a newer version (OSCx_20020305.tgz) which adds support for type tags. over the next hours i'll update my win32 port with this version. i'll post notification when that's ready.
| b o b f a l e s c h | www.zeggz.com/raf/
-
Bob Falesch -
Maurizio Umberto Puxeddu