[PD-dev] [tcpserver]: bad performance of new version

Martin Peach martin.peach at sympatico.ca
Fri May 1 15:16:46 CEST 2009


Roman Haefeli wrote:
> 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.
> 

When you send some message through tcpserver, the send routne first 
checks to see if it can be sent. The call to do this is a function known 
as "select", which has a timeout parameter. The select call returns as 
soon as the socket is available or the timeout expires, whichever comes 
first. If the socket is blocked, select would never return if there was 
no timeout. So I gave the call a default 1ms timeout.

This could all be done using threads as well but I just don't know when 
I'll have time to do it. I still don't see that it would solve your 
problem anyway, if your application insists on sending to disconnected 
clients, you would have lots of threads sitting around, and still get no 
feedback about the connection.

Martin




More information about the Pd-dev mailing list