I’ve upgraded to the new RB5009 from my old HAP AC, and I’ve noticed a strange behavior of the system clock. Many times a day the clock is being adjusted a second or even two
> system ntp client print
enabled: yes
mode: unicast
servers: timeserver.iix.net.il
vrf: main
freq-drift: 442.319 PPM
status: synchronized
synced-server: timeserver.iix.net.il
synced-stratum: 2
system-offset: -251.803 ms
Here is the list of servers:
> system ntp client servers print
Flags: X - disabled; D - dynamic
0 address=timeserver.iix.net.il resolved-address=192.114.63.250 min-poll=6 max-poll=10 iburst=yes auth-key=none
I can’t imagine how a clock can be that off. It looks to me more like some competing time updates but I don’t know what alternative source of time could be there.
Any ideas?
So, after writing this yesterday, I’ve decided to disable the NTP client and see if the clock really drifts that much. With the PPM error advertised, I should have seen tens of seconds difference over the 12 hr period, and I’ve checked now that the clock is still perfectly aligned with my computer clock, within a 0.5 seconds error of perception.
So I’m starting to think that maybe I’ve accidentally imported the drift setting from my old router. I’ll reset my frequency drift and see if that changes the picture
If you restored binary backup from hAP ac to RB5009, then you imported quite a few potential problems … binary backups are not meant to transfer config between different device models (even if backup is restored on another device of same model it can cause some surprises). So the erroneous drift value might only be a beginning …
well, I did restore binary and then quickly realized it was not a good idea and restored back to the factory settings, then manually imported the relevant config via scripting.
After playing with this for a while I can see that resetting the frequency drift didn’t really help; after starting the ntp client again I have observed the frequency drift get back to ~500 PPM and the constant time update messages returned
20:35:18 system,info ntp settings changed by leo
20:35:27 system,info ntp change time Sep/12/2022 20:35:27 => Sep/12/2022 20:35:27
20:56:49 system,info ntp change time Sep/12/2022 20:56:49 => Sep/12/2022 20:56:49
20:56:49 ntp,warning WARNING: frequency out of range: -0.000541. MAX: 0.000500
21:15:03 system,info ntp change time Sep/12/2022 21:15:03 => Sep/12/2022 21:15:03
21:32:15 system,info ntp change time Sep/12/2022 21:32:14 => Sep/12/2022 21:32:15
21:53:41 system,info ntp change time Sep/12/2022 21:53:41 => Sep/12/2022 21:53:41
22:16:08 system,info ntp change time Sep/12/2022 22:16:08 => Sep/12/2022 22:16:08
22:37:32 system,info ntp change time Sep/12/2022 22:37:31 => Sep/12/2022 22:37:32
22:53:38 system,info ntp change time Sep/12/2022 22:53:38 => Sep/12/2022 22:53:38
23:18:13 system,info ntp change time Sep/12/2022 23:18:12 => Sep/12/2022 23:18:13
update-time (yes | no; Default: yes) If set to yes then router clock will be set to time, provided by cloud server IF there is no NTP or SNTP client enabled. If set to no, then IP/Cloud service will never update the device’s clock. If update-time is set to yes, Clock will be updated even when ddns-enabled is set to no.
so, technically, since I had the NTP client enabled, that setting should have been ignored. We’ll see about that soon.
First netinstall before jumping to conclusions, please.
I’m still not convinced all the rubbish from previous digital import was cleared with factory reset.
I started to notice this in the logs after upgrading from 6 to 7. I turned off /ip/cloud/update-time and it fixed it for me. I am using a local NTP server.
I’m seeing the same issue on a CHR instance in a KVM VM (on Proxmox VE). Cloud time sync is off, 4 ntp servers are configured, all work. The offset is weirdly high. Can it be caused by something like CPU frequency scaling?
I apologize for not responding earlier, somehow the notifications from the forum got lost.
As was suggested above, I have restored to factory settings and re-configured the router from scratch. It was painful, but I was able to salvage some blocks of config from the config exports lying around. It looks like my original attempt to restore from a binary backup has misconfigured the hardware or something like that. In any case, after the reset I stopped seeing this issue
Yes, it is a really nasty problem.
I think RouterOS should post a big warning when restoring a backup from a different device.
When same hardware → warning and pointing to some info page on how to reset MAC addresses etc
When different hardware model → plainly refuse to restore.
And then offer a service in the mikrotik account to convert a .backup file to a .rsc file that the user can use to recover their config manually.
