NTP widget time wrong?
-
@JonathanLee
I suppose you mean NAT redirection , to catch "Naugthy clients" that doesn't adhere to the NTP server they get from DHCPNope ...
All my NTP clients seem to be well behaved.
I don't log many rogue NTP requests.I only allow NTP requests to TFW (pfSense IF's) on all but one Vlan.
My pfSense & Linux servers are Synced to my two "stratum 0" Boxes , and have a few selected "stratum 1" servers as backup./Bingo
-
@bingo600 said in NTP widget time wrong?:
What time server are you using ??
pfSense is a firewall, not a Time server.
And my guess is that the NTP server is distributing the correct time, mine does.
It's just the Widget that doesn't spend CPU-Cycles on autorefresh.Bingo, now that I understand what the issue is, I agree. But spending the time to build up a GPS based Stratum 1 time server then have the widget lag... was a bit disconcerting. I spent a lot of time trying to fix something that wasn't broke. Unfortunately, when I searched the issue here, I wasn't shown Anthonys' previous thread. Of all the widgets on the dashboard, I somehow had the mistaken idea the NTP widget would be the ONE to have have accurate "TIME".
The time server I am using is Raspberry Pi based, uses a GPS hat from Uputronics and after a couple of other builds (that showed the same widget issue in pfSense), I settled on the configuration from Phil Randal (Phil's Occasional Blog). His build is much more involved but really ties down the "time" function of GPS as opposed to location or movement. He also makes it easy to use or not use various GPS sources from config files on the server. The other option is to remove the hat and run u-Blox u-Center software to access and configure the GPS settings of the M8/8 chip via USB-C on the hat itself.
All of the time needy devices on my network are getting their time from pfSense, I may need to reassess that. But, until now, it has worked for years with offsite sources.
Hopefully the devs will look at this and fix it at some point... wasted cpu cycles or not. My little SG-4860 generally runs at about 10% load, so I think I have the available cycles to support a fully functional widget.
Until then, maybe an option to NOT show a dysfunctional clock and a disclaimer of it's shortcomings might be a nice stopgap.
-
@Ramosel said in NTP widget time wrong?:
time-c-b.nist.gov
Just tried adding that...somehow pfSense is not seeing it as a valid address after clicking save. I take it the "c" is for central time.
Tried the IP and it took that...
-
@NollipfSense time-c-g.nist.gov resolves just fine. But you shouldn't be marking things as pools when they are not pools.
;; QUESTION SECTION: ;time-c-g.nist.gov. IN A ;; ANSWER SECTION: time-c-g.nist.gov. 3600 IN A 129.6.15.30
https://tf.nist.gov/tf-cgi/servers.cgi
Looks like you have a space on the end there as well..
-
@johnpoz Thanks John, I'll fix that.
That worked...
-
@NollipfSense said in NTP widget time wrong?:
@Ramosel said in NTP widget time wrong?:
time-c-b.nist.gov
Just tried adding that...somehow pfSense is not seeing it as a valid address after clicking save. I take it the "c" is for central time.
No, it's just a lesser used IPV4 server in Boulder. Dave MIlls is an old acquaintance and when I spoke with him about my pfSense setup a few years back he said the a-b servers get hammered the most... all the IPV6 guys flock to the d-b and e-b servers... use c-b.
https://tf.nist.gov/tf-cgi/servers.cgi
-
@Ramosel
That is actually not a bad price for the "Hat" ... ā¬50 from France.Right now i'm doing a DIY NTP server, with an OrangePI One.
That will be built in my - RAPCO 1804 L25C GPSDO Receiver
I have chosen the OrangePi over the RasPi's (I have 10+ 3B's in the drawer), due to the Lan CHIP being connected directly to the SoC.
The RasPi 3B Lan chip is actually USB coupled, and that causes a bit of jitter.This is my current "burn in" test of the OrangePi.
With a DS3231 IIC Module - https://www.aliexpress.com/item/32822420722.html$ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- 32 33 34 35 36 -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
$ sudo hwclock --verbose hwclock from util-linux 2.36.1 System Time: 1695225080.007973 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1695223549 seconds after 1969 Last calibration done at 1695223549 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2023/09/20 15:51:41 Hw clock time : 2023/09/20 15:51:41 = 1695225101 seconds since 1969 Time since last adjustment is 1552 seconds Calculated Hardware Clock drift is 0.000000 seconds 2023-09-20 17:51:39.554254+02:00
The hardware will be "transplanted" into the GPSDO Box , and i will piggyback on the existing Trimble GPS receiver (RX + 1PPS).
Then install & run GPSD + NTP w. 1-PPS support/Bingo
-
@bingo600 yes, that is what I mean to NAT to your NTP server's IP address for clients not manually going to it. For me I use authenticated NTP so the firewall points to those when requests hit the firewall.
-
@bingo600 said in NTP widget time wrong?:
@Ramosel
That is actually not a bad price for the "Hat" ... ā¬50 from France.Right now i'm doing a DIY NTP server, with an OrangePI One.
That will be built in my - RAPCO 1804 L25C GPSDO ReceiverI like that, sweet. Thanks for the info. Most of these builds are turning off the USB and using GPIO. The i2c gets really simple. Phil gets really deep into fine tuning after you get it running... I need to go back and do more, but I though the Pi NTP server was causing the widget issue. Now that I know it's not, I'll dig deeper into the GPS/NTP/PPS dialog.
pi@RPi4b-NTP-GPS:~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --I'm curious if Phil's build would work on the Orange Pi??
http://www.philrandal.co.uk/blog/archives/2019/04/entry_213.html -
Cannot get the devices to agree on time, one will be -0.046s while another device will be +0.045s
-
@Ramosel said in NTP widget time wrong?:
I'm curious if Phil's build would work on the Orange Pi??
http://www.philrandal.co.uk/blog/archives/2019/04/entry_213.htmlThe Trimble TSIP protocol is somewhat special, compared to NMEA.
But i'm in contact with the maintainer of the TSIP part of GPSD, and he's quite sure GPSD will work.
Even with a receive only (Uart RX + 1-PPS) connection. I can't (won't) connect TX to the OrangePI, as that "belongs to the Rapco".If i go totally crazy i could test for "missing 1-PPS" for ie. 20 sec , and then switch over to a 1-PPS divided down from the 10MHz OCXO in the Rapco.
That way "I'll be somewhat in sync .. Depends on the holdover routine in the Rapco" even with a GPS outage.Hmmm .... Maybe the HW dependent part should be moved to the "Off Topic thread" you made.
https://forum.netgate.com/topic/182811/raspberry-gps-based-time-server/Bingo
-
@bingo600 said in NTP widget time wrong?:
Hmmm .... Maybe the HW dependent part should be moved to the "Off Topic thread" you made.
https://forum.netgate.com/topic/182811/raspberry-gps-based-time-serverSure, now that I know I'm not crazy and the NTP clock is really grunged... I'm good here. I doubt that I'd ever build what you have, but you've got me interested and I'd sure like to follow the build. Use my thread or start your own, I'm cool either way.
Rick