• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

NTP time sync issue

Scheduled Pinned Locked Moved General pfSense Questions
30 Posts 8 Posters 9.5k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P
    pfcode
    last edited by Dec 28, 2015, 2:54 AM

    Hi,

    My Win7 laptop's time server was set to 192.168.1.1, and updated/Synced with pfSense NTP successfully. However, from pfSense Dashboard->NTP Status, the Server time is always 3 seconds slower than my Laptop time, say: laptop time was 9:48:00pm, but on pfSense Dashboard -> NTP Status-> Server time: was 9:47:57pm. Why is it not synced properly? How could that be happened?

    William
    NTP.PNG
    NTP.PNG_thumb

    Release: pfSense 2.4.3(amd64)
    M/B: Supermicro A1SRi-2558F
    HDD: Intel X25-M 160G
    RAM: 2x8Gb Kingston ECC ValueRAM
    AP: Netgear R7000 (XWRT), Unifi AC Pro

    1 Reply Last reply Reply Quote 0
    • J
      johnpoz LAYER 8 Global Moderator
      last edited by Dec 28, 2015, 2:59 AM

      I find that unlikely and most likely a delay in where your reading the time… Why don't you just check with w32tm or ntp if that is what your running on your laptop..

      This will tell you exactly how far off your laptop is off from its ntp server..

      An intelligent man is sometimes forced to be drunk to spend time with his fools
      If you get confused: Listen to the Music Play
      Please don't Chat/PM me for help, unless mod related
      SG-4860 24.11 | Lab VMs 2.7.2, 24.11

      1 Reply Last reply Reply Quote 0
      • P
        pfcode
        last edited by Dec 28, 2015, 3:19 AM

        @johnpoz:

        I find that unlikely and most likely a delay in where your reading the time… Why don't you just check with w32tm or ntp if that is what your running on your laptop..

        This will tell you exactly how far off your laptop is off from its ntp server..

        No delay in reading, because the Window time was displayed at the right bottom corner of Window task bar, while the pfSense ntp status: server time was display at the middle of the browser, I can see the 2 times at the same time: 3 seconds difference.

        William

        Release: pfSense 2.4.3(amd64)
        M/B: Supermicro A1SRi-2558F
        HDD: Intel X25-M 160G
        RAM: 2x8Gb Kingston ECC ValueRAM
        AP: Netgear R7000 (XWRT), Unifi AC Pro

        1 Reply Last reply Reply Quote 0
        • J
          johnpoz LAYER 8 Global Moderator
          last edited by Dec 28, 2015, 3:46 AM

          dude.. Really…

          How are you syncing time??  just windows, or are you running ntp actually...

          ntptime.png
          ntptime.png_thumb
          w32tmcheck.png
          w32tmcheck.png_thumb

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.7.2, 24.11

          1 Reply Last reply Reply Quote 0
          • P
            pfcode
            last edited by Dec 28, 2015, 5:04 AM Dec 28, 2015, 4:16 AM

            @johnpoz:

            dude.. Really…

            How are you syncing time??  just windows, or are you running ntp actually...

            I'm syncing Windows time with pfSense, I set the Windows internet time server to 192.168.1.1, the pfSense LAN interface, My pfSense box run as a NTP server. from what I saw is that Windows time is faster than pfSense NTP server time. not sure why, anyway, here is:

            ntptrack.PNG
            ntptrack.PNG_thumb

            Release: pfSense 2.4.3(amd64)
            M/B: Supermicro A1SRi-2558F
            HDD: Intel X25-M 160G
            RAM: 2x8Gb Kingston ECC ValueRAM
            AP: Netgear R7000 (XWRT), Unifi AC Pro

            1 Reply Last reply Reply Quote 0
            • P
              pfcode
              last edited by Dec 28, 2015, 4:59 AM Dec 28, 2015, 4:33 AM

              Hmmm, All of a sudden, Windows time is now synced with pfSense time, very odd.

              EDIT:  thats because my wife stopped watching online movies.

              Release: pfSense 2.4.3(amd64)
              M/B: Supermicro A1SRi-2558F
              HDD: Intel X25-M 160G
              RAM: 2x8Gb Kingston ECC ValueRAM
              AP: Netgear R7000 (XWRT), Unifi AC Pro

              1 Reply Last reply Reply Quote 0
              • P
                pfcode
                last edited by Dec 28, 2015, 5:44 AM Dec 28, 2015, 4:52 AM

                Here is what I found, which can be reproducable. I have Snort and pfBlockerNG installed on the pfSense box btw. Whenever there is heavy internet activities involved, e.g. my wife was watching online movies, the pfSense NTP server time was displayed in couple of seconds slower than all the connected devices whose times were synced with it, which made me thinking that time were not synced for each other, until all the heavy internet activities were stopped.

                This is not good, I thought the system is multi-threaded, every service should be working properly. A couple of seconds delay is HUGE.

                Is it just the NTP widget issue or the entire NTP service issue?

                Release: pfSense 2.4.3(amd64)
                M/B: Supermicro A1SRi-2558F
                HDD: Intel X25-M 160G
                RAM: 2x8Gb Kingston ECC ValueRAM
                AP: Netgear R7000 (XWRT), Unifi AC Pro

                1 Reply Last reply Reply Quote 0
                • R
                  RonpfS
                  last edited by Dec 28, 2015, 5:24 AM

                  Same things happens here, I have Win 7 x64 Internet time set to pfsense 2.2.6

                  
                  C:\>w32tm /stripchart /computer:172.24.xx.xxx
                  
                   Suivi de 172.24.xx.xxx[172.24.xx.xxx:123].
                  L'heure actuelle est 2015-12-28 00:16:50.
                  00:16:50 d:+00.0008824s o:+01.9393273s  [                           |    *                ]
                  00:16:52 d:+00.0008465s o:+01.9389158s  [                           |    *                ]
                  00:16:54 d:-00.0000914s o:+01.9393138s  [                           |    *                ]
                  00:16:56 d:-00.0000847s o:+01.9394665s  [                           |    *                ]
                  00:16:58 d:-00.0000822s o:+01.9392438s  [                           |    *                ]
                  00:17:00 d:-00.0000751s o:+01.9392295s  [                           |    *                ]
                  00:17:02 d:-00.0000769s o:+01.9392350s  [                           |    *                ]
                  00:17:04 d:-00.0001045s o:+01.9392911s  [                           |    *                ]
                  00:17:06 d:-00.0001090s o:+01.9392888s  [                           |    *                ]
                  00:17:08 d:-00.0001038s o:+01.9392729s  [                           |    *                ]
                  00:17:10 d:-00.0001074s o:+01.9392196s  [                           |    *                ]
                  00:17:12 d:+00.0000000s o:+00.0000000s  [                           *                ]
                  00:17:14 erreur: 0x800705B4
                  00:17:17 erreur: 0x800705B4
                  00:17:20 erreur: 0x800705B4
                  00:17:23 d:+00.0010001s o:-00.0005000s  [                           *                ]
                  00:17:25 erreur: 0x800705B4
                  00:17:28 erreur: 0x800705B4
                  00:17:31 erreur: 0x800705B4
                  00:17:34 d:+00.0030002s o:-00.0015001s  [                           *                ]
                  00:17:36 erreur: 0x800705B4
                  
                  

                  2.4.5-RELEASE-p1 (amd64)
                  Intel Core2 Quad CPU Q8400 @ 2.66GHz 8GB
                  Backup 0.5_5, Bandwidthd 0.7.4_4, Cron 0.3.7_5, pfBlockerNG-devel 3.0.0_16, Status_Traffic_Totals 2.3.1_1, System_Patches 1.2_5

                  D 1 Reply Last reply Apr 7, 2020, 5:33 PM Reply Quote 0
                  • J
                    johnpoz LAYER 8 Global Moderator
                    last edited by Dec 28, 2015, 12:37 PM

                    For starters windows might not actually be trying to "sync" out of the box, it might just be setting the time every so often..  I you want it to "sync" up its clock with an ntp server then you really need to actually make sure that its doing that or install ntp.

                    As to clock being off when machine is under heavy load?  Is pfsense a VM?  Or running on hardware?

                    You do understand ntp isn't actually the clock on the system, it just adjusts the clock to run faster or slower to keep accurate time based on another clock it checks time against..  Ntp checks the time against another clock, and tells the system clock hey your running a bit fast, hey your running a bit slow lets make some tiny adjustments so you keep the same time as this really accurate clock I am checking against.

                    The ntp service checks this time every so often, when it first starts it will check more often then after its been running a while.. Notice the 1024 in my output that is how often its asking the time..

                    The stripchart you were running isn't any sort of sync just checking hey what is the time on that computer based on my time and showing you the offset and delay..  That you were getting errors is a bad sign for sure…  This other guy is just show ing th is clock is off by 1.9 seconds..  Your saying when you get pfsense get busy its time is off?  Maybe -- again ntp is not the actual CLOCK of the system..

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                    1 Reply Last reply Reply Quote 0
                    • M
                      mer
                      last edited by Dec 28, 2015, 12:53 PM

                      Are you (the folks having issues) comparing the windows time to the "time" in the pfSense gui or are you actually doing ntp commands on the pfSense box (console or ssh)?  Things like ntpq -pn, ntpstat, etc?  It's highly likely that a GUI processs may need to go and poll on a periodic basis so there could be a discrepancy there (a heavy load may slow down updates to the GUI).  Then there is "how does Windows actually update/set it's time"?  It may not be as nice as NTP, so it could be bigger jumps less often.

                      1 Reply Last reply Reply Quote 0
                      • H
                        Harvy66
                        last edited by Dec 28, 2015, 1:06 PM

                        By default, Windows only syncs once a week with the configured timeserver. That's a lot of time for drift and skew to make changes. When you said there was a 3 second offset, at that time, when was the last time your client was synced?

                        1 Reply Last reply Reply Quote 0
                        • P
                          pfcode
                          last edited by Dec 28, 2015, 4:23 PM Dec 28, 2015, 4:02 PM

                          @mer:

                          Are you (the folks having issues) comparing the windows time to the "time" in the pfSense gui or are you actually doing ntp commands on the pfSense box (console or ssh)?

                          I am comparing the windows time to the "time" on the pfSense gui, which is Dashboard->NTP Status->Server time.

                          As to clock being off when machine is under heavy load?  Is pfsense a VM?  Or running on hardware?

                          Pfsense, not a VM,  it was streaming online movies from outside world.

                          @Harvy66:

                          When you said there was a 3 second offset, at that time, when was the last time your client was synced?

                          I synced/updated the Windows time just a minute before, the time was synced successfully, both times were the same, and kept the same for a period of times. But as long as there is any heavy internet activities, then pfSense clock (Server time) on webgui suddenly were off, slower than the clients' times, made it looks like both were no longer synced, until no heavy loads, it (pfSense clock) then recovered by its own.

                          EDIT: Just minutes ago, I re-opened the NTP status screen at pfSense Dashboard, the pfSense clock is now 2 seconds faster than my Window clients without any heavy loads, so I'm really confused to which time is accurate.

                          Release: pfSense 2.4.3(amd64)
                          M/B: Supermicro A1SRi-2558F
                          HDD: Intel X25-M 160G
                          RAM: 2x8Gb Kingston ECC ValueRAM
                          AP: Netgear R7000 (XWRT), Unifi AC Pro

                          1 Reply Last reply Reply Quote 0
                          • M
                            mer
                            last edited by Dec 28, 2015, 5:44 PM

                            from the console or ssh into the pfSense box get the output of the command "ntpq -pn"  (I think there is a way to actually enter commands from the WebGui, I just don't have it in front of me right now).

                            That will give information on the state of NTP sync on the pfSense box:  what peers are playing, offsets, jitter, etc.  There may be a command called "ntpstat" that gives a quick summary of synchronized, to what server and how close the time is to that server.

                            If the pfSense NTP is synchronized to a server and the Windows box is showing a different time I'd be inclined to believe the pfSense box as correct, but only what you see from the ntpq/ntpstat commands, not the GUI (to eliminate any update delays of the GUI)

                            1 Reply Last reply Reply Quote 0
                            • P
                              pfcode
                              last edited by Dec 28, 2015, 6:29 PM

                              Using putty:

                              ntp.PNG
                              ntp.PNG_thumb
                              ntpstatus.PNG
                              ntpstatus.PNG_thumb

                              Release: pfSense 2.4.3(amd64)
                              M/B: Supermicro A1SRi-2558F
                              HDD: Intel X25-M 160G
                              RAM: 2x8Gb Kingston ECC ValueRAM
                              AP: Netgear R7000 (XWRT), Unifi AC Pro

                              1 Reply Last reply Reply Quote 0
                              • D
                                David_W
                                last edited by Dec 28, 2015, 6:50 PM

                                @mer:

                                from the console or ssh into the pfSense box get the output of the command "ntpq -pn"  (I think there is a way to actually enter commands from the WebGui, I just don't have it in front of me right now).

                                I'd use:
                                ntpq -c 'rl' -wp

                                If that causes an error, leave out the w. It's best to paste the results as text using the 'Code' feature (the # above the editor). The values of sys_jitter, clk_jitter and clk_wander are of particular interest. It would also be useful to know where you are (roughly) and what WAN connection(s) you have.

                                Any time displayed via the dashboard plugin is subject to so many possible delays as to make it worthless for debugging purposes.

                                Windows' time synchronisation is designed for low load on the time servers, not a good quality lock to network time. Windows' internal timing is subject to some granularity issues (and therefore has a quality ceiling) prior to Windows 8.

                                One important issue is that the timing components in the machines we use are poorly temperature compensated. If a pfSense machine has fluctuating load, its internal temperature can fluctuate all over the place. Unless you have a pulse-per-second source feeding into the machine (such as a GPS receiver) or are synchronising every 16 seconds to a local Stratum 1 server (do not do this with a Stratum 1 on the Internet - it's extremely antisocial), it will take a long time for ntp's PLL to settle down after any temperature related disturbances.

                                Better quality timing components are available, but as most users don't care about the quality of their timing, there is no incentive for the manufacturers to pay the significant additional costs when building mass market hardware. The manufacturers care about every penny on the bill of materials, so are not interested in paying substantially more for temperature compensated or ovenised oscillators.

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pfcode
                                  last edited by Dec 28, 2015, 9:37 PM Dec 28, 2015, 7:17 PM

                                  @David_W:

                                  @mer:

                                  from the console or ssh into the pfSense box get the output of the command "ntpq -pn"  (I think there is a way to actually enter commands from the WebGui, I just don't have it in front of me right now).

                                  I'd use:
                                  ntpq -c 'rl' -wp

                                  If that causes an error, leave out the w. It's best to paste the results as text using the 'Code' feature (the # above the editor). The values of sys_jitter, clk_jitter and clk_wander are of particular interest. It would also be useful to know where you are (roughly) and what WAN connection(s) you have.

                                  Any time displayed via the dashboard plugin is subject to so many possible delays as to make it worthless for debugging purposes.

                                  Windows' time synchronisation is designed for low load on the time servers, not a good quality lock to network time. Windows' internal timing is subject to some granularity issues (and therefore has a quality ceiling) prior to Windows 8.

                                  One important issue is that the timing components in the machines we use are poorly temperature compensated. If a pfSense machine has fluctuating load, its internal temperature can fluctuate all over the place. Unless you have a pulse-per-second source feeding into the machine (such as a GPS receiver) or are synchronising every 16 seconds to a local Stratum 1 server (do not do this with a Stratum 1 on the Internet - it's extremely antisocial), it will take a long time for ntp's PLL to settle down after any temperature related disturbances.

                                  Better quality timing components are available, but as most users don't care about the quality of their timing, there is no incentive for the manufacturers to pay the significant additional costs when building mass market hardware. The manufacturers care about every penny on the bill of materials, so are not interested in paying substantially more for temperature compensated or ovenised oscillators.

                                  ntpq -c 'rl' -wp:

                                  
                                  associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
                                  version="ntpd 4.2.8p4@1.3265-o Mon Oct 26 14:28:17 UTC 2015 (1)",
                                  processor="amd64", system="FreeBSD/10.1-RELEASE-p25", leap=00, stratum=3,
                                  precision=-22, rootdelay=65.209, rootdisp=77.293, refid=159.203.8.72,
                                  reftime=da2c0742.c3cc6660  Mon, Dec 28 2015 14:08:50.764,
                                  clock=da2c08e2.c4fed519  Mon, Dec 28 2015 14:15:46.769, peer=59118, tc=9,
                                  mintc=3, offset=-1.970223, frequency=21.851, sys_jitter=2.309164,
                                  clk_jitter=2.943, clk_wander=0.201
                                       remote           refid      st t when poll reach   delay   offset  jitter
                                  ==============================================================================
                                  *159.203.8.72    192.5.41.209     2 u  416  512  377   25.338   -1.970   2.309
                                  +zero.gotroot.ca 30.114.5.31      2 u  272  512  377   61.560   -9.818   2.231
                                  -ntp.tranzeo.com 206.108.0.132    2 u  342  512  377   20.040   -9.387   2.651
                                  +penguin.hopcount.ca
                                                   200.98.196.212   2 u  385  512  377   15.905   -7.855   3.722
                                  
                                  

                                  Living in Toronto, Canada, and using Rogers internet cable at 250/20 mbps.

                                  Release: pfSense 2.4.3(amd64)
                                  M/B: Supermicro A1SRi-2558F
                                  HDD: Intel X25-M 160G
                                  RAM: 2x8Gb Kingston ECC ValueRAM
                                  AP: Netgear R7000 (XWRT), Unifi AC Pro

                                  1 Reply Last reply Reply Quote 0
                                  • D
                                    David_W
                                    last edited by Dec 29, 2015, 12:23 AM Dec 28, 2015, 7:50 PM

                                    It looks as if you are using relatively local NTP servers to your physical location, which is good. You are using a cable modem, which can lead to high jitter, but c. 2.5ms system jitter isn't the end of the world.

                                    Precision -22 suggests you might be using the on-processor TSC as your timing source.

                                    Post the results of:
                                    sysctl kern.timecounter.choice kern.timecounter.hardware
                                    which will show the timecounter choices and weights, also the timecounter your system is currently using.

                                    My experience of running NTP servers on bare metal FreeBSD installations is that the HPET is often a more stable timing source. If you want to give this a go, add a line to /boot/loader.conf.local that reads:
                                    kern.timecounter.tc.HPET.quality=5000

                                    You'll need to create /boot/loader.conf.local if it doesn't already exist. Once you've made the change, delete the ntpd.drift file (its contents are invalidated by the change of timing source) using:
                                    pkill ntpd ; rm /var/db/ntpd.drift
                                    then reboot. After the system has been running for at least 12 hours, re-run the command I gave in the previous post. Hopefully clk_jitter is significantly lower than the 2.9ms in your earlier output.

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pfcode
                                      last edited by Dec 28, 2015, 9:31 PM

                                      @David_W:

                                      Post the results of:sysctl kern.timecounter.choice kern.timecounter.hardware

                                      
                                      sysctl kern.timecounter.choice kern.timecounter.hardware
                                      kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) i8254(0) HPET(950) dummy(-1000000)
                                      kern.timecounter.hardware: TSC-low
                                      
                                      

                                      Release: pfSense 2.4.3(amd64)
                                      M/B: Supermicro A1SRi-2558F
                                      HDD: Intel X25-M 160G
                                      RAM: 2x8Gb Kingston ECC ValueRAM
                                      AP: Netgear R7000 (XWRT), Unifi AC Pro

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        pfcode
                                        last edited by Dec 29, 2015, 12:13 AM

                                        @David_W:

                                        delete the ntp.drift file

                                        you meant: ntpd.drift ?  which I deleted.

                                        Release: pfSense 2.4.3(amd64)
                                        M/B: Supermicro A1SRi-2558F
                                        HDD: Intel X25-M 160G
                                        RAM: 2x8Gb Kingston ECC ValueRAM
                                        AP: Netgear R7000 (XWRT), Unifi AC Pro

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          David_W
                                          last edited by Dec 29, 2015, 12:36 AM

                                          @pfcode:

                                          @David_W:

                                          delete the ntp.drift file

                                          you meant: ntpd.drift ?  which I deleted.

                                          That is the file I meant. I've edited the earlier post accordingly.

                                          As I thought, your system had chosen TSC (well TSC-low, though the difference is not material here) as its timecounter. If you repeat that command having made the change I suggested to /boot/loader.conf.local, you should find the quality figure after HPET is now 5000 and that kern.timecounter.hardware is now HPET. It will be interesting to see whether that proves to have lower jitter (clk_jitter) and at least as good short-term stability (clk_wander) as TSC.

                                          It may take 24 hours for things to settle down as ntpd had no drift file value to start from.

                                          It is worth turning on pfSense's ntp RRD graphs in Services -> NTP, though I would strongly recommend you apply the patch in https://redmine.pfsense.org/issues/4423 first.

                                          1 Reply Last reply Reply Quote 0
                                          20 out of 30
                                          • First post
                                            20/30
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                            This community forum collects and processes your personal information.
                                            consent.not_received