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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
