Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-20 00:38, John Knight skrev: Why doesn't Debian use the rhel6-openvz-kernel if that is the one that is maintained? Are you sure they use an outdated kernel? I didn't see an el6 tag on your kernel version that you first posted which means it's probably based on the 2.6.32 vanilla branch (http://wiki.openvz.org/Download/kernel/2.6.32). The el6 version (http://wiki.openvz.org/Download/kernel/rhel6) is the only known actively developed branch of 2.6.32 that I know of. I can't imagine Debian not packaging it up correctly by not reflecting the correct branch information. Though it's only been a year and half since 2.6.32-el6 has been around, I've already seen quite a bit of bug fixes, security fixes and backports added to it so it's already diverging quite heavily from the vanilla branch. Something that works flawlessly on 2.6.32-el6 might not work the same way on 2.6.32, and I'm wondering if this might be a cause of issues. I did some reading on the openvz forum / wiki. They seems to also update and fix the debian branch from what I found. Anyway I don't have the time to build this server from scratch anyway so it will have to stay the way it is unless it's seriously broken. For the next server I will research will further, and test out lxc to see if it can replace openvz. I found some posts to this mailinglist about lxc that seems to indicate that it works well, and the methods are quite similar to openvz. To Digium: Does Digium test dahdi against a specific set of kernels such as 2.6.18-el5 and 2.6.32-el6 or do they only test against the vanilla upstream branches or a mixture? Dahdi target platforms would be interesting to know in relation to the context of Johan's dahdi problem. Maybe I will try switch to lxc instead of openvz as it is in the mainline kernel now. After all I need two things: Isolation, and the possibility to run multiple asterisk VEs on the same physical machine. Hmm, I've never used lxc. It definitely sounds interesting. If you're going to implement it running Asterisk, I'd love to know if there are any issues or special methods required to get dahdi running (such as the DEVNODES feature in vz). Also, sorry to anyone if I've veered too far offtopic, I'm quite interested and invested in openvz/asterisk/dahdi interoperability. I'll keep you updated! Thanks for you input! -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On Fri, 2012-01-20 at 15:31 +0100, Johan Wilfer wrote: For the next server I will research will further, and test out lxc to see if it can replace openvz. I found some posts to this mailinglist about lxc that seems to indicate that it works well, and the methods are quite similar to openvz. +1 for LXC. Has been running flawlessly for me (about a dozen instances on a single modest machine) for about six months now, on Ubuntu (server) 11.04 - asterisk 1.4.x and FreePBX. I have a parent asterisk running on the host that handles call routing for the containers. Documentation is almost nil, and some of the tools are flaky - while I was getting the template perfected I had a few instances of stuck containers in a weird state which required manual removal of files in /cgroup. I've often wondered if I jumped into LXC too soon, but now that the template is stable and I'm not constantly mucking with it, it has been maintenance-free (knock on wood). See the archives for my posts about getting dahdi to run (for timing conferences) in the containers. Cheers, j -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On Wed, Jan 18, 2012 at 01:06:06PM -0600, Shaun Ruffell wrote: Another thing you can try in the meantime is switch to DAHDI 2.5.0.2 and edit drivers/dahdi/Kbuild to enable dahdi_dummy which will use the (relatively inefficient for the purposes of conferencing) highres timers when loaded by default on recent kernels (if compiled in). Slightly OT: If you re-enable dahdi_dummy the same way on 2.6, it will oops on load as it misses a parent device. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
In article 4f168fcc.9070...@jttech.se, Johan Wilfer li...@jttech.se 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. [...] 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? It may be a stupid question just displaying ignorance on my part, but why are you using *AMD*64 architecture on an *Intel* processor? Surely for 64-bit, you should be using x86_64 architecture instead? Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
Tony Mountifield wrote: It may be a stupid question just displaying ignorance on my part, but why are you using*AMD*64 architecture on an *Intel* processor? Surely for 64-bit, you should be using x86_64 architecture instead? From what I've read, AMD came out with the extended instruction set and Intel just implemented it as is. It's basically the same for both processors. Doug -- Ben Franklin quote: Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-19 13:27, Doug Lytle skrev: Tony Mountifield wrote: It may be a stupid question just displaying ignorance on my part, but why are you using*AMD*64 architecture on an *Intel* processor? Surely for 64-bit, you should be using x86_64 architecture instead? From what I've read, AMD came out with the extended instruction set and Intel just implemented it as is. It's basically the same for both processors. Doug I found this wiki http://wiki.debian.org/DebianAMD64Faq , it states that AMD64 / Intel64 / x86_64 are the same thing: Debian on AMD64 FAQ Q: Is this port only for AMD 64-bit CPUs? A: No. AMD64 is the name chosen by AMD for their 64-bit extension to the Intel x86 instruction set. Before release, it was called x86-64 or x86_64, and some distributions still use these names. Intel refers to its AMD64 implementation as Intel64 previously named EM64T. The architecture is AMD64-compatible and Debian AMD64 will run on AMD and Intel processors with 64-bit support. Because of the technology paternity, Debian uses the name AMD64. I've always wondered about the amd in the name, but it makes sense now. Thanks for the input.. -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 20:06, Shaun Ruffell skrev: That's pretty severe, and could certainly cause problems for DAHDI trying to use the kernel as a timing source. NTP will correct the drift, but the drift is still happening and it's not corrected on every tick. If the ticks are not happening at the rate they are supposed to, then DAHDI will not be operating at the clock rate it is supposed to. Kevin, this looks like a good candidate for using the monotonic interface in the kernel that we were talking about last week or the week before. The specific function call escapes me at the moment. Johan, I can't do it right this second, but I'll prepare an issue / patch against a 2.6.32 kernel that should make dahdi less prone to clock skew from NTP (although you probably want to get that fixed somehow) if you would be willing to test it for me on your server. Another thing you can try in the meantime is switch to DAHDI 2.5.0.2 and edit drivers/dahdi/Kbuild to enable dahdi_dummy which will use the (relatively inefficient for the purposes of conferencing) highres timers when loaded by default on recent kernels (if compiled in). Yes! That did it. Thank you! This time it wasn't as much channels active as the last time. It was 32 channels active, and the last time 57. In the beginning of the next week there will be more users to reproduce the test with more channels, and I will begin to work with a test configuration to create some channels from another server. (Should have done that a long time ago I guess) I will hold up migration of more customers to this server, so we can test your patch against Dahdi 2.6. This is the the server with dahdi_dummy idle: 99.999% 99.997% 100.000% 99.999% 99.999% 99.994% 99.997% 99.999% 99.997% 99.999% 99.999% 99.999% 99.999% 99.999% 99.998% 99.999% 99.999% 99.998% 99.998% 99.999% 99.999% 99.999% 99.998% 99.999% 99.999% 99.998% 99.998% 100.000% 99.999% 99.998% 99.999% 99.999% 99.998% 99.998% 99.999% 99.998% 99.998% 99.999% 99.998% ^C --- Results after 10335 passes --- Best: 100.000 -- Worst: 99.984 -- Average: 99.998134, Difference: 99.998607 This is the server with dahdi_dummy during load: 99.996% 99.999% 99.998% 99.992% 99.997% 99.999% 99.996% 99.993% 99.999% 99.998% 99.992% 99.994% 99.996% 99.992% 99.994% 99.996% 99.998% 99.998% 99.998% 99.997% 99.999% 99.995% 99.993% 99.998% 99.997% 99.998% 99.996% 99.995% 99.998% 99.990% 99.996% 99.996% 99.997% 99.992% 99.994% 99.986% 99.998% 99.991% 99.987% 99.991% 99.999% ^C --- Results after 201 passes --- Best: 100.000 -- Worst: 99.962 -- Average: 99.994760, Difference: 99.998428 Thanks! -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 19:44, John Knight skrev: Have you used 64 bit kernels (amd64) in your setup? Distribution? Aye, I use the current stable 64-bit rhel6 branch openvz kernel with centos 6 on the node and scientific linux 6 in the template without issue other than what I described before with res_timing_timerfd.so pegging the cpu and coring Asterisk. Good to know that it is working! I've run i386 earlier, but thought it was time to try 64-bit. It's never a suggestion a debian user wants to hear, but as the vanilla 2.6.32 openvz kernel has effectively been abandoned by the OpenVZ dev team in favor of the rhel6 version of 2.6.32, and since the node shouldn't really be doing anything other than hosting the templates, have you considered running centos6/rhel6-openvz kernel on the node and debian in the containers? Just a suggestion, but no further openvz development is being done to the vanilla 2.6.32 branch and the rhel6 openvz kernel will consistently have bug fixes and and backports. Not trying to start a distro war or anything, rather just a suggestion. I've been quite happy with Debian. Previously I was using BSD, and it was almost impossible to upgrade the system. And apt / dpkg have never failed me, very impressive. I guess rhel works well also, but I've little experience with it. Why doesn't Debian use the rhel6-openvz-kernel if that is the one that is maintained? Are you sure they use an outdated kernel? I have to read up on this, the next server maybe should use another distro for the HN. Maybe I will try switch to lxc instead of openvz as it is in the mainline kernel now. After all I need two things: Isolation, and the possibility to run multiple asterisk VEs on the same physical machine. -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
I've been quite happy with Debian. Previously I was using BSD, and it was almost impossible to upgrade the system. And apt / dpkg have never failed me, very impressive. I guess rhel works well also, but I've little experience with it. Debian is a great distribution as well. I still use it as the container os to host web vps. I think for OpenVZ usage though, it would be best to at least run your node software on the same distribution that is targeted via OpenVZ dev staff. You shouldn't really be doing anything else on your node anyway, so the os type shouldn't really interfere I would think. Though this argument breaks down when I suggest it to my Debian-using friends who seem to have a knee-jerk right hook coming my way when I mention rhel/centos. :D Why doesn't Debian use the rhel6-openvz-kernel if that is the one that is maintained? Are you sure they use an outdated kernel? I didn't see an "el6" tag on your kernel version that you first posted which means it's probably based on the 2.6.32 vanilla branch (http://wiki.openvz.org/Download/kernel/2.6.32). The el6 version (http://wiki.openvz.org/Download/kernel/rhel6) is the only known actively developed branch of 2.6.32 that I know of. I can't imagine Debian not packaging it up correctly by not reflecting the correct branch information. Though it's only been a year and half since 2.6.32-el6 has been around, I've already seen quite a bit of bug fixes, security fixes and backports added to it so it's already diverging quite heavily from the vanilla branch. Something that works flawlessly on 2.6.32-el6 might not work the same way on 2.6.32, and I'm wondering if this might be a cause of issues. To Digium: Does Digium test dahdi against a specific set of kernels such as 2.6.18-el5 and 2.6.32-el6 or do they only test against the vanilla upstream branches or a mixture? Dahdi target platforms would be interesting to know in relation to the context of Johan's dahdi problem. Maybe I will try switch to lxc instead of openvz as it is in the mainline kernel now. After all I need two things: Isolation, and the possibility to run multiple asterisk VEs on the same physical machine. Hmm, I've never used lxc. It definitely sounds interesting. If you're going to implement it running Asterisk, I'd love to know if there are any issues or special methods required to get dahdi running (such as the DEVNODES feature in vz). Also, sorry to anyone if I've veered too far offtopic, I'm quite interested and invested in openvz/asterisk/dahdi interoperability. -- John Knight Classic City Telco LLC Email: j...@classiccitytelco.com | Main: (706) 995-0200 Direct: (706) 995-0201 | Mobile: (706) 255-9203 On 1/19/2012 6:17 PM, Johan Wilfer wrote: 2012-01-18 19:44, John Knight skrev: "Have you used 64 bit kernels (amd64) in your setup? Distribution?" Aye, I use the current stable 64-bit rhel6 branch openvz kernel with centos 6 on the node and scientific linux 6 in the template without issue other than what I described before with res_timing_timerfd.so pegging the cpu and coring Asterisk. Good to know that it is working! I've run i386 earlier, but thought it was time to try 64-bit. It's never a suggestion a debian user wants to hear, but as the vanilla 2.6.32 openvz kernel has effectively been abandoned by the OpenVZ dev team in favor of the rhel6 version of 2.6.32, and since the node shouldn't really be doing anything other than hosting the templates, have you considered running centos6/rhel6-openvz kernel on the node and debian in the containers? Just a suggestion, but no further openvz development is being done to the vanilla 2.6.32 branch and the rhel6 openvz kernel will consistently have bug fixes and and backports. Not trying to start a distro war or anything, rather just a suggestion. I've been quite happy with Debian. Previously I was using BSD, and it was almost impossible to upgrade the system. And apt / dpkg have never failed me, very impressive. I guess rhel works well also, but I've little experience with it. Why doesn't Debian use the rhel6-openvz-kernel if that is the one that is maintained? Are you sure they use an outdated kernel? I have to read up on this, the next server maybe should use another distro for the HN. Maybe I will try switch to lxc instead of openvz as it is in the
[asterisk-users] Dahdi for meetme on AMD64 arch?
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 %MEMTIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R1 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! -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
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? -- John Knight Classic City Telco LLC Email: j...@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 %MEMTIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R1 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! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I'm not very fond of the idea to rebuild everything on i386 architecture, but that's the last resort. /Johan 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 %MEMTIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R1 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! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
Ah, apologies, I just re-read your given Asterisk version. Indeed, I was using 1.8.5.0 at the time, not any 1.4.x release. Any digium timing card will work as an OpenVZ compatible dahdi timing device, I've seen this work on both Virtuozzo and OpenVZ. Setting it up, there's no difference in how you set up passthrough access using DEVNODES to the device from /dev inside the $CTID.conf file. Just make sure permissions inside the container make it writable by the asterisk user. -- John Knight Classic City Telco LLC Email: j...@classiccitytelco.com | Main: (706) 995-0200 Direct: (706) 995-0201 | Mobile: (706) 255-9203 On 1/18/2012 8:52 AM, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I'm not very fond of the idea to rebuild everything on i386 architecture, but that's the last resort. /Johan 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 %MEMTIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R1 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! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com --
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On Wed, Jan 18, 2012 at 02:52:47PM +0100, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I would be interested to learn if there was any problem with soft (coretimer) when DAHDI is running on your ne platform. I would not expect that. One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 16:45, John Knight skrev: Ah, apologies, I just re-read your given Asterisk version. Indeed, I was using 1.8.5.0 at the time, not any 1.4.x release. Any digium timing card will work as an OpenVZ compatible dahdi timing device, I've seen this work on both Virtuozzo and OpenVZ. Setting it up, there's no difference in how you set up passthrough access using DEVNODES to the device from /dev inside the $CTID.conf file. Just make sure permissions inside the container make it writable by the asterisk user. Okay, I will try that procedure tonight. I'll also remove my Intel dual nic card, and the network bonds. After that, then only difference to the machine working and the machine not working are i386 / amd6. And the os version - debian 5 / 6. Have you used 64 bit kernels (amd64) in your setup? Distribution? Thanks for your advices, it's very appreciated! /Johan On 1/18/2012 8:52 AM, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I'm not very fond of the idea to rebuild everything on i386 architecture, but that's the last resort. /Johan 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 %MEMTIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R1 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! --
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 17:50, Shaun Ruffell skrev: On Wed, Jan 18, 2012 at 02:52:47PM +0100, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I would be interested to learn if there was any problem with soft (coretimer) when DAHDI is running on your ne platform. I would not expect that. One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? The clock is accurate by ntp sync. It uses the vanilla debian config you get if you apt-get install ntp. Was it nt(p) you meant above? The clock drifts a lot if it is not synced by ntp. I've noticed most of my hp 360/380 servers to drift up to 10 minutes per week, including this server. But ntp fixes this right? If you have ideas how to debug this I would be very grateful. -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se direkt: +46 31 380 91 01 support: +46 31 380 91 00 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
"Have you used 64 bit kernels (amd64) in your setup? Distribution?" Aye, I use the current stable 64-bit rhel6 branch openvz kernel with centos 6 on the node and scientific linux 6 in the template without issue other than what I described before with res_timing_timerfd.so pegging the cpu and coring Asterisk. It's never a suggestion a debian user wants to hear, but as the vanilla 2.6.32 openvz kernel has effectively been abandoned by the OpenVZ dev team in favor of the rhel6 version of 2.6.32, and since the node shouldn't really be doing anything other than hosting the templates, have you considered running centos6/rhel6-openvz kernel on the node and debian in the containers? Just a suggestion, but no further openvz development is being done to the vanilla 2.6.32 branch and the rhel6 openvz kernel will consistently have bug fixes and and backports. Not trying to start a distro war or anything, rather just a suggestion. -- John Knight Classic City Telco LLC Email: j...@classiccitytelco.com | Main: (706) 995-0200 Direct: (706) 995-0201 | Mobile: (706) 255-9203 On 1/18/2012 1:01 PM, Johan Wilfer wrote: 2012-01-18 16:45, John Knight skrev: Ah, apologies, I just re-read your given Asterisk version. Indeed, I was using 1.8.5.0 at the time, not any 1.4.x release. Any digium timing card will work as an OpenVZ compatible dahdi timing device, I've seen this work on both Virtuozzo and OpenVZ. Setting it up, there's no difference in how you set up passthrough access using DEVNODES to the device from /dev inside the $CTID.conf file. Just make sure permissions inside the container make it writable by the asterisk user. Okay, I will try that procedure tonight. I'll also remove my Intel dual nic card, and the network bonds. After that, then only difference to the machine working and the machine not working are i386 / amd6. And the os version - debian 5 / 6. Have you used 64 bit kernels (amd64) in your setup? Distribution? Thanks for your advices, it's very appreciated! /Johan On 1/18/2012 8:52 AM, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk 1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I'm not very fond of the idea to rebuild everything on i386 architecture, but that's the last resort. /Johan 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,
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On 01/18/2012 12:15 PM, Johan Wilfer wrote: 2012-01-18 17:50, Shaun Ruffell skrev: On Wed, Jan 18, 2012 at 02:52:47PM +0100, Johan Wilfer wrote: 2012-01-18 11:31, John Knight skrev: 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? Hi! I think the timing support was included in asterisk in 1.6.1/1.6.2. As I run 1.4 these modules are not available at all. Do you run asterisk1.6 and amd64? Another option would be to port my dialplan to a newer version of asterisk if this can resolve the issue. A workaround I've been tinking about is to try to put a spare Digium-card in the server just for timing, if there is something strange with the soft dahdi timing. I would be interested to learn if there was any problem with soft (coretimer) when DAHDI is running on your ne platform. I would not expect that. One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? The clock is accurate by ntp sync. It uses the vanilla debian config you get if you apt-get install ntp. Was it nt(p) you meant above? The clock drifts a lot if it is not synced by ntp. I've noticed most of my hp 360/380 servers to drift up to 10 minutes per week, including this server. But ntp fixes this right? That's pretty severe, and could certainly cause problems for DAHDI trying to use the kernel as a timing source. NTP will correct the drift, but the drift is still happening and it's not corrected on every tick. If the ticks are not happening at the rate they are supposed to, then DAHDI will not be operating at the clock rate it is supposed to. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On Wed, Jan 18, 2012 at 12:58:31PM -0600, Kevin P. Fleming wrote: On 01/18/2012 12:15 PM, Johan Wilfer wrote: 2012-01-18 17:50, Shaun Ruffell skrev: One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? The clock is accurate by ntp sync. It uses the vanilla debian config you get if you apt-get install ntp. Was it nt(p) you meant above? The clock drifts a lot if it is not synced by ntp. I've noticed most of my hp 360/380 servers to drift up to 10 minutes per week, including this server. But ntp fixes this right? That's pretty severe, and could certainly cause problems for DAHDI trying to use the kernel as a timing source. NTP will correct the drift, but the drift is still happening and it's not corrected on every tick. If the ticks are not happening at the rate they are supposed to, then DAHDI will not be operating at the clock rate it is supposed to. Kevin, this looks like a good candidate for using the monotonic interface in the kernel that we were talking about last week or the week before. The specific function call escapes me at the moment. Johan, I can't do it right this second, but I'll prepare an issue / patch against a 2.6.32 kernel that should make dahdi less prone to clock skew from NTP (although you probably want to get that fixed somehow) if you would be willing to test it for me on your server. Another thing you can try in the meantime is switch to DAHDI 2.5.0.2 and edit drivers/dahdi/Kbuild to enable dahdi_dummy which will use the (relatively inefficient for the purposes of conferencing) highres timers when loaded by default on recent kernels (if compiled in). Cheers, Shaun -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
On 01/18/2012 01:06 PM, Shaun Ruffell wrote: On Wed, Jan 18, 2012 at 12:58:31PM -0600, Kevin P. Fleming wrote: On 01/18/2012 12:15 PM, Johan Wilfer wrote: 2012-01-18 17:50, Shaun Ruffell skrev: One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? The clock is accurate by ntp sync. It uses the vanilla debian config you get if you apt-get install ntp. Was it nt(p) you meant above? The clock drifts a lot if it is not synced by ntp. I've noticed most of my hp 360/380 servers to drift up to 10 minutes per week, including this server. But ntp fixes this right? That's pretty severe, and could certainly cause problems for DAHDI trying to use the kernel as a timing source. NTP will correct the drift, but the drift is still happening and it's not corrected on every tick. If the ticks are not happening at the rate they are supposed to, then DAHDI will not be operating at the clock rate it is supposed to. Kevin, this looks like a good candidate for using the monotonic interface in the kernel that we were talking about last week or the week before. The specific function call escapes me at the moment. Indeed it does :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dahdi for meetme on AMD64 arch?
2012-01-18 20:06, Shaun Ruffell skrev: On Wed, Jan 18, 2012 at 12:58:31PM -0600, Kevin P. Fleming wrote: On 01/18/2012 12:15 PM, Johan Wilfer wrote: 2012-01-18 17:50, Shaun Ruffell skrev: One question first though, is your new server able to keep accurate time with nt, or is the clock drifting or experiencing heavy jitter? The clock is accurate by ntp sync. It uses the vanilla debian config you get if you apt-get install ntp. Was it nt(p) you meant above? The clock drifts a lot if it is not synced by ntp. I've noticed most of my hp 360/380 servers to drift up to 10 minutes per week, including this server. But ntp fixes this right? That's pretty severe, and could certainly cause problems for DAHDI trying to use the kernel as a timing source. NTP will correct the drift, but the drift is still happening and it's not corrected on every tick. If the ticks are not happening at the rate they are supposed to, then DAHDI will not be operating at the clock rate it is supposed to. Didn't think of that. I've turnd of ntpd now to see exactly how much the clock skew when ntpd is not running. root@milkyway:/home/johan# ntptime ntp_gettime() returns code 0 (OK) time d2c1ac73.45214000 Wed, Jan 18 2012 21:39:15.270, (.270039), maximum error 167603 us, estimated error 815 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 522.000 us, frequency 124.445 ppm, interval 1 s, maximum error 167603 us, estimated error 815 us, status 0x1 (PLL), time constant 6, precision 1.000 us, tolerance 500 ppm, This is the server running dahdi_test at the same time: root@milkyway:/home/johan# dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.602% 99.991% 99.614% 99.983% 99.608% 99.999% 99.611% 100.000% 99.999% 99.998% 99.999% 99.995% 99.609% 99.613% 99.997% 99.608% 99.611% 99.999% 99.608% 99.610% 99.998% 99.999% 99.999% 99.995% 99.987% 99.999% 99.999% 99.999% 99.999% 99.996% 99.999% 99.999% 99.995% 99.998% 99.999% 99.999% 99.999% 99.998% 99.999% 99.992% 99.994% 99.999% 99.989% 99.999% 99.998% 99.998% 99.996% 99.998% 99.998% 99.983% 99.999% 99.998% 99.999% 99.992% 99.997% 99.997% 99.982% 99.979% 99.986% 99.993% 99.999% 99.999% 99.999% 99.995% 99.999% 99.997% 99.993% 99.995% 99.998% 99.998% 99.999% 99.998% 99.998% 99.998% 99.999% 99.999% 99.999% ^C --- Results after 77 passes --- Best: 100.000% -- Worst: 99.602% -- Average: 99.945879% Cummulative Accuracy (not per pass): 99.998 Kevin, this looks like a good candidate for using the monotonic interface in the kernel that we were talking about last week or the week before. The specific function call escapes me at the moment. Johan, I can't do it right this second, but I'll prepare an issue / patch against a 2.6.32 kernel that should make dahdi less prone to clock skew from NTP (although you probably want to get that fixed somehow) if you would be willing to test it for me on your server. Another thing you can try in the meantime is switch to DAHDI 2.5.0.2 and edit drivers/dahdi/Kbuild to enable dahdi_dummy which will use the (relatively inefficient for the purposes of conferencing) highres timers when loaded by default on recent kernels (if compiled in). Cheers, Shaun Great, I will try this. I start with dahdi_dummy and check the results. Thank you! -- Johan Wilfer email: jo...@jttech.se JT Tech | Developer webb: http://jttech.se -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
