Murf has posted details of a conversion and some test results for SIP in Asterisk:

Hello!

I've been slaving over chan_sip for some time now, and have some preliminary comparisons.

1. I'm comparing the 'stock' trunk version to team/murf/bug11210, where I've:
1. put all peers into an astobj2 hash table
2. put all users into an astobj2 hash table
3. put all dialogs (sip_pvt) into an astobj2 hash table
4. put all peers with an IP into an astobj2 hash table.
5. added a small hashtab to the ast_sched struct,
6. changed the ast_sched schedq linked list to be a doubly-linked list

2. In my first round of performance comparisons, I'm running asterisk compiled with no optimizations, and the -pg option added to profile the code. So, don't expect asterisk to run miraculously fast.

3. Also, the test machine (ala digium) is NOT a powerful machine... with 1 gig of memory and running an old version of Ubuntu. It's a Dell 32-bit PC, 2.8Ghz, P4. So, don't expect asterisk to run miraculously fast.
At least compared to the quad-processor 64-bit monsters that folks like to brag about! Oh, btw, I never noted any swapping throughout my testing.

4. All testing done with 'ulimit -n 8196' done previously. I have to do this, or I bump into the 'too many open files' problem. The threshold is about 195 simultaneous calls.

5. I'm using the latest version of sipp to thrash asterisk. I have two basic test scenarios: Run a LOT of really really really short calls, versus running a lot of LONG calls, and see how many you can run at once before problems set in...

for the short calls:
./sipp -sn uac 192.168.134.252 -s 12 -d 100 -l 256
(don't worry, you'll never get close to 256 sim. calls! [at least, not on MY machine!!!] sipp will start out at 10 calls/sec; keep bumping up the call limit until you start seeing retrans and timeouts. Things'll just plain go nuts. When you hit this, you've gone too far.)

for the long calls:
./sipp -sn uac 192.168.134.252 -s 12 -d 100000 -l 270
(run this several times, and vary that last number to find a limit that will allow you to run stably. If sipp goes nuts and cpu idle drops to 0%, stop the test and try again with a lower number!)

6. On my asterisk machine, the sipp entry in sip.conf looks like this:
[asterisk02]
type=friend
context=sipptest
host=192.168.134.240
user=sipp
canreinvite=no
disallow=all
allow=ulaw

7. and the sipptest context in extensions.conf looks like this:

context sipptest
{
_X. => {
Answer();
Background(demo-instruct);
Background(demo-instruct);
Background(demo-instruct);
Background(demo-instruct);
Hangup();
}
}
(I looked around for the longest playing soundfile I could find. Still, playing it 4 times may not take the full 100 secs. Tough. Close enough.)

8. To add spice to life, after the [asterisk02] entry in sip.conf, I added over 4600 other friend entries.

9. Asterisk is running on 192.168.134.252; sipp runs on 192.168.134.240.
Between them are 2 cheap 8-port switches and a router/switch.
Everything is running at 100mbit, and the kids are probably killing each other using network intensive gaming maneuvers in the same network.

OK, I admit it, I feel like a kid who's just put a turbocharger on his 450 V-8. Let's see what this baby can do on the open road. I have the advantage of not having to worry about what the police/sheriff/FBI will think!

Results:

On trunk:

Short Call test: at 100 calls/sec, I start seeing some retransmits after a while at 120 calls/sec, I see 0% cpu idle and sipp goes nuts.
Long Call test: at 270 simultaneous calls, cpu idle bobbles down to 0% frequently, but asterisk seems to hang on.
at 280, things fall apart pretty swiftly.

On my turbocharged V8 version in team/murf/bug11210:

Short Call test: things fall apart at 450 calls/sec. cpu idle drops to
0% and asterisk falls apart.

Long Call test: at 300 simultaneous calls, cpu hits 0% every now and then, but asterisk remains stable. at 310 simul. calls, we are stable for quite a while, but the cpu idle % times keeps bobbing up and down, and when it hits 0% hard, asterisk starts to trip up.
Conclusions: while I can get 4x performance for short calls, I seems to be dealing with some sort of network limit or something for long calls. Still, using hash tables to cut cpu usage, asterisk seems to be able to squeeze a few more calls in before it gets overloaded (about 10% or so?).

Caveats: There's still a few issues to clear up, namely 'pedantic' dialog lookups need to be addressed, and there's an occasional timing issue between the rtp stuff, and dialog destruction. It happens about as often as asterisk crashes in trunk from a bad peer pointer, btw, both problems occur during module reload/unload... always work to do!)

So, anyone wanna take this puppy out for a drive?

murf

--
Steve Murphy
Software Developer
Digium

Comments (Click to post)

Name:
Subject:
Website:
Message: