On Thu, 2009-04-30 at 10:17 -0400, Martin Peach wrote: > Roman Haefeli wrote: > > i ve been testing the new netpd-server based on the new > > [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could > > solve some problems, but some new ones were introduced. > > > > i found, that the most recent version of [tcpserver] peforms quite bad > > cpu-wise. this has some side-effects. in netpd, when a certain number of > > users are logged in (let's say 16), it can happen, that the traffic of > > those clients makes the netpd-server use more than the available > > cpu-time. i made some tests and checked, if all messages come through > > and if messages delivered by the server are still intact. under normal > > circumstances, there is no problem at all. but under heavy load, when > > the pd process is demanding more than available cpu time, some messages > > are corrupted or lost completely; in the worst case the pd process > > segfaults, at the moment of a client connecting or disconnecting. i > > guess, this is due to some buffer under- or overrun between pd and the > > tcp stack, but i don't really know. > > Hi Roman, > Did you try using the new [timeout( message? The latest version of > tcpserver defaults to a 1ms timeout, so if you have a bunch if > disconnected clients, Pd will hang for 1ms each, which will quickly add > up to more than the audio block time and then Pd will start thrashing > and eventually die or become comatose, as it were.
no, i haven't tried this parameter yet. but i sure will do and report back, when i can tell more about how it behaves. i haven't fully understood, what it does and what it can be used for. could you elaborate that a bit more? yet it sounds a bit strange to me, that i need to tweak a networking object with a time value for correct operation. > I think you need to experiment with different values for the timeout. ok > > Set it to zero and it should give the same results as the previous > version; you, mean, [tcpserver] will hang pd, when the buffer of a certain socket is full? or do you mean the version, that cut off some parts of messages under certain circumstances? > maybe try something around 100 instead of the default 1000 > (it's in microseconds). > The other way to fix this in the tcpserver source is to make a new > thread for each client, but I'm afraid that will just open another can > of worms/zombies. i hardly know anything about threading, but i guess that is what other servers do (e.g apache). also didn't i see a way around creating dynamically an instance of the protocol handling abstraction for each socket, which is, i guess, something similar to threading in the pd world (not technically, but conceptually). roman ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev