NTP is wrong by almost 3 minutes.
-
I ran ti twice, here is the output, I noticed at the end of the first run, after it gives me the offset time it says "325 sec", whats taht about?
ntpdate -d time.nist.gov 21 Dec 12:27:10 ntpdate[90838]: ntpdate 4.2.8p8@1.3265-o Tue Jul 19 16:25:10 UTC 2016 (1) transmit(128.138.141.172) receive(128.138.141.172) transmit(128.138.141.172) receive(128.138.141.172) transmit(128.138.141.172) receive(128.138.141.172) transmit(128.138.141.172) receive(128.138.141.172) server 128.138.141.172, port 123 stratum 1, precision -29, leap 00, trust 000 refid [NIST], delay 0.09991, dispersion 0.00021 transmitted 4, in filter 4 reference time: dc0563c9.00000000 Wed, Dec 21 2016 12:25:45.000 originate timestamp: dc056424.63b52a21 Wed, Dec 21 2016 12:27:16.389 transmit timestamp: dc056424.5befb402 Wed, Dec 21 2016 12:27:16.359 filter delay: 0.09991 0.09993 0.10071 0.10135 0.00000 0.00000 0.00000 0.00000 filter offset: -0.00832 -0.00838 -0.00796 -0.00751 0.000000 0.000000 0.000000 0.000000 delay 0.09991, dispersion 0.00021 offset -0.008325 21 Dec 12:27:16 ntpdate[90838]: adjust time server 128.138.141.172 offset -0.008 sec 325 sec ```ntpdate -d time.nist.gov
21 Dec 12:32:39 ntpdate[16340]: ntpdate 4.2.8p8@1.3265-o Tue Jul 19 16:25:10 UTC 2016 (1)
transmit(129.6.15.30)
receive(129.6.15.30)
transmit(129.6.15.30)
transmit(129.6.15.30)
receive(129.6.15.30)
transmit(129.6.15.30)
transmit(129.6.15.30)
server 129.6.15.30, port 123
stratum 1, precision -29, leap 00, trust 000
refid [ACTS], delay 0.15990, dispersion 24.00020
transmitted 4, in filter 4
reference time: dc056561.1ebacc2a Wed, Dec 21 2016 12:32:33.120
originate timestamp: dc05656b.6a52fae8 Wed, Dec 21 2016 12:32:43.415
transmit timestamp: dc05656d.512dbb90 Wed, Dec 21 2016 12:32:45.317
filter delay: 0.15997 0.00000 0.15990 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.030677 0.000000 0.031073 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.15990, dispersion 24.00020
offset 0.03107321 Dec 12:32:47 ntpdate[16340]: adjust time server 129.6.15.30 offset 0.031073 s ec
-
Not sure, don't think ever seen anything like that before.
You can see it sends 4 queries, and shows your offset from all 4 off them
filter offset: -0.00832 -0.00838 -0.00796 -0.00751
So not sure where that odd 325 display would come from??
-
Any guesses as to why I am seeing such a big difference?
-
Grasping at straws, but is the hardware clock on the unit itself correct?
-
I dont know, how could I check that?
-
If it's a PC of some type then I would look in the BIOS. If it's something else then I don't know.
-
I hate to ask stupid questions, but there are some basics…
1. Ignoring the NTP widget for the moment, what is shown as the current date/time in the System Information widget? Does it agree or disagree with www.time.gov?
2. Have you cleared your browser's cache?
-
To eliminate all possible browser cache problems just go to Diagnostics ->Command Prompt
type "date" without quotes and wait for the answer.
Or do the same in shell…I don't think it's related to any cache just because in logs we already have
"21 Dec 12:27:16 ntpdate[90838]: adjust time server 128.138.141.172 offset -0.008 sec 325 sec"
To check what hardware clocks you have run
dmesg | grep timerand/or
sysctl kern.timecounter
You should see all possible timers and counters found and/or used by system. You can also change it to desired, tuning kern.timecounter.hardware.
Read https://www.freebsd.org/doc/en/books/faq/troubleshoot.html -
Thanks all, the System Information Widget was also wrong.
w0w's suggestion seems to have fixed system time.
: 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 1546529202 Hz quality 1000: sysctl kern.timecounter.hardware=HPET kern.timecounter.hardware: TSC-low -> HPETSo now System time matches time.gov, however NTP time remains the same although I don't know if this will fix itself given a little time? I restarted the service but the NTP offset remains the same.
-
I'm seeing the same issue with the NTP time being off by 5mins. Never noticed that till now. My system clock matches the NIST time though.
Running 'date' from the command prompt returns the system time which is correct to the NIST time. The NTP widget is 5 mins off
-
I just polled the ntp server pool I'm using (pool.ntp.org) and it is off by the same 5 mins.
sntp 0.pool.ntp.org
When I poll nist it shows the same 5 minute discrepancy
sntp 128.138.141.172
-
If anyone is interested I switched my ntp servers from ntp.org to the NIST servers and the discrepancy has resolved itself..
-
That is interesting.
I have been using time.nist.gov for a few days now and my NTP time is still off by a few minutes. System time now matches up but NTP has not resolved itself, I restarted the service over a day ago and it is still off by a few minutes.
Anyone know what the root problem is here, especially now that I am apparently not the only one seeing some issues with time?
-
I'm sure you do, but just to check you do have your machines set to use your pfsense as the ntp time server?
-
Some of them are and some aren't what I'm looking at is that the NTP time widget on my pfSense box is not syncing up with time.gov, even though it is using NIST for NTP. My system clock is synced up.
Also, my machines that are using pfsense for time match the incorrect pfsense time widget exactly.
My machines that are not using pfsense for time (cellphone, laptop) match time.gov exactly.
-
I just successfully tested time.nist.gov sync without any issue.
Please provide the output of
more /var/etc/ntpd.conf -
I was having the same problem, running on 2.4 i would select to run NTP on the Lan side and it would never sync. If i manually sync'ed then it would work.
-
Some of the NTP tools included with pfSense can be a big help in figuring out what is going wrong. The place to start is likely ntpq:
[2.3.2-RELEASE][root@pfSense.home]/root: ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *pi-v1.home .GPS0. 1 u 12 64 377 0.420 -0.034 0.008 +hp400.home 172.16.0.4 2 u 44 64 377 0.412 5.662 0.782 +ntp.cox.net .GPS. 1 u 14 64 377 51.577 1.667 0.452The above shows that I am syncing with my Pi while my hp server and Cox Cable NTP servers are available as fallbacks.
The first column is the sync status and is covered in the http://www.ntp.org/ documentation. If you are not selecting servers and syncing to one of them you have a starting place to look for your problem.
I'd go look at at least the quick start at ntp.org and select either a pool or at least three servers to sync to before going on to look for other issues.
-
I finally got around to having a look at the code for the NTP widget. The "Server Time" field is created using some cute dynamic update code that plays games between the http server (aka pfSense) time and the http client browser time. The approach was likely state of the art… in 2003 when it was last updated. Seriously, the code lists compatibility as IE 4.x/5.0, Netscape 4.x/6.0, and Mozilla 1.0.
The short version is that this code is badly need of replacing, and until it is replaced the Server Time field in the NTP widget should simply be ignored.
One more "as time permits" activity. :)
-
I finally got around to having a look at the code for the NTP widget. The "Server Time" field is created using some cute dynamic update code that plays games between the http server (aka pfSense) time and the http client browser time. The approach was likely state of the art… in 2003 when it was last updated. Seriously, the code lists compatibility as IE 4.x/5.0, Netscape 4.x/6.0, and Mozilla 1.0.
The short version is that this code is badly need of replacing, and until it is replaced the Server Time field in the NTP widget should simply be ignored.
One more "as time permits" activity. :)
Wow, thank you so much for looking into this! I'm glad that this could resolve into something that will eventually be an improvement to pfSense!
