Freddy, FDSET is just a size of a system structures, meaning the maximum allowed count of open handles ( sockets ) by a process. With FDSET=64 you can open only 32 proxies for signaling channels ( for example ). Regards, Boris -----Original Message----- From: Freddy Parra [mailto:fparra@xxxxxxxxxx] Sent: Friday, April 02, 2004 5:50 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: RE: CallSignalHandlerNumber Just made a new build of all three libraries with FD_SETSIZE=256. I didn't see an increase on the gnugk execuable size. I saw that i can also set LARGE_FDSET=1, will setting LARGE_FDSET=1 have any affect in Windows or just Linux? Freddy -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of Zygmuntowicz Michal Sent: Thursday, April 01, 2004 1:00 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: RE: CallSignalHandlerNumber 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/ ------------------------------------------------------- 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=ick _______________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id...49 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_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/
