Hello, In the past I have expiremented with these values and be sure to use win2k server as your operating platform to not run into the limitations of the w32 Operating system regarding the max amount of tcp sockets or you might be able to tweak the values in the registers yourself. The real maximum amount of calls that I was able to reach on 1 w32 box in a bench mark was about 3000. But the machine is very sluggish and does not react well to any commands anymore. As a note but of minor importance is that all my heavy loaded environments are put on linux and only small childs ( they handle up to 100 proxied calls) located at customers to do the proxy trick. My experience tells me that gnugk performs excellent on linux ( I use RH9) for the heavier loaded environments. Another invention is that I use a lot of VPNed parent child situations to nicely break out of clients that are using nated environments so all the proxying is done at the client site and my parent does route and control the call but does not proxy the traffic. Penetrating nat is one of the great things of the gnugk but also a serious security issue regarding NAT policy for the majority of my clients. Tjapko. -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of Boris V. Kardakov Sent: Jueves, 01 de Abril de 2004 09:54 p.m. To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: Re[3]: CallSignalHandlerNumber We are using win2k as, all libs compiled with fdset 1024. So every instance of call signal calling thread call do the select of maximum 1024 sockets. >From the other hand, we use Dual Pentium Processor(r) platform, so we can operate more than one thread at one time. ( say, two threads ;) So, we use CallSignalHandlerNumber=2. As a result we have 1024 * 2 signal channels can be served. -----Original Message----- From: "P. P." [mailto:block111@xxxxxxx] Sent: Friday, April 02, 2004 8:37 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re[3]: CallSignalHandlerNumber Sooo..., whats the recommended value? :)) > > 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/ > ------------------------------------------------------- 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_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/ --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.639 / Virus Database: 408 - Release Date: 22/03/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.639 / Virus Database: 408 - Release Date: 22/03/2004 ------------------------------------------------------- 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/
