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

[Hans-Christoph Steiner]

Do you have a good description of the problem with [netserver]?  If  
so, I could take stab at it.

.hc

On Apr 26, 2009, at 8:27 PM, Roman Haefeli wrote:

> hi martin, hi all
>
> 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.
> i wrote a benchmark patch and found out, that not only the new
> netpd-server patch performs badly, but quite some portion of bad
> performance comes from the new [tcpserver]. the testpatch compares
> perfomances of sending data to clients using [tcpserver] and  
> [netserver]
> from maxlib. the version of [tcpserver] shipped with current pd- 
> extended
> performs slightly better than [netserver] (tested on OS X and linux).
> however, the most recent version, that solves the tcp buffer overrun
> problem, performs ~11 times worse than [netserver]. is that the trade
> off from solving the other issue? or could this theoretically be
> improved?
>
> unfortunately, i still don't have a netpd-server running, which can be
> considered stable. the current one doesn't crash anymore, because
> clients lost network connection, but it crashes, when there is too  
> much
> traffic. respectively, it cannot be considered reliable, because it
> drops messages under certain circumstances.
>
> @code-maintainers
> is anyone maintaining the code of [netserver] or maxlib in general?  
> this
> object class still suffers from the 'buffer overrun -> pd hangs'
> problem. since the same problem was fixed for [tcpserver], it might  
> not
> be too hard to port that fix to [netserver]. i am not able to dig  
> into c
> sources, so i wanted to kindly ask here, if someone is interested to  
> do
> it.
> [tcpsocketserver FUDI] was meant as a replacement for [netserver] in
> order to get rid of the pd hangs caused by it. however, now i am not
> sure anymore, if this approach was a good idea at all, since the
> overhead from implementing FUDI parsing and stuff in pd instead of  
> in c
> seems to be enormeous.
>
> roman
> < 
> benchmark_server 
> .pd 
> > 
> < 
> benchmark_server_testclient 
> .pd>_______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


----------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic