Markus and David, The problem is that Unix programs are just not designed to handle hundreds of file handles in a single select statement. The "poll" command was designed as a better, but not perfect, solution to that problem. There will always be a limit on the number of the file handles a single process can address. Expanding it from the default of 1024 to 16384 certainly means that more file handles are available, but it also means that more CPU time will is spent simply manipulating lists of FDs rather than doing useful work (as demonstrated by Markus's figures). For a good explanation of the tradeoffs of various approaches, see http://www.kegel.com/c10k.html >From experience, the way to solve this problem is to use a single gatekeeper with multiple seperate proxy processes. I personally have seen a single 1.6Ghz Linux machine handle more than 400 simultaneous calls with no problems using this approach. That was signalling only - doing media as well would reduce the number of calls, but then again, using a dual 3Ghz machine would increase it again dramatically. A single gatekeeper process can easily handle thousands of registrations, but there is no way it can also handle the call proxying for that number of users at any useful utilisation ratio. And for systems that need to support tens of thousands of users, with thousands of simultaneous calls, a distributed system of proxies and GK will always be needed. And yes, such a system does exist :) Craig On Thu, 15 Apr 2004 10:15:40 +0200 Markus Storm <markus.storm@xxxxxxxxxxxxx> wrote: > david winter wrote: > > > I understand that part, but is it just really hard to proxy the RTP? > > is there a bottleneck somewhere? is the code just not efficient > > enough? (not that i am knocking the code, this is great stuff.) but I > > dont see the value in proxying (barring doing it for NATs) this until > > i can get closer to 500 proxied RTP calls on a $3000 computer. this > > coming from the perspective of an international voip carrier, carrying > > LOTS of minutes. > > I agree (same business, same problem here). > > Interesting, though, that most of the CPU seems to be burned in select(): > I've compiled with LARGE_FDSET enabled. Without that, gnugk burns even > 100% CPU. > > > [root@lnxc-025:/usr/local/bin]$ strace -cp 22671 > Process 22671 attached - interrupt to quit > Process 22671 detached > % time seconds usecs/call calls errors syscall > ------ ----------- ----------- --------- --------- ---------------- > 80.41 1.921345 58 32953 select > 9.52 0.227385 9 25324 sendto > 6.70 0.160188 6 25324 recvfrom > 1.61 0.038422 93 414 414 rt_sigsuspend > 1.23 0.029284 4 7600 gettimeofday > 0.24 0.005694 7 838 kill > 0.11 0.002519 9 285 write > 0.08 0.001927 5 414 414 sigreturn > 0.07 0.001712 4 414 rt_sigprocmask > 0.02 0.000432 24 18 send > 0.01 0.000216 6 36 recv > 0.00 0.000099 33 3 shutdown > 0.00 0.000057 10 6 time > 0.00 0.000041 21 2 socket > 0.00 0.000036 12 3 close > 0.00 0.000028 14 2 listen > 0.00 0.000014 7 2 bind > 0.00 0.000009 5 2 getsockname > 0.00 0.000009 5 2 setsockopt > ------ ----------- ----------- --------- --------- ---------------- > 100.00 2.389417 93642 828 total ----------------------------------------------------------------------- Craig Southeren, craigs@xxxxxxxxxxxxxxxxx http://www.postincrement.com Post Increment - Software, Consulting and Services Co-founder of the only open source H.323 project Phone: +61 2 43654666 Fax: +61 2 43673140 Mobile: +61 417 231046 ICQ: #86852844 MSN: craig_southeren@xxxxxxxxxxx GnuPG Public Key: http://www.postincrement.com/pgp.txt Blog: http://www.southeren.com/blog/ ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&opÌk _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Homepage: http://www.gnugk.org/
