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

[Kevin P. Fleming]

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 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?

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: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org