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

[Johan Wilfer]

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 at 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 at 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: johan at jttech.se
JT Tech | Developer          webb: http://jttech.se