NTP / System Time Oddities

  • PFsense has been off by the current official time by 5 hours (dashboard time) and 7 minutes (time received by internal LAN clients from PFsense ntpd) since I set it up. About 5 months now. I've been manually updating the time on my internal devices every-time my wife tells me the time is wrong - she watches it more than I do.

    So, I had NTP setup with 4 time srv's 0.ca.pool.ntp.org and 1,2,3.
    After browsing PFsense forums and experimenting for a few hours this morning I am stumped.

    SO, I ensured the correct time zone was selected in general setup. I then selected another time zone, applied the changes, restart service then time changed. I then reversed those settings putting in my correct time zone, applied the changes and the time changed. 7 minutes late then restart ntpd. Nothing changed. Then restart PFsense - no change.

    So I thought I had read somewhere that using a specific country pool was faster and more accurate but it sometimes had problems. So I changed the ntp sync srv's to just 0.pool.ntp.org, 1,2,3 - so four pools.

    Then I repeated the above troubleshooting steps.
    Nothing changed. PFsense system time off by 5 hours, clients off by 7 minutes.

    BIOS battery could cause this I was told. So, I shutdown PFsense and entered the BIOS where I found the date time was set back to some time in 2010 - 10 years ago, which is odd since the system was built in 2011 - but whatever. I corrected that and restart PFsense.

    I then checked PFsense dashoard and it's still 5hours off. However, when I forced a manual sync on my Windows PC it sycn'd properly with PFsense and now is showing the correct time - this was 2 hours ago.

    My question is: Is there a known bug/issue with the Dashboard plugin presenting the wrong system time.

    I have entered the BIOS of the PFsense PC two more times, each separated by 1 hour and it still shows the correct time.

    I don't think the BIOS battery is dead, but the system IS 9 years old now.

    Where is the PFsense dashboard pulling the time from and how do I get it to show the correct time?

  • @1OF1000Quadrillion

    The 5 hour difference could be a time zone error. However, I have no idea what could cause a 7 minute error.

    So I thought I had read somewhere that using a specific country pool was faster and more accurate but it sometimes had problems.

    All NTP servers are supposed to be traceable to International Atomic Time and so should all have the exact same time. The only difference is how precise they are. The higher the stratum number, the less precise. Also, variations in transit time, from the server, will affect precision.

    A bad battery can cause the mom board clock to lose the time, but it's out of the picture once NTP syncs. However, at 9 years, it's probably dead.

    My dashboard clock shows the same time as another computer that gets it's time from pfSense. It also shows the same time as a clock I have that receives time from WWVB.

  • Hi,

    Thanks so much for your response.

    The seven minute issue has been resolved. All my internal LAN systems are now updating time accurately with PFsense.

    The 5hour time difference on the dashboard is not resolved and I have no clue where to go from here.

    It is currently 15:28 in Ottawa, Ontario Canada (EST Zone)

    this is what my dashboard says:
    Uptime 03 Hours 23 Minutes 32 Seconds
    Current date/time Tue Feb 25 10:28:07 EST 2020

    Any ideas from anyone? I mean this has GOT to be an issue with PFsense right. The time in my BIOS is correct as of 3hours 23 Minutes 32 Seconds ago.


  • @1OF1000Quadrillion

    What's your time zone set to? Mine's America/Toronto. What do computers on you network show? If they're correct, NTP is working properly and you likely have a configuration issue for the Dashboard display.

  • Hey. Yes mine is set to America/Toronto also. All my PC's are now displaying the correctly synced and correct date/times according to https://nrc.canada.ca/en/web-clock/ . I go here to get an accurate current time.

    The ONLY thing that is NOT working properly is the dashboard time display, which is off by 5hours.

    I just removed the system information plugin and then re-inserted it into the dashboard and it is still 5 hours off. I am not sure where to go from here, as I already said, as there seems to be no way I can re-configure the system information plugin.

    You know what - since the system is so old, your right, the BIOS battery may be pooched or flaky. I'll get another and install it and see if that resolves the issue. I will report the results back here.

  • I changed the BIOS battery, bought a new one from the source. I checked before I changed it, the BIOS time/date was still correct.

    After I changed the BIOS battery I went in reset defaults and set the current date/Time.

    Once back on the PFSense Dashboard page, on the system information plugin (is it referred to as a plugin? Or a script?WebApp?) section, the time is still off by five hours.

    It is currently Feb.25, 2020 8:32. Below is what I see on the dashboard:

    Uptime 00 Hour 06 Minutes 05 Seconds
    Current date/time Tue Feb 25 3:08:30 EST 2020

    I would love to resolve this but I am at my whits end. Is there a way to edit the config files manually and would that even help?

    Any other help you or anyone can give me would be awesome. I'd like to get it resolved. But, everything seems to working as I expected it to.

    Is there a way to manually set the time in PFsense? Or does it have some other mechanism. I guess what I am asking is, where does PFSense get the time from for the dashboard page?

  • Well. Now my windows systems are not sycning with the pfsense ntpd server. Status page says it's running. It's setup exactly the same as it was before I started all this troubleshooting. It can be reached. Windows returned an error saying that it couldn't use this time server because the difference was to great. Dashboard page shows pfsense system time is still 5hours behind. It is setup to the correct time zone America/Toronto EST. I am now using the original ntp.org servers which would allow me to sync from windows (0.ca.pool.ntp.org 1.ca.pool.ntp.org 2.ca.pool.ntp.org 3.ca.pool.ntp.org) I used "echo date('r');" in the php command and it returned Tue, 25 Feb 2020 06:15:47 -0500 I checked the BIOS 2 minutes ago it it was to correct time of 11:39PM. So approx. 5 hours behind.

  • I read in another post where someone had posted as a reply to a question similar to mine, "type date" into the Command. So, I did that. Then thought hey I wonder if I can manually set the time for PFSense using this command. I did that. It said: date: can't reach time daemon, time set locally Wed Feb 26 12:19:00 EST 2020. I checked Dashboard and it is now showing the correct time and my Windows PC's are once again syncing with the ntp service.

    So, in essence I forced a timesync, PFSense could not communicate with the configured time servers for whatever reason and it used the system time instead. Does that mean that PFSense will eventually go out of sync again?

    I edited the post to add this. I did a refresh on the dashboard page and the time was off again by 11 minutes. I am flabbergasted. It had the correct time, pulled from what I believe is the BIOS (locally set time) and it stayed that way for about 3 minutes. Now it's 11 minutes off. Brand new BIOS battery.

    Again I am stumped.

  • Generally Unix/Linux expects the hardware/BIOS clock to be UTC time, so if you're setting that to local time and telling pfSense to -5 hours that's likely the difference there. Clock drift is a separate issue. In rare cases I've seen even recently new PCs drift several minutes per day (which implies a hardware problem) and the "fix" there was to run the time sync every 30 minutes or so.
    The pfSense "book" recommends checking for BIOS updates as well to fix possible issues.

  • @teamits

    Linux allows the use of either local time or UTC. I normally use UTC, but use local time on dual boot Linux/Windows systems, as Windows supports only local time. My pfSense firewall/router is set to UTC.

  • Netgate Administrator

    Wrong system clock selected? Something that varies with cpu speed maybe?

    What does sysctl kern.timecounter show?

    Though you usually see time errors logged if that happens.


  • Hi Guys,

    Thanks for all the responses. Its an old Dell Inspiron 620 with an as up to date BIOS as it's ever gonna get:-)
    I reconfigured using just one pool from ntp.org (0.ca.pool.ntp.org).

    All the reading I've done is telling me to use multiple srv's or pools. But all I need is timeserver that is synced itself regularly and is fairly stable in uptime. So, I did the one pool configuration, restarted Pfsense and did a test synced with my windows srv and a couple desktops, laptops and all device's sync as expected. I know they did becasue I watched the time change it was out by 5 hours after all - lol. But, it's all working again. If it goes out again I'll notice in one of two ways. Wifey will ask why I'm late picking her up or I'll notice the time difference between the PC and the cell phone before I end up late to pick up wifey.

    Thanks everyone.

    PS - When I was in the BIOS I did not see an option to select or change time zone data - I saw date/time and that's it.

  • Netgate Administrator

    @1OF1000Quadrillion said in NTP / System Time Oddities:

    I'll notice the time difference between the PC and the cell phone before I end up late to pick up wifey.

    Sounds high risk! 😉

  • @1OF1000Quadrillion said in NTP / System Time Oddities:

    PS - When I was in the BIOS I did not see an option to select or change time zone data - I saw date/time and that's it.

    That's because the computer clock only knows whatever time you set it to. It has no other means of being set, so no need for time zones. In this respect, it's no different than any alarm or stove clock. On the other hand, NTP servers, which can be anywhere in the world, provide UTC, which a computer then offsets to local time. This is where the time zone comes in.

Log in to reply