Today I #TIL: Mikrotik NTP support and the surprise use of octal counting

This is hopefully the first post in the “Today I #TIL” series. Yes, I know :) Hi Amin:) The idea is to make shorter blog posts about one or two new things that I learned more or less on the same day as the blog post.

Today something unsuspecting happened. I was working away, writing Python and all that stuff, when the Internet broke. I had WiFi, but no Internet access. I assumed my ISP was acting up again, but this is was something different. To cut the story short, my WiFi bridge (described in this blog post) stopped working, and I had to restart one of my Audience access points to make it work again.

But that’s not the main story. When I was browsing through WinBox (Mikrotik’s configuration software) I came across the NTP section. And so I learnt that Mikrotik devices (I guess most of them?) can work as an NTP server, an NTP client, or both.

NTP, Network Time, Protocol, is the way computers share information about the time. There are NTP servers that have very precise clocks, which tell other computers which time it is. And this can work in a cascade, any computer can be an NTP server, get the time from an upstream NTP server, and share it amongst its peers.

Jeff Geerling made a few interesting videos about NTP and Raspberry Pis.

And so I thought that it would be fun to set up my Mikrotik router to get the time from some proper NTP server and share it in my local network. Yes, I know, I have a rather special definition of fun. But you, dear reader, are reading this post, so probably we have something in common.

First I looked for a suitable time server. I wanted something relatively local. And a quick search resulted in this: Główny Urząd Miar (in Polish). Turns out, a Polish governmental organisation, Główny Urząd Miar (Central Office of Measures) runs their own NTP servers, and they are located in the “Laboratory of Time and Frequency”, which sounds like a super cool place to work.

With the server chosen, I went to configure NTP services on the router. And that is very simple, Mikrotik’s NTP docs say it all.

This is how I configured my NTP server and client on the router:

Screenshot of the Mikrotik’s configuration showing the NTP client and server windows

I added two CIDR ranges because my access points create a second NAT, so the devices connected straight to router are in the 192.168.88.0/24 range, the ones connected over Wifi are in the 192.168.10.0/24 range. I could probably modify it to have a flat single range, but I just don’t want to touch the Audience’s configuration.

And le voila por favor, my Mikrotik router is now an NTP client, taking the time from the Laboratory, as well as a local NTP time server, being able to share the time with other machines.

Now, time to set it on the clients. Right now, all of my devices run either Debian or Kubuntu. My desktop is running Kubuntu 25.04, and there time is handled by the friendly named systemd-timesyncd service.

Changing the time server from the default, Ubuntu’s one to a different one is a matter of changing the /etc/systemd/timesyncd.conf. To add a custom server, uncomment the line starting with NTP and add the address of the server. Now just

sudo systemctl restart  systemd-timesyncd.service

And the new configuration can be confirmed by running

timedatectl timesync-status

The response should show the new server being used.

Now, on my Home Assistant box I am running Debian which uses the (I’m guessing) older ntpd daemon to get the time, and here things got more interesting.

On Debian, changing the time server requires modifying the /etc/ntpsec/ntp.conf file. I added server 192.168.88.1 above any other server or pool line.

Then it’s just running

sudo systemctl restart ntpd.service

and it should be fine.

To confirm the change was done, run

ntpq -p

If there is no such program, install it with

sudo apt install ntpstat

For me the result of running ntpq -p was

     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
*_gateway                                194.146.251.100  2 u   18   64  377   0.2879   0.0059   0.1151

The mysterious “reach” number

Everything in the output of this command was relatively clear, expect for the reach part. It was changing in a seemingly random way, and the ntpq documentation was not clear on the matter.

Thankfully, I found this site that explained how beautifully weird it is.

The reach value describes eight bits of information, each being 0 or 1, but in octal. That sequence is the history of connecting the server, and each of those eight bits describes whether the connection was successful (1) or not (0). Those eight bits are then converted to octal. 11111111 (eight good connections) is 377 in octal, and so 377 shows no problem with connectivity. A better and more thorough explanation can be found on the linked site. Why did they do it? I don’t know, but I am sure that a group of very smart engineers have had very good reasons to do so.

Bottom Line

Today I #TIL that

— Mikrotik hardware can work as an NTP server and client
— Poland has a Laboratory of Time and Frequency
— ntpq has some fascinating quirks

Is this knowledge useful in any way? Not really, but does knowledge need to be useful? I don’t think so. I hope there will be many more such #TIL posts to come.

BTW, this is the first post that I wrote using only the zed editor in vim mode. Using vim keybindings is still often a pain, but I am persevering like a Martian rover, and every new keybinding that I learn is a spark of joy.

Thanks for reading!