RE: CallSignalHandlerNumber

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/



-------------------------------------------------------
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/


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux