Wow! 64Bit Asterisk on a T2000

Asterisk Asterisk Support
1

Finally got a 64bit build of asterisk to boot on a Sun T2000 Cool Threads with the UltraSparcT1 (Niagra) CPUs

good news is it only took a couple of days and an extra set of eyeballs poking at the makefiles to get it to work, badnews, when running a call generator against it last night with a call rate of 250 calls/second it looks like theres a Memory Leak somewhere in the channel setup/teardown

I tried using astmm to locate the issues but once that code is enabled asterisk just refuses to run (bus error (core dumped) type response when trying to start asterisk)

I really need to get one of the super geniuses to take a look at this when they get back from Von

2

Hi,

Which call generator were you using, I would like to test our asterisk boxes before pushing them through into the production environment.

What compile flags are you using to build a 64-bit environment? And wouold you recommend the 64-bit build for a production environment? Have you managed to build asterisk on a 64-bit intel box? I’m looking for what modifications were made to the makefile on a x64 environment.

Also, just a quick question, you mentioned Sun Studio in e previous thread, I was wondering if we need to use the GNU build environment for asterisk, or have you managed to test a compile with Sun Studio?

Cheers
Asgaroth

3

I was using sipp to generate calls.

the tests were very simple send an invite wait for 100,180, and 200 OK then send BYE and wait for ack

max call rate I was able to acheive was 550 calls/sec after that things go bad…

as far as buildng it, I used the gcc, gmake that comes with sol10. I also needed to install ginstall (used pkg-get for that)

SunStudio will not build it at this time there are gmake specific things in the make files the cause sun’s make to fall over dead

also to get 64bit binaries i had to do several modifications to the make files to add the -m64 switch

I need to get back and do some more testing this week and write all this up.

Also note: trunk needs a few patches if you are going that route

4

Thanks for the quick response :smile:

With regards the call generator though, did you setup another asterisk box to perform the generation to the T2000?

On a side note, with regards the installation locations, i modified the “main” makefile to put things in

/opt/asterisk/bin,
/opt/asterisk/lib,
/opt/asterisk/include,
/opt/asterisk/man,
/opt/asterisk/sbin,
/opt/asterisk/var/log etc etc.

Can you think of any negative affect this may have. The only thing i can think of is that I would need to keep the include paths static so that if i’m compiling anything against the include files with this structure, then the headers are found, i guess the other way would be to manually go and edit the headers. I wonder if the autoconf/configure “future” additions will sort this out?

I’m about to go and make the same installation location changes with the 1.2.6 release of asterisk. What I have been doing previously is to build asterisk, start it up, do some basic testing within asterisk, run an appcert against the binaries i’ve created, then build a pkg which i could then use to “upgrade” our production systems.

I’ve currently got asterisk 1.2.5 running in 2 zones in a S10 box on Dell PE 1850’s. I read somewhere (i think it was the Digium knowledgebase) that the maximum number of concurrent calls range from 60 - 80 depending on codecs used. At that call rate the CPU’s on our syste are only peaking at 40 - 60% usage, so i figured 2 zones would make better use of the resources. I also have asterisk being monitored by the SMF (PSH Feature) of S10. Maybe I should add a section in this forum for the PSH addition, its dead handy for when asterisk crashes, its also handy for startup/shutdown/reboots etc of the box as you know from S10 onwards Sun are gonna phase out legacy startup scripts.

My next mission objective is to get this going with IPMP on the global zone for network failover. I think I may have got it going, but i need to actually test this more, ie: physically pull the cable and see what it does.

I guess these are all handy little features around the OS, I would like to try to get to a point where we can safely build * with documented optimizations for the Makefile, but I guess tat will just be a work in prgress as we move along on Sun. However, any suggestions/criticisms you may have from your experience would be appreciated.

Cheers
Asgaroth

5

With respect to sipp I was running it on a linux box (havent had much luck getting to to compile on NON-linux platforms (solaris and OSX are what I tried)

As far as changing paths I dont see a big deal there as long as you put the includes in the proper locations…

personally I would prefer to run everything out of /opt/asterisk and even run asterisk as a non-root user (say the asterisk user) this in itself would increase security

as far as peak call load… transcoding is the big problem say going from 711 to g729 is pretty FPU intensive and I wouldnt even try it on a T2K the T1 CPU has abysmal FPU performance (sun even admits to this)

Also one way to increase call capacity way up (and it can be done) is to reduce the number of sessions we media proxying is required and set canreinvite to yes for sip sessions and enable native transfers for IAX. This will in most cases allow the media stream to move off of asterisk and go end point to endpoint (as long as you are doing something like a protocol conversion say SIP to IAX or TDM to SIP obviously)

I have a box deployed that in the first 7 days of this morn did 200K Minutes with load avgs of like 0.02 to 0.05 with a large number of sip peers (150+ registrations and 15 to 20 static non-registering peers)
(particular box is a Dell 2850 w/ a pair of 2.8 Xeons w/ Hyperthreaded disabled)