Nice stats! Keep going:) One remark - your bottleneck may be RAS handling thread. While CallSignalHandlerNumber controls a number of threads for signalling channels (for 400 calls it should be enough to set it to some number definitelly smaller than 100), RAS messages are handled sequentially only by one thread. You may try replacing 2.0 with 2.2 to see if there is any performance gain. One thing came to my mind. Windows SDK enforces limit of 64 sockets per thread by default. Maybe this is your bottleneck too. You can control this by setting FD_SETSIZE preprocessor macro. After setting this macro to some nice values (like 256 or more), you have to recompile everything (PWLib, OpenH323 and GnuGk). The macro has to be set in each of the projects (PWLib, OpenH323, GnuGk). Having FD_SETSIZE with its default value, you are limiting GnuGk to at most 32 calls per signaling handler. And you may run into additional troubles. Regards, Michal Freddy Parra <fparra@xxxxxxxxxx> wrote: >This is an interesting subject and I like to post some statistics that I\'ve just come across with the latest 2.08 Gnugk. > >Gnugk Running on 4 3.06 Xeon GHz CPU Processors with 2GB of memory on Windows 2003 Server. >Endpoints Running are Cisco 5400\'s registered to Gatekeeper(RAS). >Gatekeeper in H225 and H245 Routed mode only. No RTP Proxing. >Testing with a DS3 of traffic. >Current Setup: Excel -> Cisco -> GK -> Cisco -> Excel. Gnugk Acting as are zone gatekeeper for are Ciscos. > >CallSignaling Handler Set to 2 = Max Active Calls were 60, after this calls were just rejected. >CallSignaling Handler Set to 4 = Max Active Calls were 110, after this calls were just rejected. >CallSignaling Handler Set to 100 = We Were Able to Run about 400+ Active calls with sometimes 20 to 30 calls waiting to be setup. No Problems, we left this running for couple hours >and completed over 15000 calls in just a few hours with about a 60 percent asr ratio. Only thing we noticed was a spike in low call durations, were looking into this , other then this it worked great. > >During these test the CPU utilization fluctuated between 2 and 14 percent. > >We will probably be pumping a few more DS3\'s. Will begin reporting more specific results and specific stats on different servers running Windows and Linux. > >Would be great to have additional stats posted from other people who are currently running gnugk. Thanks. > >Freddy > >-----Original Message----- >From: Zygmuntowicz Michal [mailto:m.zygmuntowicz@xxxxxxx] >Sent: Wednesday, November 19, 2003 2:46 PM >To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >Subject: Re: CallSignalHandlerNumber > > >100 is a bad choice probably, but 1 is not the best one too. If we consider authentication/accounting >performed during Setup processing we may find single call signal handler limiting our call throughput. >If our average Setup processing time is 100ms, we will not be able to handle more than 10 calls per second >(in practice this number is yet smaller). >Another thing is that processing large socket select lists is not efficient - it is probably >better to split them among multiple threads. > >----- Original Message ----- >From: "Andrey S Pankov" <casper@xxxxxxxxxxxxxxxxx> >Sent: Wednesday, November 19, 2003 1:10 PM > > >> > I\'ve seen some production environments where this option has been set to 100 >> > or similar value to offer best call throughput. >> >> Does it help? Do they really have what they expect from setting it to 100? ------------------------------------------------------- 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_id=1470&alloc_id=3638&op=click _______________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
