Gps receiver & ntp
-
I have a cheap USB to serial NEMA GPS, and it runs at 500ms off decent time.
-
Maybe a bit offtopic, but I remember I read something about GPS, UTC and the atomic clock not beeing in sync cause of leap seconds.
How does that work when you sync with both GPS and NTP? Do you get excact local time anyway, or will your server drift back and forth several seconds?
http://leapsecond.com/java/gpsclock.htm
-
Many NTP servers use GPS for their time sync, all you're doing is cutting out the middle man as it were.
The NTP protocol uses UTC and includes leap seconds. GPS time sources don't include the leap seconds, but they do include the offset from UTC so it's easy for receivers to work out the UTC time, which the NTP daemon will then use.
In short, it's all handled transparently for you and you don't have to worry about it.
-
Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):
-
Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):
Great article. It shows you why can't you do that built-into pfSense, especially inside ESXi.
- you need hardware GPI port to get into the system the PPS signal
- you need modified kernel to be able to process in nanoseconds time the PPS signal
But nevertheless you can build the whole box as described with a PI. I'd just mount it in a waterproof box and add PoE support and place the whole thing on the roof for the best GPS signal…
-
We have PPS_SYNC in the pfSense kernel, and you can get PPS over serial with a hardware serial port.
So you can do it on pfSense, it just requires the proper hardware.
-
Well spent a massive £19.95 on an unbadged USB GPS dongle, plugged it in - named the ports correctly in ESXi - rebooted the pfsense box - it found the GPS source and it started reporting status!
The only slight surprise is that it seems very slow to choose the GPS source as the active peer - both GPS and the back up external NTP server are shown as "False Ticker" and it uses the local clock.
Is there a way to make it choose the GPS source as a the preferred option if available or at least speed up the decision making process?
Just to make clear, not after a super accurate clock, just that our internet links are so erratic that we cn be out of contact for a few hours at a time- so if the GPS holds us to less than 0.1 of a sec that would be enough.
Andrew
-
I've found that using 3-4 NTP servers in addition to the GPS has made mine more likely to be used as the source.
Also GPS signal quality can affect things as well.
It's already set to prefer the GPS when possible but if it believes that the GPS is far enough off of reality, it can still be discarded.
-
Still confused.
WE run with the GPS enables and 0.uk.pool.ntp.org 1.uk and 2.uk etc as NTP servers.
It tooks about 2 hours to stop using local and switch to GPS as the timesource - worked solidly for about 48 hours and has now swapped to an internet time server even though GPS has by far the lowest jitter - what causes the swap (and how can I influence it?00
Thanks
Andrew
-
Can you post the output of ntpq -c pe and ntpq -c assoc?
Without having a better idea of what NTP is reporting we could only guess, which is pretty pointless ;)
-
Well spent a massive £19.95 on an unbadged USB GPS dongle, plugged it in - named the ports correctly in ESXi - rebooted the pfsense box - it found the GPS source and it started reporting status!
The only slight surprise is that it seems very slow to choose the GPS source as the active peer - both GPS and the back up external NTP server are shown as "False Ticker" and it uses the local clock.
Is there a way to make it choose the GPS source as a the preferred option if available or at least speed up the decision making process?
Just to make clear, not after a super accurate clock, just that our internet links are so erratic that we cn be out of contact for a few hours at a time- so if the GPS holds us to less than 0.1 of a sec that would be enough.
Andrew
What GPS is this can you link the model?
I find it interesting as mine runs half a second of normal time due to what i guess is the usb to serial conversion.
-
$ ntpq -c pe
remote refid st t when poll reach delay offset jitterxGPS_NMEA(0) .GPS. 0 l 11 16 377 0.000 -533.88 1.737
LOCAL(0) .LOCL. 12 l - 64 0 0.000 0.000 0.000
+ntp.demon.co.uk 195.66.241.10 2 u 230 256 377 23.140 -2.786 0.806
*dns0.rmplc.co.u 195.66.241.2 2 u 162 256 377 24.208 -2.528 0.843
+ntp.oceanmediag 192.93.2.20 2 u 60 256 377 22.431 -2.508 0.433 -
-
Yeah, that looks pretty clear, and the assoc output confirms that your GPS is being seen as a false ticker. The time is significantly off from the other sources (and the jitter twice as high), which is why it's being rejected. I'm pretty confident that it's because the GPS doesn't have PPS support.
-
Maybe a bad exaMPLE QUOTED
THIS IS MORE TYPICAL
$ ntpq -p
remote refid st t when poll reach delay offset jitterxGPS_NMEA(0) .GPS. 0 l 15 16 377 0.000 -531.24 0.355
LOCAL(0) .LOCL. 12 l 74m 64 0 0.000 0.000 0.000
+ntp.demon.co.uk 195.66.241.10 2 u 42 256 377 23.525 0.407 18.033
-time.shf.uk.as4 82.219.4.30 3 u 91 128 377 31.379 0.189 9.375
+ntp1.exa-networ 33.117.170.50 2 u 128 128 377 29.922 -0.829 11.751
*ntp.oceanmediag 193.190.230.66 2 u 108 256 377 22.060 -0.943 11.376 -
I have a cheap USB to serial NEMA GPS, and it runs at 500ms off decent time.
See my original post and picture, could of saved your self the £.
-
The x still means that NTP sees it as a false ticker - again, the offset is quite far from everything else - about half a second if I remember my units correctly. Without PPS support I suspect you won't change the situation.
-
@Cry:
Without PPS support I suspect you won't change the situation.
Agree.
-
We have PPS_SYNC in the pfSense kernel, and you can get PPS over serial with a hardware serial port.
PPS needs GPIO not serial.
-
We have PPS_SYNC in the pfSense kernel, and you can get PPS over serial with a hardware serial port.
PPS needs GPIO not serial.
Nope.
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
http://gpsppssync.sourceforge.net/
http://lists.ntp.org/pipermail/questions/2007-December/016485.html
http://mail-index.netbsd.org/current-users/2012/08/10/msg020838.html
(and many many other references to it working perfectly fine over serial…)
