[asterisk-users] Dahdi for meetme on AMD64 arch?

[John Knight]

Hi Johan,

I've run into a similar issue before.  I didn't resolve the problem per 
se, but I got around it by modifying modules.conf to disable the loading 
of res_timing_timerfd.so and loaded res_timing_dahdi.so instead:

noload => res_timing_timerfd.so
load => res_timing_dahdi.so

Cpu load came back down and call quality has been excellent since.  
Perhaps this might work for you?


--
<http://www.classiccitytelco.com>

*John Knight*
Classic City Telco LLC
*Email:* john at classiccitytelco.com | *Main:* (706) 995-0200
*Direct:* (706) 995-0201 | *Mobile:* (706) 255-9203


On 1/18/2012 4:24 AM, Johan Wilfer wrote:
> I'm in the process of replacing an old server with a new one and are
> making som changes in the infrastructure, the biggest change in my eyes
> is moving from i386 to AMD64 arch. Yesterday I began migrating some
> users from the old to the new server.
>
> After only 57 concurrent calls in abount 13 conferences the sound are
> losing quality.
> The server uses dahdi 2.6.0 for timing but no dahdi hardware.
>
> dahdi_test gives results like this when the server is used like that:
> 100.000% 99.999% 99.994% 99.998% 99.999% 99.616% 99.614% 99.997%
> 99.998% 99.618% 99.615% 99.994% 99.987% 99.626% 99.628% 99.993%
> 99.626% 100.000% 100.000% 99.622% 99.999% 99.607% 99.604% 99.627%
> 99.621% 99.629% 99.627% 99.998% 99.622% 99.995% 99.621% 99.996%
>
> Results from dahdi_test with only some calls active:
> 99.999% 99.999% 99.990% 99.998% 99.999% 99.995% 99.995% 99.993%
> 99.997% 99.993% 99.999% 99.998% 99.996% 99.996% 99.998% 99.998%
> 99.991% 99.998% 99.995% 99.995% 99.987% 99.985% 99.996% 99.995%
>
> Looking at the cacti graphs the kernel uses 100% cpu (total 400% with 4
> processor cores), when the problem above is present. Top does not show
> this kernel-cpu that cacti shows, but this maybe is by design? Asterisk
> is using about 15% cpu.
>
> top - 19:32:06 up 20:57,  1 user,  load average: 0.00, 0.00, 0.00
> Tasks: 213 total,   1 running, 212 sleeping,   0 stopped,   0 zombie
> Cpu(s):  7.4%us, 29.6%sy,  0.0%ni, 55.3%id,  0.0%wa,  0.0%hi,  7.7%si,
> 0.0%st
> Mem:  12299332k total,  3967800k used,  8331532k free,   251432k buffers
> Swap: 19529720k total,        0k used, 19529720k free,  2919456k cached
>
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 30666 root       0 -20  539m  25m 6600 S   15  0.2   6:55.01 asterisk
>    738 root      20   0 19184 1444 1004 R    1  0.0   0:00.08 top
>
>
> The old server (i386 Debian 5: Linux 2.6.26-2-openvz-686) can have 320
> calls in conferences without this problem.
> The new server (amd64 Debian 6: Linux 2.6.32-5-openvz-amd64) show these
> problems after 50 calls..
>
> Old server:
> Hp dl360g5, 4 cpu Xeon E5420, 2.50GHz
> run i386 with PAE and OpenVZ, Debian Lenny
> uses the broadcom nic's on the motherboard
> asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing)
> cacti shows cpu in kernel mode 80% with 320 active calls in conferences
>
> New server:
> Hp dl360g7, 4 cpu Xeon E5520, 2.27GHz
> run amd63 with OpenVZ, Debian Squeeze
> uses Intel nic's 82571EB for offloading the processor + nic bonding in
> the kernel for failover.
> asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing)
> cacti show cpu in kernel mod 100% with 57 active calls in conferences
>
> This is a puzzle to me..
>   - Does anyone have experience with amd64 arch and dahdi for timing?
>   - Can Dahdi om amd64 be responsible for the high cpu in kernel mode?
>
>   - I have a spare Digium TE220, would it offload the server to use it as
> a timing source only?
>   - How do I debug the high cpu usage by the kernel, can I break this
> down by module in some way?
>
>
> Many, many thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120118/184c9539/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo2.jpg
Type: image/jpeg
Size: 9505 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120118/184c9539/attachment.jpg>