David Winter Senior Network Engineer Planet-Telecom, Inc. Tampa FL (813)901-5182 Office (813)864-3162 Direct (813)817-4204 Mobile (813)881-9762 Fax ------------------------------------------ AIM: mobofool ICQ: 3563403 MSN: dwinter@xxxxxx Y!: vt_fool
Craig Southeren wrote:
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/
