Hello!

According to RFC5905: "Primary servers are assigned stratum one; secondary servers at each lower level are assigned stratum numbers one greater than the preceding level."
My RouterOS 6.36 ntpd announces it is at stratum 0. I have a couple of devices that complain stratum must be in range 1-15 and can't synchronize. So would You please make startum configurable (preferred) or make it in range 1-15?

Kind regards,
Boris

It is not good to make it configurable.
It should have the correct value depending on the stratum of the reference it uses.
How does your router obtain time?
(locally connected GPS receiver, using other NTP servers, or using the "cloud time" feature)

My router obtain time via external NTP servers.

@borisk:
That top level (stratum 0) they talk about are the atomic clocks used as global references, like those at NIST, and the GPS reference clocks.
Unless you have a cesium clock at home, your time source is NOT stratum 0, and unless you have a GPS PPS synchronized time server, not even stratum 1. So those complains are right.
Since Mikrotik routers do not support PPS for time synchronization, it seems correct to assume they are at most stratum 4, unless they are synchronized to a lower stratum NTP server, when the MT will automatically get stratum N+1, where N is the uplink time source stratum - so you will get stratum 2 in the best case for your MT router.
Even more, that stratum 4 is actually faked if you run off the local clock, but was put in place so that the MT can be used as local network time source for windows machines, which only accept time sources with stratum less than 5.

I have checked the behavior of the NTP server on recent NTP server packages on MT hardware, and all of them onnor the stratum conventions properly.

Dear all!

Thanks for clarification. Maybe I really missed something in NTP, but to facts:
1) I have RouterOS 6.36 installed
2) I have NTP client configured with external NTP servers, all are stratum 2
3) I have NTP server configured with RouterOS

So, when I point another devices to RouterOS as NTP server, it returns:
%Aug 07 18:12:58 2016 NTP: xmit packet to 10.255.255.254
%Aug 07 18:12:58 2016 leap 0, mode 3, version 4, stratum 3, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.000ms, refid 95.104.192.10
%Aug 07 18:12:58 2016 ref db51f82f.613543ae (Sun Aug 7 18:10:55.379 2016)
%Aug 07 18:12:58 2016 org 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 rec 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 xmt db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 NTP: receive packet from 10.255.255.254

>>>>>>>>>>>%Aug 07 18:12:58 2016 leap 3, mode 4, version 4, stratum 0, ppoll 6

%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.092ms, refid 73.78.73.84
%Aug 07 18:12:58 2016 ref 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 org db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 rec db51b22c.a98d5222 (Sun Aug 7 13:12:12.662 2016)
%Aug 07 18:12:58 2016 xmt db51b22c.aa27766d (Sun Aug 7 13:12:12.664 2016)
stratum error <1-15> !

Is this wrong? I think - yes. Have I misunderstood something with NTP? May be yes But I can't synchronize with ROS NTP server. What to do? Please clarify.

Kind regards,
Boris

%Aug 07 18:12:58 2016 leap 0, mode 3, version 4, stratum 3, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.000ms, refid 95.104.192.10

This seams correct. Stratum 3 is as it should be.

%Aug 07 18:12:58 2016 leap 3, mode 4, version 4, stratum 0, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.092ms, refid 73.78.73.84
%Aug 07 18:12:58 2016 ref 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 org db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 rec db51b22c.a98d5222 (Sun Aug 7 13:12:12.662 2016)
%Aug 07 18:12:58 2016 xmt db51b22c.aa27766d (Sun Aug 7 13:12:12.664 2016)
stratum error <1-15> !

Now this is certainly wrong.
First of all there is this ref 00000000.00000000 which is invalid. This have to be a time stamp when the server last time set its clock.
Since it never happened, this whole information is invalid.

%Aug 07 18:12:58 2016 leap 0, mode 3, version 4, stratum 3, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.000ms, refid 95.104.192.10

This seams correct. Stratum 3 is as it should be.

You missed that first packet is sent from my device to ROS. Yes, this device is already synchronized to other NTP servers and is at stratum 3. But the second packet is returned from ROS, and, as You said - is certainly wrong. So if this is a bug it MUST be fixed. If this is standard - it must be changed.

I changed thread title to "bug"

@docmarius:
And yes, ROS is synchronized to external NTP:
[boris@MikroTik] /system clock> print
time: 18:35:50
date: aug/07/2016
time-zone-autodetect: yes
time-zone-name: Asia/Yekaterinburg
gmt-offset: +05:00
dst-active: no
[boris@MikroTik] /system clock> /system ntp client print
enabled: yes
mode: unicast
primary-ntp: 95.104.192.10
secondary-ntp: 93.180.6.3
dynamic-servers:
status: started

Now if I check the specs on the ntp, I think it may be correct somehow...

Let me explain: Here we see that the MT uses server 73.78.73.84 as uplink, but has never set its clock (ref is 0).
So the router's system time is invalid from NTP point of view.
And here we see the timestamp dialog, which seems valid.

And now let's see the result: - leap 3 means: Alarm condition, clock not synchronized
- mode 4 means: Server
- stratum 0 means: unspecified
- ppoll could be wrong (the maximum interval between messages in seconds to the nearest power of two, so 6 is not right, but of no importance)

So what you are basically getting is a response that your time server is not synchronized. The question is: is your upper NTP layer working correctly?
It seems it is just set to synchronize, but is not actually synchronized when the problem occurs.
BTW, server 73.78.73.84 is not in your server list. Where does this come from?

It seems your client isn't working, which makes the server behavior correct.
It should look like:

@docmarius:
Ok, do You have an idea how to debug my ntp client and understand what is wrong with it?

Sorry, pasted from the sntp client.
Corrected. The status should state "synchronized".

First, check if your firewall is passing port 123 UDP...
After that, the simplest way would be to try another time server. Just use pool.ntp.org and you will get one.

@docmarius:
Thanks for help and explanation. Now all is ok, clients get synchronized too.

[boris@MikroTik] /system clock> /system ntp client print
enabled: yes
mode: unicast
primary-ntp: 91.206.16.3
secondary-ntp: 85.21.78.91
dynamic-servers:
status: synchronized