Messages per Month
|Krzysztof Czaja||Mar 10, 2005 11:10 am|
|james tittle||Mar 10, 2005 1:44 pm|
|Josh Steiner||Mar 10, 2005 3:03 pm|
|ix...@replic.net||Mar 10, 2005 5:27 pm|
|ix...@replic.net||Mar 10, 2005 5:42 pm|
|ünter geiger||Mar 11, 2005 2:14 am|
|Krzysztof Czaja||Mar 11, 2005 4:41 am|
|Krzysztof Czaja||Mar 11, 2005 4:42 am|
|Krzysztof Czaja||Mar 11, 2005 4:47 am|
|ix...@replic.net||Mar 11, 2005 5:50 pm|
|james tittle||Mar 12, 2005 5:18 pm|
|B. Bogart||Mar 14, 2005 9:07 am|
|Krzysztof Czaja||Mar 14, 2005 12:01 pm|
|Subject:||Re: [PD-dev] just look at these numbers|
|From:||Josh Steiner (jo...@vitriolix.com)|
|Date:||Mar 10, 2005 3:03:55 pm|
how do these throughput measuments really reflect on actual performance characterisitics? ie, is the windows tk gui getting bottlenecked by this?
Krzysztof Czaja wrote:
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales (2.66MHz linux PC transfers 80Mb/s, no windows there to confirm, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?
What I did was repeatedly sending tcl comments (1Kb long each) via a tot, and storing "clock clicks -milliseconds" readings made after various amounts of transferred data.
Then I tried reducing the polling interval in window's pd.tk (originally 20ms) and got
10ms polling 810Kb/s 5ms polling 1.6Mb/s
Reducing it further was a bad idea: 1ms interval forced wish84.exe to consume over 90% of cpu by doing nothing else but polling an empty socket.
Then I tried to replace polling with setting a "fileevent" callback on a tcl socket channel. Loaded a modified pd.tk directly via wish first, then run "pd.exe -guiport", and got
so, unfortunately, tcl channel adds too much overhead...
Have not tried with ws2_32.dll yet. I am tired, this is not my platform.