ntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin

[Kingp1n]

So, the ntp daemon provided by 384.11 is unfortunately too limited to be queried by ntpq, so ntpmerlin will continue to require Entware. I will update it to be 384.11 aware (so that it can tweak nvram where needed), but i cannot integrate.

Feature-wise, ntpmerlin provides graphing as a benefit over the firmware implementation, since the redirect and the ntp daemon itself have now been integrated.

@RMerlin can the ntp redirect nvram variable be set even if ntp is in client mode only? If so, I can simplify my redirect code

EDIT: graphs will be migrated to interactive charts driven by chart.js a la uiDivStats

Dumb question, so i have removed the ntp Merlin script since it's been integrated under the new FW (384.11). How do you enable it now under the new FW and does it provide the graphs as well?

 

[QuikSilver]

Dumb question, so i have removed the ntp Merlin script since it's been integrated under the new FW (384.11). How do you enable it now under the new FW and does it provide the graphs as well?

The only part it added is the redirecting of clients that NTPmerlin does as well. The graph feature is only part of NTPmerlin.

Edit: Feature your referring to is under Administration-->System-->Basic Config. Enable local NTP server (yes/n0). If YES is chosen you have "Intercept NTP client request".

 

[L&LD]

Dumb question, so i have removed the ntp Merlin script since it's been integrated under the new FW (384.11). How do you enable it now under the new FW and does it provide the graphs as well?

If you want the graphs and the much more accurate time-keeping with ntpMerlin, make sure to disable the built-in 384.11 feature, reboot the router, and then re-install ntpMerlin.

(ntpMerlin is much more accurate because it continuously polls the NTP servers, my understanding is that RMerlin only polls a few times per 24 hours).

From the last few posts here, you may want to wait until Jack Yaz releases his updated script first.

For the record though, I've been using Jack Yaz's script from 384.10_2 and all the alphas and betas in between with no issues at all.

 

[RMerlin]

(ntpMerlin is much more accurate because it continuously polls the NTP servers, my understanding is that RMerlin only polls a few times per 24 hours).

My implementation behaves like a normal ntpd. It polls a couple of time over a short period of time, and gradually reduces the frequency according to the amount of skew encountered with each polls.

These are the default values used by Busybox's ntpd:

#define MINPOLL         6       /* minimum poll interval. std ntpd uses 6 (6: 64 sec) */
/*
 * If offset > discipline_jitter * POLLADJ_GATE, and poll interval is > 2^BIGPOLL,
 * then it is decreased _at once_. (If <= 2^BIGPOLL, it will be decreased _eventually_).
 */
#define BIGPOLL         9       /* 2^9 sec ~= 8.5 min */
#define MAXPOLL         16      /* maximum poll interval (12: 1.1h, 17: 36.4h). std ntpd uses 17 */

 

[no_name]

Just an observation and apologies if this has been addressed already. The address bar reads /feedback_info.asp

Speed test screen is similar


Sent from my iPad using Tapatalk

 

[WuTang LAN]

If you want the graphs and the much more accurate time-keeping with ntpMerlin,

ntpMerlin is much more accurate

A little misleading, as you're implying the ntpd built-in to 384.11 is not accurate enough.
I would say the ntpd is accurate enough for 99.9% of users.

The main draw for ntpmerlin now is visual feedback from the graphs.

 

[L&LD]

A little misleading, as you're implying the ntpd built-in to 384.11 is not accurate enough.
I would say the ntpd is accurate enough for 99.9% of users.

The main draw for ntpmerlin now is visual feedback from the nice graphs.

No, it is not misleading and I did not state that 384.11 is not accurate enough.

I said it is more accurate, which it is.

See post 524 above and compare it to how ntpMerlin works.

 

[jsbeddow]

I would say the ntpd is accurate enough for 99.9% of users.

Agreed. My only question regards whether using the new in 384.11 built-in ntpd service with the option enabled to "Intercept NTP client requests" functions in the same manner as the kvic/Jack Yaz ntpmerlin version. Is the built-in one also truly redirecting all NTP requests on the LAN, in the way that ntpmerlin does when that option is enabled? I was under the impression that ntpMerlin version was somehow doing a more thorough job of that, but I can't recall the source of that info.

 

[Jack Yaz]

Agreed. My only question regards whether using the new in 384.11 built-in ntpd service with the option enabled to "Intercept NTP client requests" functions in the same manner as the kvic/Jack Yaz ntpmerlin version. Is the built-in one also truly redirecting all NTP requests on the LAN, in the way that ntpmerlin does when that option is enabled? I was under the impression that ntpMerlin version was somehow doing a more thorough job of that, but I can't recall the source of that info.

Nope, same iptables approach

 

[Jack Yaz]

Just an observation and apologies if this has been addressed already. The address bar reads /feedback_info.asp

Speed test screen is similar


Sent from my iPad using Tapatalk

Yup, that's expected as I'm overriding existing pages rather than use my own and have the user have to clone /www

 

[no_name]

Yup, that's expected as I'm overriding existing pages rather than use my own and have the user have to clone /www

Thanks for taking the time to explain the reason [emoji3]


Sent from my iPad using Tapatalk

 

[RMerlin]

Nope, same iptables approach

And both with the same limitation - doesn't handle IPv6.

 

[RMerlin]

I said it is more accurate, which it is.

If it's polling much more frequently and not adapting the frequency over time, then it's not following proper ntpd rules, and is also a breach of netiquette that might result in your IP getting blacklisted from that server.

 

[L&LD]

If it's polling much more frequently and not adapting the frequency over time, then it's not following proper ntpd rules, and is also a breach of netiquette that might result in your IP getting blacklisted from that server.

I don't know if that is true or not? Maybe @Jack Yaz can answer that for us both?

 

[Butterfly Bones]

I don't know if that is true or not? Maybe @Jack Yaz can answer that for us both?

Having tested and used many other developments from kvic, I doubt his implementation used in ntpMerlin is non-compliant.

 

[L&LD]

Having tested and used many other developments from kvic, I doubt his implementation used in ntpMerlin is non-compliant.

I have no doubt too.

 

[cmkelley]

No, it is not misleading and I did not state that 384.11 is not accurate enough.

I said it is more accurate, which it is.

See post 524 above and compare it to how ntpMerlin works.

I'd bet you lunch the busybox implementation is every bit as accurate as ntpMerlin. I'd go so far as to bet the basic timekeeping code is the same, since ntp.org supplies a BSD-style license reference implementation. Why would anyone re-invent it?

- Firstly, polling the NTP servers more often turns out to not really increase time accuracy, and if you do it too often, good manners aside, you can actually decrease time accuracy. NTP is actually fairly complex code that actively figures out the "best" interval between polling.

- Secondly, after a quick perusal of the code, it sure doesn't look like ntpMerlin affects the NTP server interrogation frequency at all. Getting statistics from the daemon does not mean forcing it to poll NTP servers.

- Thirdly, the luck of the dice on how stable the oscillator is in your router plays a much bigger part than any difference there might be between the NTP implementations. My AC3200 keeps significantly more accurate time (~ 400 to 800 us offset) than my AC86U (~ 1 to 3 ms). Which isn't to say all AC3200s are more accurate than AC86Us, I'd bet a steak dinner they aren't, it's just how good the oscillator is that got pulled off the roll in the automatic pick and place machine. Not to mention they're not temperature controlled or compensated, there could be stress risers from differential expansion and contraction of the solder joints, etc.

 

[RMerlin]

Unless you work for SpaceX, a 1-2 seconds difference in clock accuracy won't be noticeable...

 

[L&LD]

I'd bet you lunch the busybox implementation is every bit as accurate as ntpMerlin. I'd go so far as to bet the basic timekeeping code is the same, since ntp.org supplies a BSD-style license reference implementation. Why would anyone re-invent it?

- Firstly, polling the NTP servers more often turns out to not really increase time accuracy, and if you do it too often, good manners aside, you can actually decrease time accuracy. NTP is actually fairly complex code that actively figures out the "best" interval between polling.

- Secondly, after a quick perusal of the code, it sure doesn't look like ntpMerlin affects the NTP server interrogation frequency at all. Getting statistics from the daemon does not mean forcing it to poll NTP servers.

- Thirdly, the luck of the dice on how stable the oscillator is in your router plays a much bigger part than any difference there might be between the NTP implementations. My AC3200 keeps significantly more accurate time (~ 400 to 800 us offset) than my AC86U (~ 1 to 3 ms). Which isn't to say all AC3200s are more accurate than AC86Us, I'd bet a steak dinner they aren't, it's just how good the oscillator is that got pulled off the roll in the automatic pick and place machine. Not to mention they're not temperature controlled or compensated, there could be stress risers from differential expansion and contraction of the solder joints, etc.

Great points! With ntpMerlin, I am at ~51.54 u offset. I would try the built-in NTP server but the graphs are too nice and I wouldn't know how accurate they would be, comparatively!

 

[Jack Yaz]

v1.3.0 is available
Changelog:

New directory structure in /jffs/scripts
uiDivStats compatibility

After updating also run

ntpmerlin startup