Hello FreeNAS forum members,
I recently installed FreeNAS 9.1.0-Release x64 and I'm having issues with the clock not keeping accurate time. My hardware is a Dell F1DH 1 U server. After lots of failed debugging I thought maybe the hardware was no good and exchanged the server for a identical one, but I'm having the same problem.
I turned on ssh root login so all the commands I use are going into that shell and not the shell opened by the gui. I use the 'date' command to do my clock checking. I have seen the time go backwards by an hour or two in a matter of minutes. I don't think it has ever gone into the future. Sometimes it will run for several hours and the time is spot on. I had ntpd configured with the default time servers and thought I would try others. I now have my local ISP's timeserver defined but that did not change anything.
I know ntpd is trying to keep the clock syncronized based on log entries:
[root@freenas] /mnt# grep "time reset" /var/log/messages
Aug 31 16:12:34 freenas ntpd[1963]: time reset +24982.994787 s
Aug 31 20:13:03 freenas ntpd[1963]: time reset +599.993700 s
Sep 1 16:09:18 freenas ntpd[11770]: time reset +16.376696 s
Sep 1 16:16:34 freenas ntpd[12365]: time reset +270.628151 s
Sep 1 17:49:45 freenas ntpd[13311]: time reset +4480.967340 s
Sep 2 04:07:12 freenas ntpd[14191]: time reset +299.960150 s
Those values look very high to me and they are all over the place. Sometimes it is so bad that ntpd can't fix it and shuts itself down:
Sep 1 01:05:32 freenas ntpd[1963]: time correction of 26098 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
To recover , I use 'ntpdate' to get the clock back to normal and then restart ntpd.
I did some research and discovered that my server has several clocks to choose from, each rated differently for accuracy:
[root@freenas] /mnt# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounters tick every 1.000 msec
Timecounter "TSC-low" frequency 1500082330 Hz quality 1000
By default TCC-low is chosen because of its high quality. However I read that this clock is based on the CPU which is not always dependable when power save is enabled on the CPU. I added a new sysctl in the web gui to use HPET instead. I saw the same clock problems. I edited the sysctl in the web gui to use i8254 instead. I saw the same clock problems. I have not tried ACPI-fast yet but I'm guessing that I'll see the same problems.
Right now my workaround (which I don't like at all) is to have cron run 'ntpdate' every five minutes.
Does anyone have any suggestions on how I can debug this? This doesn't look like normal skew where you would drift just a few seconds over time.
I recently installed FreeNAS 9.1.0-Release x64 and I'm having issues with the clock not keeping accurate time. My hardware is a Dell F1DH 1 U server. After lots of failed debugging I thought maybe the hardware was no good and exchanged the server for a identical one, but I'm having the same problem.
I turned on ssh root login so all the commands I use are going into that shell and not the shell opened by the gui. I use the 'date' command to do my clock checking. I have seen the time go backwards by an hour or two in a matter of minutes. I don't think it has ever gone into the future. Sometimes it will run for several hours and the time is spot on. I had ntpd configured with the default time servers and thought I would try others. I now have my local ISP's timeserver defined but that did not change anything.
I know ntpd is trying to keep the clock syncronized based on log entries:
[root@freenas] /mnt# grep "time reset" /var/log/messages
Aug 31 16:12:34 freenas ntpd[1963]: time reset +24982.994787 s
Aug 31 20:13:03 freenas ntpd[1963]: time reset +599.993700 s
Sep 1 16:09:18 freenas ntpd[11770]: time reset +16.376696 s
Sep 1 16:16:34 freenas ntpd[12365]: time reset +270.628151 s
Sep 1 17:49:45 freenas ntpd[13311]: time reset +4480.967340 s
Sep 2 04:07:12 freenas ntpd[14191]: time reset +299.960150 s
Those values look very high to me and they are all over the place. Sometimes it is so bad that ntpd can't fix it and shuts itself down:
Sep 1 01:05:32 freenas ntpd[1963]: time correction of 26098 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
To recover , I use 'ntpdate' to get the clock back to normal and then restart ntpd.
I did some research and discovered that my server has several clocks to choose from, each rated differently for accuracy:
[root@freenas] /mnt# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounters tick every 1.000 msec
Timecounter "TSC-low" frequency 1500082330 Hz quality 1000
By default TCC-low is chosen because of its high quality. However I read that this clock is based on the CPU which is not always dependable when power save is enabled on the CPU. I added a new sysctl in the web gui to use HPET instead. I saw the same clock problems. I edited the sysctl in the web gui to use i8254 instead. I saw the same clock problems. I have not tried ACPI-fast yet but I'm guessing that I'll see the same problems.
Right now my workaround (which I don't like at all) is to have cron run 'ntpdate' every five minutes.
Does anyone have any suggestions on how I can debug this? This doesn't look like normal skew where you would drift just a few seconds over time.