Using pfSense's time server



  • I have enabled NTP within pfSense with 5 Time Servers but I can't get any of the clients on the LAN to update to the correct time.

    If I run 'daytime 192.168.1.1' I get no response. If I run 'daytime time.nist.gov' it works.

    What am I doing wrong?



  • Do you have the LAN interface selected?




  • @Balanga:

    I have enabled NTP within pfSense with 5 Time Servers but I can't get any of the clients on the LAN to update to the correct time.

    If I run 'daytime 192.168.1.1' I get no response. If I run 'daytime time.nist.gov' it works.

    What am I doing wrong?

    Daytime doesn't use ntp, it uses an older, simpler protocol. I think…



  • What do you see if you use ntpq to check your ntp setup?

    Checking my pf sense box at 172.16.0.1 from one of my clients gets me the responses below.

    p490:/home/stan # ntpq -p 172.16.0.1
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    +server.home     172.16.0.4       2 u   97  512  377    0.177   -1.046   0.130
    *pi-v1.home      .GPS0.           1 u  119  512  377    0.578   -0.353   0.155
    +ntp.cox.net     .GPS.            1 u   91  512  377   51.263    1.371   0.995
    
    p490:/home/stan # ntpq -pn 172.16.0.1
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    +172.16.0.2      172.16.0.4       2 u  110  512  377    0.177   -1.046   0.130
    *172.16.0.4      .GPS0.           1 u  132  512  377    0.578   -0.353   0.155
    +68.0.14.76      .GPS.            1 u  104  512  377   51.263    1.371   0.995
    

    I'm using a Raspberry Pi GPS clock at 172.16.0.4 for my preferred server, peering with a local server at 172.16.0.2 backed up with my ISP's ntp server at 68.0.14.76 in case the Pi has issues.



  • @Harvy66:

    Do you have the LAN interface selected?

    Yes, I have LAN set on.  Just wondered what ADMIN signified…

    What should I run on the client to get the time synchronised?



  • @GomezAddams:

    Daytime doesn't use ntp, it uses an older, simpler protocol. I think…

    What should I use instead?



  • @stan-qaz:

    What do you see if you use ntpq to check your ntp setup?

    Checking my pf sense box at 172.16.0.1 from one of my clients gets me the responses below.

    p490:/home/stan # ntpq -p 172.16.0.1
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    +server.home     172.16.0.4       2 u   97  512  377    0.177   -1.046   0.130
    *pi-v1.home      .GPS0.           1 u  119  512  377    0.578   -0.353   0.155
    +ntp.cox.net     .GPS.            1 u   91  512  377   51.263    1.371   0.995
    
    p490:/home/stan # ntpq -pn 172.16.0.1
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    +172.16.0.2      172.16.0.4       2 u  110  512  377    0.177   -1.046   0.130
    *172.16.0.4      .GPS0.           1 u  132  512  377    0.578   -0.353   0.155
    +68.0.14.76      .GPS.            1 u  104  512  377   51.263    1.371   0.995
    

    I'm using a Raspberry Pi GPS clock at 172.16.0.4 for my preferred server, peering with a local server at 172.16.0.2 backed up with my ISP's ntp server at 68.0.14.76 in case the Pi has issues.

    What is a RPi GPS clock? And are you running FreeBSD on the Pi?

    NTPQ worked ok.



  • I'm using this board to get a GPS based clock on the Raspberry Pi, added the external antenna to improve the signal through my roof.

    https://www.adafruit.com/products/2324

    If ntpq worked then your ntp server is set up, running and accessible so all you need is a ntp client for your lan machines. What works depends on what os you are running.



  • I looked into a Raspberry Pi GPS, but based on what I could find, the jitter and offset was almost always worse than what I get to public Stratum 1 NTP servers.



  • Were you looking at one of the USB based GPS setups?

    The Adafruit version (two available, dumb board or hat board) provides direct serial and PPS support and as you can see from my ntpq numbers it is beating my ISP's ntp system. I found that when using pool servers or specific public ones ntp usually picked the Pi as the peer (shown by the * on the ntpq line) so I pulled them from my config files.

    Did you find an ntp client for your machines and is it working now?


  • Rebel Alliance Global Moderator

    jitter and offset to what?  The time from gps?  All you really need that for is to get the pps within 1 second.  The actual thing that is keeping the time accurate is the pps signal.  And there your going to be right on the money..

    
    current host set to pi3-ntp.local.lan
    ntpq> pe
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    oPPS(0)          .PPS.            0 l   10   16  377    0.000    0.004   0.003
    *SHM(0)          .GPSD.           1 l   10   16  377    0.000   -8.559   5.031
    
    

    To be honest you don't even need the time from the gps if you have internet connectivity you can just use a time from a stratum 1 on the net that is close to you.  Its the pps signal from the board that is what is useful.  The time from gps just gets you close if you have no access to any other ntp server.

    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 pfsense runs in vm, so its kind of useless as ntp server.  I just point it my pi ntp server.  As I do every other machine on the network.

    edit: I added all the graphs going back to monthly and yearly.  You can see the little pi keeps pretty good time.. if you look at the average offset with the 20 added to it your talking right on the money off by couple of microseconds..  I am very happy with the pi as a ntp server, and you can not beat the cost and a fun little project to get going..  That is if your into that sort of thing like any respecting uber geek would be ;)






  • @Balanga:

    @GomezAddams:

    Daytime doesn't use ntp, it uses an older, simpler protocol. I think…

    What should I use instead?

    ntpdate -q



  • @GomezAddams:

    @Balanga:

    @GomezAddams:

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

    9 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 000
    

    ntp 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.059325

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


  • Rebel Alliance Global Moderator

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



  • @johnpoz:

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

    You know it's good when 0.3ms offset is considered an "Outlier".


  • Rebel Alliance Global Moderator

    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.


  • Rebel Alliance Global Moderator

    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.