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

[Martin Peach]

Roman Haefeli wrote:
> On Fri, 2009-05-01 at 09:16 -0400, Martin Peach wrote:
>> 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.
> 
> ok. i think, i understand. thanks for the explanation.
> 
>> This could all be done using threads as well but I just don't know when 
>> I'll have time to do it.
> 
> no hurry. it's not the case, that i know, that threading would help for
> the issues, i am experiencing. i just wanted to have my troubles
> reported. and i think, i read somewhere about server implementations,
> that they often use a separate thread for each socket.
> 
>> 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.
> 
> the only feedback needed: was something actually sent or not? if you (or
> the patch) _know_, that messages are not received by the other end, then
> you (the patch) can handle the situation somehow.
> anyway, that is the part that seems to be already working. by using the
> current [tcpserver], you notice, if the other end vanished or is still
> listening.
> the problems i currently encounter are coming from the fact, that the
> performance of the new version is probably 20 times worse than the
> version included in current stable pd-extended. for me its a problem,
> since with a certain sane number of clients connected (let's say 16), it
> already overloads the cpu of a 1.7GHz pentium m processor. why the big
> difference to the previous version?
> 

If you set the sending timeout to zero (by sending [timeout 0( message 
to [tcpserver] )then the performance should be the same as the older 
version. AFAIK that's all I changed. Did you try that yet?
If not, something else is causing the slowdown.
If it works better, maybe set the timeout to 10 instead of 1000.

Martin