[Solved] ntpd won't keep correct time, frequency drift too large

[Pseudobolt]

I'm making this post in case anyone else runs into the same issue and looks for an answer in the forums -- I did a search and can't find any threads covering this issue.

You may have the following symptoms:

• ntp fails to keep correct time. Running 'ntpd -q' (to set the time and exit) will set the time correctly, but over time it drifts and eventually ends up wrong, in my case by more than an hour (after a week or two).
• This in turn will cause Samba (Windows) shares to not work, as the authentication fails because the time difference between client and server is too great.

Error messages may appear in the syslog (you can see them at the bottom of the FreeNAS GUI):

ntpd[12345]: frequency error 765 PPM exceeds tolerance 500 PPM

I found this freeBSD troubleshooting guide which helped me determine the problem: the timesource chosen by the operating system is not reliable. Read the link for details -- the short summary is to run the following two commands in the console to display the timesources:

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

(You will probably get a different output, but something along these lines.)

Then try changing the OS kernel time source and restarting ntpd.

# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-fast -> TSC
# service ntpd restart
Restarting ntpd...

Give it a little while and see if the ntpd errors stop. If not, repeat with a different timecounter until you find one that works.

(In my case, the default counter "TSC-low" and the "ACPI-fast" counter both were unreliable, but I when I used "HPET" it worked.)

Once you've found one that works, add it to the sysctls in the freeNAS GUI so that it gets set every time on startup. (Variable name is kern.timecounter.hardware, value is the name of the counter that works for you, eg 'TSC' in the example above.)

Hope this turns out to be helpful for someone down the line. :)

 

[cyberjock]

Can you post the motherboard and CPU you are using? This seems.... odd. My first guess is you are using AMD stuff. :P

 

[Pseudobolt]

No, actually it's an Intel S5000PSL with two Xeon 5420s.

I have to say I'd never heard of this problem before now, but it must have happened to other people before if it made it into
that troubleshooting guide.

 

[jgreco]

As someone who works with the Network Time Project, and who has had to wrestle with timesources under FreeBSD and other operating systems for years, I can tell you that this is more of an OS issue ... PC hardware is just kind-of flaky. FreeBSD makes a modest effort to determine what is most likely to work, but the sad fact is that PC hardware is kind of broken and this is at best an intelligent guess. The fact that multiple clock sources are available and that the OS supports them all says mountains about how difficult this is to do correctly. I am actually amazed that this doesn't turn up as an issue more often.