Time always slow 2.4.5
-
If initially, the time is ok, and NTP is working : maybe it's slowing the system down because your are not syncing with the correct time zone, but one that's "in the past" for you.
Me, being in the 'Paris' time zone, If I selected the real GMT time, or 'London' as my time zone, I would loose 2 hours after some re syncing duration.
-
My location is Melbourne Australia and therefore I had set the NTP as:
0.au.pool.ntp.org ==> Australia/MelbourneUpdated the date via Shell Console to crrect time ==> date yyyymmddhhmm
Time updates correctly for the System but the ticks are just so much slower.
Ill see if I can screen record and will upload what I mean.
-
Here is a 1 minute grab showing what I have tried.
https://drive.google.com/drive/folders/1t7Eo1ykHaHKNLUUI75EqOCHVot1FqAMd?usp=sharing
-
Installed 2.4.4 and still no good. This issue occurs whether the system is connected to LAN/WAN or not it doesnt make any difference.
Tried changing the battery - argh, its been spot welded! Pry welds off battery and attach to fresh CR2032 - ok.. now I've just screwed the battery argh!!!
TBC
-
Ok, got a new battery - unplugged power cord several times and BIOS is definitely keeping time (ie. the same as before) and even let the NUC sit for 5 minutes with BIOS keeping time correctly.
Booted pfSense 2.4.4 and tested time - still persistently slow whereby the system time progressed 3 seconds for every 10 seconds in real life or approx.
-
I have found that the time resyncs correctly after a reboot and then immediately slows even after I let the time fall behind about 10 minutes!
What could cause the system time to fall behind after booting?
-
Hey funktified. This is a strange one indeed.
Are you able to boot the maschine from another linux Live-DVD/USB? Just to check behaviour under different OS and to rule out a hardware issue. Have you changed any bios setting? I have no clue though, which one could cause such symtoms :)
Cheers
-
I have reset the BIOS and have installed Windows 10 and sync the time with Windows and it syncs without issue. I disconnected the LAN to test and the time is definitely working as expected. When Windows was originally installed before Internet sync, it was slower by 2 minutes and even then the seconds moved inline with normal time.
Just to be sure, I downloaded Ubuntu 20.04 Desktop and run in Live mode from USB and sure enough, time ticks normally despite being 14 hours slow. Sync via Internet to correct time and disconnected and tested for 10 minutes - time is in sync to the second.
It seems to only be in pfSense / FreeBSD no matter which version.
I am also trying to source the latest BIOS for the unit.
-
Phew ... that's weird. The only thing that remains a potential root cause accordign to my feeling indeed is aforementioned timezone settings, maybe a variance in OS and bios and ... running out of ideas too.
-
This is really annoying...
I downloaded FreeBSD 12.1 and did a Live mode and time was similar to Ubuntu being 14 hours behind (probably because it was UTC time), but once I set the date and measured every 10 seconds it does the same as before and slows.
Confirming this is only on FreeBSD platform.
-
Which nuc are you using?
-
Its a custom Leader SN4-PLUS NUC sourced in Australia and I cannot identify what the board is. This is the second unit and I know with the first unit I did not have any time issues whatsoever. That is, exactly the same hardware bought within a few days of each other (so same batch I would assume).
Sorry, I cannot point you to a page as there is none that I can find, however the specs are:
- Intel Celeron N3350
- 4GB
- 64GB Storage
- Windows 10 Professional
- 4x Serial RS232
- 2x RJ45
- HDMI, Mini DP
-
Mh. I just watched the video. The only thing I saw was that you were not having a WAN connection. Does it also show these symptoms if you have a connection to internet?
-
It doesnt matter whether its connected or not - whether ports re0 or re1 is connected on any platform it will always run slow. I even run pfSense 2.4.5 for a week, I think date only moved 2 hours according to the system!
Correction: it will always run slow on any version of FreeBSD it appears - not any other platforms
-
If I understand you correctly, you got two devices. One of which works flawlessly and one of which shows this strange behaviour. Since NUCs are not too hard to deal with if it comes to swapping ssd, I'd swap the one installed in the bad one to the good one, boot it up and check the goods ones behaviour under the very same circumstances. If it still works OK I'd go back to the reseller and request a replacement.
-
Good idea, however have 2 issues with that unfortuantely:
- The other NUC is in production
- the eMMC I think is Soldered
EItherways, its not easy for me to remove the one in production and I dont have a spare M.2 as it has a spare slot. Maybe Ill try converting this M2 to a SATA and try to install on that.
Be back once installed
BTW @three thanks for your time in bouncing ideas
-
That's what I mean:
https://www.electronics-tutorials.ws/connectivity/real-time-clocks.html
https://en.wikipedia.org/wiki/Real-time_clockon the MOBO
-
-
@funktified I think you have a hardware issue with the RTC module, bad part. I'd return. That's what your battery feeds when the unit is off and between updates. But if you've already broken the old battery off, I think you're SOL.
-
The RTC includes a crystal oscillator (in fact, it is the clock of the synchronous base) that keeps the time, when there is no NTP update.........
Well, it could be faulty on the motherboard.like this:
https://handsontec.com/index.php/product/32-768khz-quartz-crystal/
There are many forms, you can’t fix it, so submit an RMA request.
