NTP and time drift

Good morning…

I have an Switchvox SMB AA355 Appliance and I have tried both using an NTP server and setting the time manually. It falls behind at a rate of about 45 seconds per day.

How and when is the NTP server checked? If I make any changes to time settings, all calls are dropped. How does the system do it without disrupting connections, or does it?


This is either a question for DIgium support, or is not Asterisk at all.

45 seconds a day is 520 ppm. ntpd can only cope with frequency errors of less than 500ppm (you need some headroom, as well).

The most common cause of this, these days, is trying to run it on a virtual machine. This is just about possible, if you configure the virtual machine properly, but is not as good as running it on a real machine. In any case, running VoIP on a VM is not a good idea, especially if that VM has clock frequency issues.

If you are running it on a real machine, you either have a broken motherboard, or you somehow started with an end stop value in ntp.drift, and it has not managed to contact any valid servers.

NB. Out of the box, w32time is not a valid server.

Thanks for the input, David.

Well, it’s not a VM, it’s a box straight from Digium. Anyone else with the AA355 have any time issues?

I tried using different NTP servers, internal (both IP and name) and external (us.pool.ntp.org) with no luck.

When I saved the NTP server names, it gives me a success message even if the time does not set correctly. I have never seen an error message there.

I don’t find anything in the advanced error logs about it either.

If you bought it from Digium, you probably want Digium support.

ntpd errors go in syslog (typically /var/adm/messages).

I would be very surprised if invalid servers were reported at the time you configured them.

The other main diagnostic for ntpd is ntpq. Once the system has stabilised for at least half an hour run /usr/sbin/ntpq.

First run:


Then run


rv 0

and then:

rv xxx

for each association id in the output from assoc. That will give you most of the information to see what is happening, although I repeat that a frequency error of more than about 450ppm is indicative of something being broken. It is possible to compensate in steps of 100ppm, but that may just be hiding the problem.

Please contact Digium’s Support department directly:

digium.com/en/users/support_ … roduct.php


We had the same issue after upgrading to 5.0.1.

Try entering your NTP settings in
Setup>Phones>Modify Phone Setup Options>Custom NTP Server
Reboot Server

This worked for us everything has been stable for about a week.

This would also imply that there is an issue with the interface since 5.0.1 that the NTP settings are not properly writing the ntpd.conf.

Hope this helps.

The original report quoted a drift rate that was outside of ntpd’s ability to correct, other than by repeatedly stepping the time, indicating a more serious error with the system.