Gps receiver & ntp

[andrew0401]

Wondering about putting a cheap gps receiver onto the pfsense box so as to create a more stable time source ( based at a rural location and internet is slow and unreliabe) - any recommendations as to a good receiver to use?  Pfsense is running on in an ESXi box if it makes any difference.

Thanks

Andrew

[jimp]

There are a couple other threads around where people have given at least one model number of a device, but I'm not sure if very many people have tried it.

It works for me, though the device I have leaves a bit to be desired in accuracy.

In theory it should work with any device that outputs NMEA data over serial, preferably an actual serial connection and not USB-to-Serial.

[Cry Havok]

Ideally you want one that supports a PPS signal for an accurate time sync.

[jimp]

PPS over physical serial, yes.

PPS over USB isn't feasible, last I read. The timing of the bus isn't accurate enough to guarantee the signaling in the same way that a physical serial port can.

[Roots0]

I have a cheap USB to serial NEMA GPS, and it runs at 500ms off decent time.

[daffyq]

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

[Cry Havok]

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.

[biggsy]

Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):

http://www.adafruit.com/blog/2012/11/16/raspberry-flavored-time-a-ntp-server-on-your-pi-tethered-to-a-gps-unit-piday-raspberrypi-raspberry_pi/

[robi]

@biggsy:

Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):

http://www.adafruit.com/blog/2012/11/16/raspberry-flavored-time-a-ntp-server-on-your-pi-tethered-to-a-gps-unit-piday-raspberrypi-raspberry_pi/

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…

[jimp]

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.

[andrew0401]

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

[jimp]

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.

[andrew0401]

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

[Cry Havok]

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 ;)

[Roots0]

@andrew0401:

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.

[andrew0401]

$ ntpq -c pe
    remote          refid      st t when poll reach  delay  offset  jitter

xGPS_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

[andrew0401]

ntpq -c assoc

ind assID status  conf reach auth condition  last_event cnt

1  890  915b  yes  yes  none falsetick              5
  2  891  8043  yes  yes  none    reject  lost reach  4
  3  892  961a  yes  yes  none  sys.peer              1
  4  893  941a  yes  yes  none  candidat              1
  5  894  941a  yes  yes  none  candidat              1

[Cry Havok]

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.

[andrew0401]

Maybe a bad exaMPLE QUOTED

THIS IS MORE TYPICAL

$ ntpq -p
    remote          refid      st t when poll reach  delay  offset  jitter

xGPS_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

[Roots0]

@Roots0:

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 £.