[asterisk-users] hardware clock drift and CDR

[Seann Clark]

On 4/26/2010 7:33 AM, Vieri wrote:
>
> --- On Sun, 4/25/10, Gordon Henderson<gordon+asterisk at drogon.net>  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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5544 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20100426/419fb7a3/attachment.bin