Bogus time in NTP status widget
-
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.