ntpMerlin ntpMerlin v3.x

[Jack Yaz]

v3.4.5
Updated 2021-08-05

ntpMerlin implements an NTP time server for AsusWRT Merlin with charts for daily, weekly and monthly summaries of performance. A choice between ntpd and chrony is available.

ntpMerlin is free to use under the GNU General Public License version 3 (GPL 3.0).

This project is hosted on GitHub

Love the script and want to support future development? Any and all donations gratefully received!
PayPal donation
Buy me a coffee

Supported firmware versions
You must be running Merlin 384.15/384.13_4 or Fork 43E5 (or later) Asuswrt-Merlin

Installation
Using your preferred SSH client/terminal, copy and paste the following command, then press Enter:

/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/jackyaz/ntpMerlin/master/ntpmerlin.sh" -o "/jffs/scripts/ntpmerlin" && chmod 0755 /jffs/scripts/ntpmerlin && /jffs/scripts/ntpmerlin install

Usage
WebUI
ntpMerlin can be configured via the WebUI, in the Addons section.

Command Line
To launch the ntpMerlin menu after installation, use:

ntpmerlin

If this does not work, you will need to use the full path:

/jffs/scripts/ntpmerlin

 

[Jack Yaz]

Screenshots

Spoiler: WebUI

Spoiler: CLI

 

[Jack Yaz]

v3.1.0 is now available
Changelog

• IMPROVED: Update charts without a page refresh
• CHANGED: Script launches on boot from post-mount and not services-start
• FIXED: chrony.conf wasn't moved when switching storage type - thanks @JGrana
• FIXED: S77chronyd was not removed on uninstall - thanks @JGrana

 

[heysoundude]

Is anyone testing this on any of the v386.1 betas, just to possibly get ahead of the game a little bit?
I'm looking forward to that firmware, and have been watching (and loving) this idea and now script since the @kvic days (but I wasnt sure my old n66 could handle it...that was mooted when it gave up the ghost and I migrated to an ac86).
Jack, you're bloody amazing, making this stuff so easy for us. thank you.

 

[L&LD]

To use the words of a good friend... it's working bloody amazing! On RT-AX88U, RT-AX86U, RT-AC86U, RT-AC3100, RT-AC68U, RT-AC66U_B1. All running RMerlin Beta 3 or better.

 

[Jack Yaz]

Any way to ensure dnscrypt log timestamps are synced up with dnsmasq/ntp? I used ntpmerlin, the problem persisted; I removed ntpmerlin, enabled asuswrtmerlin's built in ntp option in the ui and still dnscrypt logs are not syncing up properly. (related)

This is a dnscrypt-proxy issue, so best answered in your separate thread.

 

[Jack Yaz]

Is anyone testing this on any of the v386.1 betas, just to possibly get ahead of the game a little bit?
I'm looking forward to that firmware, and have been watching (and loving) this idea and now script since the @kvic days (but I wasnt sure my old n66 could handle it...that was mooted when it gave up the ghost and I migrated to an ac86).
Jack, you're bloody amazing, making this stuff so easy for us. thank you.

You're very welcome!

 

[heysoundude]

I'm considering adding this before v386 is fully cooked - I'm hoping it will help me either diagnose or better, eliminate the jitter spikes I'm seeing in spdMerlin.
I suspect those events occur when readjusting Offset or for drift.
Can anyone speak to that? Something tells me that the metrics are in place to do so with these running...

 

[L&LD]

I don't believe keeping better time will help with what your ISP service level you get. But when I started using the chronyd variant instead of ntpd, the network was noticeably more responsive to me (@ColinTaylor was confused by that, I remember...).

There are zero reasons to not be using it now. But many benefits!

 

[heysoundude]

I don't believe keeping better time will help with what your ISP service level you get. But when I started using the chronyd variant instead of ntpd, the network was noticeably more responsive to me (@ColinTaylor was confused by that, I remember...).

There are zero reasons to not be using it now. But many benefits!

This is the 2nd time I've edited this post, for anyone following along: I had a moment of config difficulty (until I paid a bit closer attention to the .conf file contents/comments - DOH!), so I wasn't getting the tab in the GUI or charts populating.
Now that I've fixed that oversight, GUI tab is there and charts are populating and clock is settling: it looks like the clock circuitry in my AC86 runs a hair on the fast side, as my avg offset is negative, but it's a good clock because jitter is under 0.2msec (and falling), and drift is under 0.2ppm (and similarly falling). I wonder if it'll settle into usec and ppb ranges...
Like @L&LD I also chose chrony, and it feels as if things definitely move more snappily/smoothly here on my desktop as well as on my mobile. from my "day job" I know how important digital clocking is, but now I'm witnessing it on my network too.
If you've a supported router and are on the fence - even with a 1Gbps fibre connection (where it's probably MORE important than my 50/10)- you'll find this takes your network to another level

 

[heysoundude]

So, I've a question -
is it just me or does everyone else's jitter and drift charts look exactly the same? Jitter and drift are graphing the same dataset, albeit with their respective units. This isn't correct, is it?

 

[JT Strickland]

So, I've a question -
is it just me or does everyone else's jitter and drift charts look exactly the same? Jitter and drift are graphing the same dataset, albeit with their respective units. This isn't correct, is it?
View attachment 29575View attachment 29576

I believe you're correct, I have noticed mine are very similar.

 

[Jack Yaz]

Perhaps we're plotting the wrong metrics.

 

[Treadler]

So, I've a question -
is it just me or does everyone else's jitter and drift charts look exactly the same? Jitter and drift are graphing the same dataset, albeit with their respective units. This isn't correct, is it?
View attachment 29575View attachment 29576

Yup, mine are identical.

 

[Jack Yaz]

I have made some changes on the develop branch

ntpmerlin develop

Jitter has been removed from the WebUI as on further reading I don't feel it's a useful metric. It is still captured and available for users to query in the database or review in the CSV export file.
It looks like an issue crept in a while ago with data being fed into the wrong columns, which I have now corrected. This means Frequency AKA drift will look a bit different, but should be a fairly straight line.

EDIT: moving back to stable from develop will mean database columns will be incorrect and graphs will look weird!

 

[heysoundude]

I have made some changes on the develop branch

ntpmerlin develop

Jitter has been removed from the WebUI as on further reading I don't feel it's a useful metric. It is still captured and available for users to query in the database or review in the CSV export file.
It looks like an issue crept in a while ago with data being fed into the wrong columns, which I have now corrected. This means Frequency AKA drift will look a bit different, but should be a fairly straight line.

EDIT: moving back to stable from develop will mean database columns will be incorrect and graphs will look weird!

I will wait for the update. Thanks folks (maybe I sleep too much comparatively...that all happened over night for me - yikes, and cool. lol)

 

[JGrana]

A few observations...

I was working on a script to migrate my dnsmasq.host.add to @Jack Yaz YazDHCP. I ended up with a bug that assigned my Rpi Chrony server to have the wrong address. IP renewed around 11:30PM.

No more GPS/PPS based local time source.

Realized it this morning (pool.ntp.org actually informed me ;-) and I fixed it - around 9:30AM.

1) Nice to have a local Stratum 1 timesource on the network.
2) I'm impressed that chrony was able to, over time, converge to pretty good time offset. Nice slope.
3) Good to have some other servers/pools in chrony.conf!

 

[EmeraldDeer]

A few observations...

I was working on a script to migrate my dnsmasq.host.add to @Jack Yaz YazDHCP. I ended up with a bug that assigned my Rpi Chrony server to have the wrong address. IP renewed around 11:30PM.

No more GPS/PPS based local time source.

Realized it this morning (pool.ntp.org actually informed me ;-) and I fixed it - around 9:30AM.

View attachment 29683

1) Nice to have a local Stratum 1 timesource on the network.
2) I'm impressed that chrony was able to, over time, converge to pretty good time offset. Nice slope.
3) Good to have some other servers/pools in chrony.conf!

===============================================================================
Reference ID    : C0A832E6 (LeoNTP)
Stratum         : 2
Ref time (UTC)  : Wed Jan 20 03:36:49 2021
System time     : 0.000003204 seconds fast of NTP time
Last offset     : +0.000008174 seconds
RMS offset      : 0.000044115 seconds
Frequency       : 5.287 ppm slow
Residual freq   : +0.003 ppm
Skew            : 0.220 ppm
Root delay      : 0.000554169 seconds
Root dispersion : 0.000089472 seconds
Update interval : 48.5 seconds
Leap status     : Normal
===============================================================================
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.cloudflare.com           3  10   377   134  -1345us[-1356us] +/-   11ms
^- time.cloudflare.com           3  10   377   267  -1998us[-1988us] +/-   11ms
^- time.cloudflare.com           3  10   377   657  -2794us[-2799us] +/-   12ms
^- time.cloudflare.com           3  10   377   856  -1881us[-1904us] +/-   11ms
^* LeoNTP                        1   3   377    56    +12us[  +20us] +/-  289us
==============================================================================
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
time.cloudflare.com        23  13  379m     -0.016      0.015  -1377us   129us
time.cloudflare.com        10   5  172m     -0.025      0.064  -1543us   152us
time.cloudflare.com        21  13  396m     -0.016      0.021  -1525us   149us
time.cloudflare.com        36  19   10h     -0.030      0.006  -1578us   115us
LeoNTP                     14  10   379     -0.001      0.135     -0ns    15us
==============================================================================
Tue Jan 19 22:37:46 EST 2021
 22:37:46 up 2 days,  9:54,  load average: 1.86, 1.92, 1.97
==============================================================================

 

[heysoundude]

people who are just tuning in should be made aware of how awesomely cool this is:
you're tuning your network (meaning all the devices connected to it) to be as time accurate as the atomic clocks the script references.

1 ms (millisecond) = 0.001 sec, 1 thousandth of a second
1 us (microsecond) = 0.000 001 sec, 1 millionth of a second
1 ns (nanosecond) = 0.000 000 001 sec, 1 billionth of a second

This is beneficial because the little bits of drift and offset can cause tiny little issues that the router and devices have to correct for to make data move smoothly; those corrections take time, and they slow things down. don't discount this as irrelevant - the mechanisms on each end can only compensate so much before packets get dropped and speeds/throughput gets reduced: The more accurate the clock your network/devices reference, the more efficiently they work.

 

[JemTheWire]

And the graphs look cool.