Re: [asterisk-users] hardware clock drift and CDR

Seann Clark Mon, 26 Apr 2010 06:04:30 -0700

On 4/26/2010 7:33 AM, Vieri wrote:


--- On Sun, 4/25/10, Gordon Henderson<[email protected]>  wrote:

Hi,

I've noticed that one of my new servers (new mobo) if

drifting slowly

backwards in time (in aprox. 24 hours, system time

drifts back 5

minutes).

I have an ntpd process which is supposed to sync with

a lan time server

but it's not quite working. So I'm launching a manual

ntpdate or

ntp-client once an hour and that seems to work.

If you can run ntpdate and it sets the time, then you are
not running
ntpd. The 2 can not run at the same time.

Hi Gordon,

Are you sure about this? ntpd is a daemon and adjusts the time in a continuous 
manner. ntp-client or ntpdate or whatever are one-time clients that reset the 
system clock. I don't see why an ntp-client can't be run while ntpd is working 
(it shouldn't be necessary but may come in handy when the time difference is 
big and ntpd refuses to sync).

Anyway, I've noticed that my ntpd log messages don't say "anything" when trying to sync 
to my "Windows PDC LAN time server". Curiously, ntp-client DOES sync to this Windows 
server.
So I decided to sync to pool.ntp.org and now I see syslog messages that 
actually show that the system time gets adjusted by ntpd.

I'd rather sync to my LAN time server but this is off-topic on this ML.

How does Asterisk CDR count the duration/billsec

values? Does it rely on

system time ONLY for "call start" or also for "call

end"?

What Asterisk-related side-effects should I expect

from a drifting

clock?

Who cares. Just fix ntpd then your worys are gone.

Well, I still have doubts about that. I could look at * source code but I'd 
rather hear from someone here.

My ntp log shows this:

26 Apr 13:06:30 ntpd[534]: synchronized to xxx.xxx.xxx.xxx, stratum 2
26 Apr 13:21:24 ntpd[534]: time reset +2.318647 s
26 Apr 13:21:44 ntpd[534]: synchronized to xxx.xxx.xxx.xxx, stratum 2
26 Apr 13:37:46 ntpd[534]: time reset +2.325417 s
26 Apr 13:38:06 ntpd[534]: synchronized to xxx.xxx.xxx.xxx, stratum 2
26 Apr 13:54:11 ntpd[534]: time reset +2.327974 s
26 Apr 13:55:19 ntpd[534]: synchronized to xxx.xxx.xxx.xxx, stratum 2
26 Apr 14:09:16 ntpd[534]: time reset +2.177572 s
26 Apr 14:10:08 ntpd[534]: synchronized to xxx.xxx.xxx.xxx, stratum 2
26 Apr 14:26:07 ntpd[534]: time reset +2.357017 s

That kind of scares me because if I'm not mistaken it means that about every 20 seconds, 
my ntpd adjusts the system time by about 2 seconds forward. So my clock is going back 2 
seconds every 20... That's a significant drift. And it would definitely make a difference 
in my CDR records IF Asterisk were to compare the "start and end" system times.

Should I worry about this?

Vieri

If it is NTP that you are worried about, you can see what your servers look like by doing an ntpq -p which should show you the clocks in the pool, which ones it is using etc. Example:

remote refid st t when poll reach delay offset jitter

==============================================================================

*clock.trit.net 192.12.19.20 2 u 385 512 377 50.220 3.094 0.558 +blue.nonexiste. 91.189.94.4 3 u 339 512 377 49.154 -16.663 4.596 +216.45.57.38 216.218.254.202 2 u 155 512 377 50.238 1.419 0.481

With my system synchronized to clock.trit.net. That is off my master clock, and everything else is synced to it by +/- 1 second. To fix this the easiest way, that I have seen at least, stop ntpd, do an ntpdate to your primary chosen clock (ntpdate clock.trit.net in my example) and restart ntpd and verify that your clock is sync'ed accurately. Also verify that it isn't hitting your hardware dummy clock in ntpd.conf, and if it is, and you can't force it out, you can remove it temporarily.

Your CDR's will be screwy in terms of timestamps based on the system time constantly changing, as well as your log files being slightly off, and if you are doing anything remote to another box in terms of logging or database, it will be even more screwy.



~Seann

smime.p7s
Description: S/MIME Cryptographic Signature

-- 
_____________________________________________________________________
-- 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] hardware clock drift and CDR

Reply via email to