Bogus time in NTP status widget
-
@kom said in Bogus time in NTP status widget:
@rmaeder The time seems to go horribly out of sync in Firefox but not so much in Chrome.
My screenshots were from Chrome, latest version on Debian buster
-
To be honest I believe system time widget might just pull time from your PC that is viewing the page?
If they are not using the same time source - then it is possible for a disconnect between these two displays.
I would validate that your system your viewing the page from is sync'd and correct, with correct timezone, etc.
I am not seeing any sort of issue. While the 2 different widgets after different update periods - they will not actually run in sync with each other. For example if one updates every 5 seconds and the other every 1 second.
I would do just simple date command from cmd line on pfsense - does this show the correct time and zone?
[21.02.2-RELEASE][admin@sg4860.local.lan]/root: date Thu May 13 09:50:41 CDT 2021
-
@johnpoz
The times of all my machines are within a few microseconds.
I am Swiss, and I care about precision time keeping
My PC is on CST, the pfSense router is set to UTC.
The problem shows when the tab with the status display is left in the background for some time and then brought to the front.
It just lost another 50min.
It probably is not updating correctly when not in the foreground. -
I see the same behavior. If the dashboard is in the foreground the time is correct. If not, then the widget time appears to not update. Once it is in the foreground again it starts updating from the last time instead of showing the actual time.
Just a guess, but I would say the widget is not programed to show the current time, but instead increments the time from the last refresh.
I always refresh to make sure it is correct.Or...
It is a feature to show how long the dashboard was not in front. -
@andyrh said in Bogus time in NTP status widget:
but instead increments the time from the last refresh.
That is quite possible.. And would explain what is being seen. Calling it a feature is a nice idea ;) hehehe
-
On my Hyper-V VM and host... ¯\(ツ)/¯
-
I don't see where the problem is with your post @provels
As we are assuming the 2 widgets update at different cycles, so its quite possible to differences like this with systems that are not showing polling and displaying the time at the same rates..
Something that shows the 3 sources at the same time would be needed to see if they are in fact in sync, etc..
Using a simple windows cmd, I can check time to see the offsets from 3 different sources. My pc, pfsense, and my ntpserver.. All within less than a ms..
$ w32tm /monitor /computers:192.168.9.100,192.168.9.253,192.168.3.32 192.168.9.100[192.168.9.100:123]: ICMP: 0ms delay NTP: +0.0000284s offset from local clock RefID: 192.168.3.32 [192.168.3.32] Stratum: 2 192.168.9.253[192.168.9.253:123]: ICMP: 0ms delay NTP: -0.0000537s offset from local clock RefID: 192.168.3.32 [192.168.3.32] Stratum: 2 192.168.3.32[192.168.3.32:123]: ICMP: 0ms delay NTP: +0.0001672s offset from local clock RefID: 'PPS [0x00535050] Stratum: 1
I wouldn't take what a widget shows as accurate time for anything other than a few seconds at best - all depending on what exactly its showing and how often it refreshes, etc.
While I can understand the concern of wildly different values being displayed - I think the theory of system widget not refreshing in background, and then only refreshing value from its last actual query for time does explain what is going on with the widgets in a browser.
If the concern is to know if the pfsense ntp is in sync with its source - the ntpq output would be much better source for this information.
[21.02.2-RELEASE][admin@sg4860.local.lan]/root: ntpq ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== *ntp.local.lan .PPS. 1 u 230 512 377 0.373 +0.257 0.107 ntpq>
Or looking at the monitor graph.. Here is mine going back for the last week for example
-
@johnpoz said in Bogus time in NTP status widget:
w32tm /monitor /computers:192.168.9.100,192.168.9.253,192.168.3.32
Thanks for the command. For some reason my host won't give me the time, but I wasn't really concerned. Everyone goes to pool.ntp.org anyway. Just thought the disparity in the display was unusual.
-
@provels said in Bogus time in NTP status widget:
Everyone goes to pool.ntp.org anyway
No not everyone ;) You have all your devices go to out to the internet to pool? Why would they not sync either off pfsense or your local ntp server?
My ntp server participates by being a server in the pool.. But no I don't sync time from there.
If you have client A syncing to pool, and client B syncing to pool - they could have quite a bit of difference in time, when it comes to what is possible with ntp.. Vs all clients syncing to the same source like your pfsense, even if pfsense syncs from pool.
Your talking milliseconds normally here.. But when it comes to ntp, 80ms and 1ms is a big difference ;) heheh Normally like to be sub ms range.
Pfsense time looks to be fine, and would assume your client the same, etc. I think the whole issue here is trying to express time in a browser widget ;)
I would assume when @rmaeder refreshes his browsers any large differences in the widgets goes away.
-
@johnpoz said in Bogus time in NTP status widget:
I would assume when @rmaeder refreshes his browsers any large differences in the widgets goes away.
when I put the pfsense window into the background for 10 minutes, then bring it back, the time in the ntp widget is off by about 5 minutes.
-
it's a simple php line
<div id="datetime"><?= date("D M j G:i:s T Y"); ?></div>
with a functuon that update every 6
function stats(x) { ... updateDateTime(values[6]); ... }
it is not meant to be a precision time keeper,
it's more like a "snapshot" for when you go to the dashboard -
@johnpoz said in Bogus time in NTP status widget:
Why would they not sync either off pfsense or your local ntp server?
This, pfSense. NTP listening on LAN or ALL.
If you have client A syncing to pool, and client B syncing to pool - they could have quite a bit of difference in time
Understood, thanks.
-
What are you lan rules - the any any rule? Are you forcing traffic out a gateway? Do you have floating rules?
Windows should sync time with ntp on pfsense, if ntp services are running and in sync and you have the firewall rules to allow it.
I personally run actual ntp on my windows machine vs the built in service.. But that is just me..
But windows way still works
-
@johnpoz
Tried hitting Update again a few more times, then it worked. LAN rules are pfBlockerNG generated plus LAN/ANY. I don't think LAN rules should be required to use NTP. I'm pretty sure I remember having clients set to pfSense time in the past, but the times getting out of whack so I went back to pools. -
@provels said in Bogus time in NTP status widget:
I don't think LAN rules should be required to use NTP.
Not if they default any any.. But if you had modified the rules in a such a manner then sure you could block them. I do not believe there are hidden rules like there is with dhcp.. But maybe there is. I would have to look.. BRB
yeah I don't see hidden rules that allow ntp when you enable it, like what happens with dhcpd.. So yeah it would be quite possible for a user to block ntp in their firewall rules. Out of the box no, the default any any rule would allow it.
Personally the built in time sync of windows is a bit lacking ;) I just disable it and use the actual client from ntp.org - you can grab a windows copy here
https://www.meinbergglobal.com/english/sw/ntp.htm -
@johnpoz said in Bogus time in NTP status widget:
I just disable it and use the actual client from ntp.org
Thanks, maybe I'll try that.
They say the man with 2 watches never really knows what time it is... :) -
ut-oh ;) we may have a future stratum 1 time server owner soon..
ntp is fascinating to me.. There are few around here as well that run their own.. It can be done fairly cheaply with pi and a gps hat for it.
Some interesting threads if you look for them.. Some have some really great setups, mine is bit older and not as accurate as it could be.. It sub 1ms, have seen like 20ns setups..
I have not gotten into the tinker with it mood in quite some time to play around with tweaking it to see if could get it to be more stable. Last thing I did with it really was switch it to running ntpsec... I should prob reset up my monitoring of it I guess ;) To better track how well its doing..
pi@ntp:~ $ ntpq ntpq> pe remote refid st t when poll reach delay offset jitter ======================================================================================================= *SHM(1) .PPS. 0 l - 8 377 0.0000 -0.0388 0.0088
Looks to be within 40ns - but should prob graph that to see how its drifting, etc.