Using pfSense's time server
-
Daytime doesn't use ntp, it uses an older, simpler protocol. I think…
What should I use instead?
ntpdate -q
The FreeBSD version ntpdate works fine, but when I run an OS/2 version I get
C:\usr\bin>ntpdate.exe -q -d 192.168.1.1
9 Jun 20:41:21 C:\usr\bin\ntpdate.exe[13633]: ntpd 4.2.0-os2-emx build 2
Looking for host 192.168.1.1 and service ntp
host found : pfSense.localdomain
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
transmit(192.168.1.1)
transmit(192.168.1.1)
192.168.1.1: Server dropped: strata too high
server 192.168.1.1, port 123
stratum 16, precision -6, leap 11, trust 000
refid [192.168.1.1], delay 0.02557, dispersion 24.06950
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000
originate timestamp: db0444e1.d1eb851e Thu, Jun 9 2016 20:41:21.820
transmit timestamp: db0444e2.deb851eb Thu, Jun 9 2016 20:41:22.870
filter delay: 0.02557 0.04124 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.139033 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.02557, dispersion 24.06950
offset 0.1390339 Jun 20:41:23 C:\usr\bin\ntpdate.exe[13633]: no server suitable for synchronization found
Can't say that any of that means anything to me….
Incidentally looking at the FreeBSD man page
https://www.freebsd.org/cgi/man.cgi?query=ntpdate&sektion=8
it says
After a
suitable period of mourning, the ntpdate utility is to be retired from
this distribution. -
That is saying your ntp server is not well, stratum 16 is about equal in accuracy to a sundial! :-)
192.168.1.1: Server dropped: strata too high server 192.168.1.1, port 123 stratum 16, precision -6, leap 11, trust 000ntp docs here:
http://www.ntp.org/documentation.html
-
For comparison I just tried the same command from a FreeBSD system
root@Desktop:~ # ntpdate -q -d 192.168.1.1
10 Jun 10:21:56 ntpdate[5544]: ntpdate 4.2.8p6-a (1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
server 192.168.1.1, port 123
stratum 3, precision -19, leap 00, trust 000
refid [192.168.1.1], delay 0.02594, dispersion 0.00002
transmitted 4, in filter 4
reference time: db0503de.fb41da29 Fri, Jun 10 2016 10:16:14.981
originate timestamp: db05053a.fd647e67 Fri, Jun 10 2016 10:22:02.989
transmit timestamp: db05053a.ee249963 Fri, Jun 10 2016 10:22:02.930
filter delay: 0.02600 0.02597 0.02594 0.02599
0.00000 0.00000 0.00000 0.00000
filter offset: 0.059365 0.059361 0.059325 0.059352
0.000000 0.000000 0.000000 0.000000
delay 0.02594, dispersion 0.00002
offset 0.05932510 Jun 10:22:02 ntpdate[5544]: adjust time server 192.168.1.1 offset 0.059325 sec
I guess this shows a problem with the program I'm usingon OS/2.
-
ntpd 4.2.0-
That is a OLD version of ntp.. That is prob why your having problems.. And works from the system using 4.2.8p6
4.2.0 is from 2003 for gosh sake..
-
I would have to look at what was going on yesterday afternoon evening on why it got a little haywired - but even then your talking 20 microseconds off, not miliseconds. Normally it is within 5micro seconds. Which for the < than $100 it cost to put together. I pretty sure that is pretty freaking good ;) Way better then your going to get syncing off the internet.
My information could be old, but it seems the issue in the reviews was not so much how accurate the PI was able to stay with GPS, but other computer's ability to sync with the PI was hindered by the USB Ethernet making for "poor" quality by some definition of poor.
Active Peer 208.100.4.52 216.86.146.46 2 u 14 256 377 11.469 0.457 0.332
Candidate 67.202.100.50 216.86.146.46 2 u 174 256 377 11.859 0.666 0.166
Outlier 216.239.36.15 92.118.64.39 2 u 198 256 377 35.324 -0.364 0.334
Outlier 216.152.240.220 164.67.62.194 2 u 165 256 377 63.997 0.363 0.173You know it's good when 0.3ms offset is considered an "Outlier".
-
My pi serves up to pool, hundreds of connections all the time…
ntpq> monstats enabled: 0x1 addresses: 3097 peak addresses: 3097 maximum addresses: 14563 reclaim above count: 600 reclaim older than: 64 kilobytes: 218 maximum kilobytes: 1024 ntpq>ntpq> mrulist
Ctrl-C will stop MRU retrieval and display partial results.
^Cmrulist retrieval interrupted by operator.
Displaying partial client list.
Retrieved 1654 unique MRU entries and 0 updates.So pretty sure it can handle serving up ntp to your network just fine…
Here is my workstation that syncs with my pi, and I have the poll really short
> ntpq ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== *pi3-ntp.local.l .PPS. 1 u 12 32 377 0.266 -0.015 0.007 ntpq> -
Those are much better stats. Better drivers and hardware I bet. Thank you sir, I now have a new project to plan for.
-
I'm using a very old, non-turbo Pi v1, so old it had to be modified to allow the GPS HAT to mount on it. No tweaks to the basic Raspberrian OS except I don't start the X server on it since it isn't needed with SSH access.
The timekeeping on the Pi is pretty good as yhis ntpq from a ssh to the pi shows:
pi@pi-v1 ~ $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS0. 0 l 8 8 377 0.000 0.002 0.004 pi@pi-v1 ~ $That there is some issue on the Pi, as can be seen here compared to the pfSense system, the delay and jitter on the Piare higher, which I attribute that to the weak Ethernet.
t3400-n:/home/stan # ntpq -p server.home remote refid st t when poll reach delay offset jitter ============================================================================== *pi-v1.home .GPS0. 1 u 361 1024 377 0.549 0.274 0.033 +pfSense.home 172.16.0.4 2 u 442 1024 377 0.206 0.020 0.055 server.home .INIT. 16 u - 1024 0 0.000 0.000 0.000 +ntp.cox.net .GPS. 1 u 956 1024 377 51.861 1.931 0.297 t3400-n:/home/stan # 1 u 956 1024 377 51.861 1.931 0.297 t3400-n:/home/stan #If the attachments work here the first is a full ntp display, it is pretty much swamped by the high disp plot. The second is the same plot with the disp line suppressed.
Still for under $100 it is going to be hard to get a more convenient or accurate local time server. I find it quite nice to have my time stable even when the WAN is down due to ISP or equipment problems. Pi, GPS HAT, power brick and remote antenna, throw in a case if you feel fancy. You can also find the old v1 Pi boards dirt cheap as folks move to the v2 or v3 ones.
-
Makes me want to dig out my Pi …. What OS are you running on it? Last time I tried I couldn't get FreeBSD installed on it.
I don't suppose pfSense would work on it :)....
-
Nope, pfSense won't run but using the basic Pi OS and following the help in the forums I have mine running. It works well enough that I don't pay any attention to it for months on end.
Basic forum topic: https://forums.adafruit.com/viewtopic.php?f=50&t=70133
I'd start reading it about here to miss the initial confusion: https://forums.adafruit.com/viewtopic.php?f=50&t=70133&start=60#p359668
I got involved a bit later: https://forums.adafruit.com/viewtopic.php?f=50&t=70133&start=90#p360387
A bit on the network delay in the Pi: https://forums.adafruit.com/viewtopic.php?f=50&t=70133&start=150#p389708
If you search the Adafruit forums on GPS you'll hit a few more topics that apply to newer hardware and later OS releases.
-
If you want quick easy to follow guide with info on what to order, and getting a ntp stratum 1 on a pi..
http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html
Quick start NTP on the Raspberry Pi -
I applied the tweaks mentioned here to my Pi and it has really improved the stability of the time system on my pfSense box. I will be trying a newer version of the Pi than my very old v1 to see if that improves the USB - Ethernet delay.
The left side scale (+1 to -1 ms) is showing all the items except the Disp. The Disp is on the left side (+5 to +40 ms) scale. The disp is still high enough that if it is shown on the same scale it swamps the other data.
