What's new

ntpMerlin ntpMerlin v3.x

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Jack Yaz

Part of the Furniture
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:
Code:
/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:
Code:
ntpmerlin

If this does not work, you will need to use the full path:
Code:
/jffs/scripts/ntpmerlin
 
Last edited:
Screenshots
396909c6c7.png
02f06c84a4.png
 
Last edited:
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.
 
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. :D
 
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!
 
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...
 
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!
 
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
 
Last edited:
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?
jitter.jpgdrift.jpg
 
I have made some changes on the develop branch
Code:
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!
 
Last edited:
I have made some changes on the develop branch
Code:
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)
 
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.

NTP.JPG


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!
 
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!
Code:
===============================================================================
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
==============================================================================
 
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.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top