I firmly believe that mikrotik has been having problems as an ntp server since 7.2rc. In the service project, I raised a work order more than once, but it seems that it has not been completely resolved so far.
According to my observation, if mikrotik cannot act as ntp client and get an upstream time correctly, it will not work as ntp server. Setting to use local time has no effect.
This is correct behaviour and is the same in all NTP server implementations. The notable exception is possibility to use localclock as reference (in most Linux implementations) and it’s up to NTP server admin to set stratum of localclock low (i.e. number high enough) so that it’s only used by its clients if absolutely none of higher-precision references are available.
The behaviour you see is even more important since ROS devices don’t have hardware clocks and are initialied to some (more or less poor) approximation to current time at boot time.
negative. I use GPS as the clock source and configure stratum=1, but the issue still exists.
I’m not sure if ROS NTP client can actually work with GPS receiver as source of (highly) precise time data. NMEA telegrams provide low precision as they are transmitted within one second, the problem is also slow serial line rate which doesn’t allow very precise delivery of time stamp. True GPS NTP boxes use NMEA telegrams to get time information and additionally PPS for precise time stamping (PPS is a special impulse, transmitted by GPS receiver, precisely on beginning of a second, every second; usually a special data port is there only for PPS). And even if ROS NTP client would be able to use GPS receiver as reference, until it’s locked, NTP server can not provide time to its clients. Setting stratum doesn’t help with this issue, stratum only makes your NTP server more or less attractive for clients to sync to it (versus other NTP servers they might be configured with).
You can decide not to believe (I have around 30 years of user experience with NTP protocol), but that’s not going to change the way NTP is supposed to work.
I agree. Using NMEA to provide “GPS time” is usually much worse than using NTP over internet.
I do have an NTP appliance (LeoNTP) at home and my MikroTik routers perfectly obtain time from it (and work as a server once they are locked).
There is no “issue”, it just works OK.
(there is a possible point for improvement: use random source port for server connections instead of 123, but that is related to ISP blocks as mentioned above)
It’s not about gps as ntp client (in fact it can’t). We can adjust mikrotik’s local clock according to GPS, regardless of time accuracy.
And use the local clock as the source of NTP server.
Unfortunately, the mikrotik ntp server which uses the local clock as the time source, will stop working after about 1 week except reboot system. here is the issue.
As I wrote: NMEA telegrams from GPS receiver are not very precise (± 0.5 seconds is pretty normal) but NTP is supposed to be precise. And using localclock on MT devices as any kind of reference clock for network is even worse idea.
You’ll have to rethink your setup and come up with another solution. If you insist on using local source for time sync of your network, you can use a low-cost device (e.g. RPi) running “normal” linux with NTP server which allows to use local clock as reference clock. You can then try to discipline local clock using NMEA telegrams if you will. Just a word of caution: large jumps in reference time compared to NTP client’s own idea of time makes it unhappy (and discard that time source as sync candidate). “Large” in this context means “tens of miliseconds per sync opportunity” (NTP client asks server for time every now and then, by default interval is between 64s and 1024s). And that’s less than precission which can be derived from NMEA telegrams only.
Now, if the fact that ROS NTP server stops giving out time after a week is the only problem you see, then open trouble ticket with mikrotik support (support@mikrotik.com , https://mikrotik.com/support ) and also give them supout.rif, taken when NTP server malfunctions.
If you insist on using local source for time sync of your network, you can use a low-cost device (e.g. RPi) running “normal” linux with NTP server which allows to use local clock as reference clock. You can then try to discipline local clock using NMEA telegrams if you will.
I don’t think this is any different from using mikrotik. Maybe linux can receive ppi from a serial port, but the “500ms” is enough for my needs.
Now, if the fact that ROS NTP server stops giving out time after a week is the only problem you see, then open trouble ticket with mikrotik support (> support@mikrotik.com > , > https://mikrotik.com/support > ) and also give them supout.rif, taken when NTP server malfunctions.
Yes, they started investigating this issue in May 2022, and there was progress but not much. This is why I came to forum.
Yes, but not for NTP’s needs… so it may experience strange phenomena when you use that as a time source.
(it will not want to select this time source because there is so much jitter)
When you have internet, at least you should add a timeserver on internet to your configuration, and you will most likely find that it selects that as its time source instead of the GPS.
OK. So in /system/ntp/server you have “use-local-clock” set to “yes” and “local-clock-stratum” to some sane number (like 10). After a while, what does /system/ntp/monitor-peers say about “server” with address 127.127.1.0?
When you have internet, at least you should add a timeserver on internet to your configuration
This is exactly the problem, I need to synchronize the clocks of various devices in a network environment without internet. 1 second error or jitter is not an issue.
I restarted the whole mikrotik 6 days ago and it works great now. I will answer this question within 1 to 3 days
After 12 days 8 hours and 50 minutes of startup, the ntp server failed.
at this time,
[admin@MikroTik] > /system/ntp/monitor-peers
type="ucast-client" address=127.127.1.0 refid="" stratum=2 hpoll=3 ppoll=0
root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms disp=0 ms jitter=0 ms
Dunno why but this fixes NTP for me:
/ip firewall nat
add action=masquerade chain=srcnat comment="NTP fix" dst-port=123 out-interface-list=WAN protocol=udp to-ports=\
12300-12390
It is because your ISP blocks the NTP port 123 for you. As explained above.
failed tx dst: 224.0.1.1 src::: err:No error information
Who knows what this is?
Enabled multicast but blocked multicast e.g. in firewall
defconf is not that much changed
Does anyone have any ideas?
If an ISP is blocking NTP, ask them if they have a NTP server you can use.
What I am experiencing is that a Mikrotik device will not update from a Mikrotik device. I have a hEX that is connected to the ISP as my primary router and two hAP ax3s connected to the hEX. They are network neighbors; they are on the same VLAN. The hEX has no problem receiving NTP updates from us.pool.ntp.org, and devices such as my Windows laptop have no problem getting NTP updates from the hEX. But neither hAP can get NTP updates from the hEX. They always remain in the waiting state when configured to receive NTP updates from the hEX. But when I configure them to get NTP updates from us.pool.ntp.org, there is no problem; they change to synchronized state in less than a minute. The hEX is the path to the ISP, so the NTP updates to the hAPs are passing through it to get to the hAPs. So, my conclusion is that Mikrotik NTP cannot talk to Mikrotik NTP.
-Mark