What's new

ntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin

  • 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!

@PeterR please can you post the error here

Installing on a RT-AC66u, error-

cp: can't stat '/www/require/modules/menuTree.js': No such file or directory
sed: /tmp/menuTree.js: No such file or directory
cp: can't stat '/tmp/menuTree.js': No such file or directory
mount: mounting /jffs/scripts/custom_menuTree.js on /www/require/modules/menuTree.js failed: No such file or directory​
 
Installing on a RT-AC66u, error-

cp: can't stat '/www/require/modules/menuTree.js': No such file or directory
sed: /tmp/menuTree.js: No such file or directory
cp: can't stat '/tmp/menuTree.js': No such file or directory
mount: mounting /jffs/scripts/custom_menuTree.js on /www/require/modules/menuTree.js failed: No such file or directory​
Thanks, I'll get that fixed for the next version
 
ntpMerlin has settled down nicely. The bounce all over were playing with scribe (syslog-ng) and a many reboots as I botched setting it up correctly o_O

Now nice and stable / quiet. I'm on the west coast USA, using the four us.pool.netp.org servers.

screenshot-router-asus-com-8443-2019-04-11-08-14-22.png
 
Last edited:
As a matter of course, when setting up an NTP client, I always pick pool.
If I have a good NTP client, it will figure out that this or that server is good or bad and switch to another.
A handy explanation of what and how is here:
http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ALGO-BASIC-SYNC
On install it had pool.ntp.org and it seemed to prefer China, which I have blocked along with other known bad sources, per firehol.

I change those to north-america.pool.ntp.org and was getting still wide fluctuations in jitter. I then narrowed it down to us.pool.ntp.org and after about a week it settled to what I posted above. The shorter the distance to the server pool, the better, obviously.
 
Last edited:
I change those to north-america.pool.ntp.org and was getting still wide fluctuations in jitter. I then narrowed it down to us.pool.ntp.org and after about a week it settled to what I posted above. The shorter the distance to the server pool, the better, obviously.

Have you narrowed the field to a single server entry or are you using 0, 1 , 2 , 3?
 
Installing on a RT-AC66u, error-

cp: can't stat '/www/require/modules/menuTree.js': No such file or directory
sed: /tmp/menuTree.js: No such file or directory
cp: can't stat '/tmp/menuTree.js': No such file or directory
mount: mounting /jffs/scripts/custom_menuTree.js on /www/require/modules/menuTree.js failed: No such file or directory​
Can you provide me with a copy of /www/state.js please? I modify that file with another script, and need to ensure nothing conflicts
 
Posting this just for discussion or use as needed... It may help explain some of the lines. The authoritative references are the NTP docs online.
#
# VCC-20190411
#
# The following restrict statements prevents using NTP as a traffic amplification tool by ignoring mode 6 and mode 7 packets.
# Especially the monlist feature has a big potential to be abused for this in older NTP versions
# Lock down NTP's default behavior from abuse
#
restrict default limited kod nomodify notrap nopeer noquery
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict source nomodify notrap noquery # required for pool directive if using restrictive default permissions
disable auth stats
#
# But allow local access and tools like ntpq full access to this system on loopback
#
restrict 127.0.0.1
#
# When using IPv6, comment out this line
#
# restrict -6 ::1
#
# Allow NTP to continue if NTP detects a large jump in time. This is most important for resuming VMs from suspend states, etc..
# However, it opens the system up to possible abuse from MIM attackes. Make sure you have sufficient time sources listed to prevent MIM attacks.
#
tinker panic 0
#
# The local (undisciplined) system clock, can be a backup time source when no time servers listed are responding.
# Be careful as Intel / X86 systems are not designed with extremely accurate time chips.
# For safer operations on time SERVERS, create this as a high stratum level to let any potential clients know this source may be marginal.
# Stratum 12 forces clients to use any other timesource they have loaded with a higher stratum.
# In some cases, if this is a main timeserver, then carefully consider whether to use the local system clock at all.
#
server 127.127.1.0
fudge 127.127.1.0 stratum 12
#
# replace the following time servers to the ones close to you
# see http://support.ntp.org/bin/view/Servers/NTPPoolServers
#
# The 'burst and iburst' keywords speeds up initial synchronization, but can be a source for abuse.
# burst tells NTP to send a burst of eight packets to the remote server instead of one when the server is reachable.
# iburst tells NTP to send a burst of eight packets to the remote server when the server is not reachable.
# The result is faster and more reliable synchronizations.
# Be careful with burst and iburst as SOME public servers may deny or frown upon the request as it places additional response burden on those target servers..
# 0, 1, 2 are a randomized pool of US NTP servers which change hourly. These are mostly Stratum 1, 2
#
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst
server 3.us.pool.ntp.org iburst
#
# Use a specific TRUSTED public US NTP servers...
#
server time.apple.com iburst # Stratum 1
server time.nist.gov iburst # Stratum 1 or 2
server clock1.unc.edu iburst # Stratum 2
#
# Here is where we may want to add international TRUSTED time sources from countries of presence from the pool project.
# Some of these may return Stratum 1 time sources.
# For internationals, we can alter the listing to include those here. They will be automatically "not used" b/c the stratums and network delays will likely disqualify them from use.
#
# server pool.ntp.org iburst # Stratum 2
#
# Lines below from original ntpMerlin source packages
#
interface ignore wildcard
interface listen br0
#
logfile /opt/var/spool/ntp/ntp.log
driftfile /opt/var/spool/ntp/ntp.drift
#
# https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
#
#leapfile /opt/var/spool/ntp/leap-seconds.list
#
# <EOF>
#

You can use nptq -p to poke around a bit more in what ntp's seeing..

/jffs/configs# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 12 l 41 64 1 0.000 0.000 0.000
+time.richiemcin 200.98.196.212 2 u 7 8 17 29.771 0.867 4.170
-4.53.160.75 64.113.44.54 2 u 7 8 17 51.130 -2.410 3.226
*t2.time.bf1.yah 98.139.133.62 2 u 7 8 17 44.802 3.699 3.359
+eterna.binary.n 199.102.46.70 2 u 7 8 17 48.906 -0.713 3.312
-ussjc2-ntp-002. .GPSs. 1 u 30 64 1 88.546 4.033 1.055
-time-d-b.nist.g .NIST. 1 u 29 64 1 82.563 -10.874 1.501
-ntp1.net.unc.ed .GPS. 1 u 28 64 1 21.416 1.117 0.517

Sorry about the min/max poll settings earlier. I should have checked the logs after a restart.

I updated my default for the router and just dropped it in.
My defaults were minpoll 6 maxpoll 7. Due to the discussion below, I removed minpoll and maxpoll from my example.
You may set them as you wish noting the recommendations as long as you understand the environments in which you are operating.
The actual defaults are minpoll 6 maxpoll 10 which should work well for most setups too.
 
Last edited:
server 0.us.pool.ntp.org iburst minpoll 1 maxpoll 3
server 1.us.pool.ntp.org iburst minpoll 1 maxpoll 3
server 2.us.pool.ntp.org iburst minpoll 1 maxpoll 3
server 3.us.pool.ntp.org iburst minpoll 1 maxpoll 3

Tried and it appears that minpoll 1 is invalid?

Apr 13 09:27:58 S77ntpd: Waiting for NTP to sync before starting...
Apr 13 13:27:58 ntpd[19278]: ntpd 4.2.8p12@1.3728-o Fri Mar 22 21:45:59 UTC 2019 (1): Starting
Apr 13 13:27:58 ntpd[19278]: Command line: ntpd -c /jffs/configs/ntp.conf -g
Apr 13 13:27:58 ntpd[19283]: proto: precision = 2.567 usec (-18)
Apr 13 13:27:58 ntpd[19283]: minpoll: provided value (1) is out of range [3-255])
Apr 13 13:27:58 ntpd[19283]: switching logging to file /opt/var/spool/ntp/ntp.log
Apr 13 09:27:59 ntpMerlin: Lock file found (age: 67 seconds) - stopping to prevent duplicate runs

I set to minpoll 3 maxpoll 6

Is this correct?
 
Last edited:
Tried and it appears that minpoll 1 is invalid?

Apr 13 09:27:58 S77ntpd: Waiting for NTP to sync before starting...
Apr 13 13:27:58 ntpd[19278]: ntpd 4.2.8p12@1.3728-o Fri Mar 22 21:45:59 UTC 2019 (1): Starting
Apr 13 13:27:58 ntpd[19278]: Command line: ntpd -c /jffs/configs/ntp.conf -g
Apr 13 13:27:58 ntpd[19283]: proto: precision = 2.567 usec (-18)
Apr 13 13:27:58 ntpd[19283]: minpoll: provided value (1) is out of range [3-255])
Apr 13 13:27:58 ntpd[19283]: switching logging to file /opt/var/spool/ntp/ntp.log
Apr 13 09:27:59 ntpMerlin: Lock file found (age: 67 seconds) - stopping to prevent duplicate runs

I set to minpoll 3 maxpoll 6

Is this correct?
Please explain to everyone why you think a poll of less than six to a public NTP server is acceptable.
 
https://access.redhat.com/solutions/39194

minpoll <value>
maxpoll <value>

  • These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two.

  • The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h).

  • The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 3 (8 s).
 
Please explain to everyone why you think a poll of less than six to a public NTP server is acceptable.

I was strictly looking at the range provided by Gattaca ( server 0.us.pool.ntp.org iburst minpoll 1 maxpoll 3 )
If the range was invalid (1) and the minimum is 3, I was just adjusting the range parameters by a factor of 3 (3 -6) instead of (1 -3).

According to this https://access.redhat.com/solutions/39194 provided by hervon, it appears that no parameters should be set.

Is there a polite parameter to set? [3-255] Or should minpoll, maxpoll not be used?
 
Last edited:
I was strictly looking at the range provided by Gattica ( server 0.us.pool.ntp.org iburst minpoll 1 maxpoll 3 )
If the range was invalid (1) and the minimum is 3, I was just adjusting the range parameters by a factor of 3 (3 -6) instead of (1 -3).

According to this https://access.redhat.com/solutions/39194 provided by hervon, it appears that no parameters should be set.

Is there a polite parameter to set? Or should minpoll, maxpoll not be used?

Yes, you can use the defaults. That's recommended for most setups.

I altered the NTP settings b/c we've had trouble with the polling when "internal NTP" servers were used. Notice my comment about VMs and those commodity clock chipsets - they were never designed for accuracy.

The more high-quality "NTP peers" you have listed, the less the is a need to alter the defaults. Our trouble is far too often people just listed one or two "internal" NTP servers (not a pool). For example, typical IT often points to routers and "PCs" to be NTP servers when they have no business hosting that function - especially with those wandering clock chipsets. Then when things start breaking due to time-drifts, everyone goes but my NTP is working... Yeah, and what NTP Servers are you using again? LOL

They are also useful if you want to make sure that your NTP daemon will detect an outage of the NTP peers in less time.

For this install, the defaults or removing those 2 parms from the lines is fine. I just shared my default ntp.conf to explain what some of the lines do. Later!
 
Last edited:
https://access.redhat.com/solutions/39194

minpoll <value>
maxpoll <value>

  • These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two.

  • The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h).

  • The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 3 (8 s).
So, @EmeraldDeer was being a bit cryptic ... using a minpoll of less than 6 against public servers at the very least is considered extremely rude, and also is likely to get you kicked off of the public servers, and can actually decrease your overall clock accuracy. Please don't change minpoll below 6.
 
I was strictly looking at the range provided by Gattaca ( server 0.us.pool.ntp.org iburst minpoll 1 maxpoll 3 )
If the range was invalid (1) and the minimum is 3, I was just adjusting the range parameters by a factor of 3 (3 -6) instead of (1 -3).

According to this https://access.redhat.com/solutions/39194 provided by hervon, it appears that no parameters should be set.

Is there a polite parameter to set? [3-255] Or should minpoll, maxpoll not be used?
Polite Parameters for public NTP servers
  • Minpoll defaults to 6 (64 seconds). Minpoll should never be set lower than six.
  • Maxpoll defaults to 10 (1024 seconds). It is acceptable to go as low as six. Most clocks perform poorly, so wide clock offsets from changes in ambient temperature and computer load may make maxpoll as low as 6 desirable.
  • Iburst is acceptable but burst is not acceptable
If you also have your own NTP server
  • Minpoll can be set to the minimum of 3 (8 seconds) but is not very effective unless NTP server is connected to GPS
  • Set iburst to your NTP server and remove iburst from the public NTP servers in your ntp.conf.
 
So, @EmeraldDeer was being a bit cryptic ... using a minpoll of less than 6 against public servers at the very least is considered extremely rude, and also is likely to get you kicked off of the public servers, and can actually decrease your overall clock accuracy. Please don't change minpoll below 6.

That's how I took it.

Edit: So I see @gattaca changed the example to ( 3 and 6 ) which is still wrong and the minimum that can be safely used is (6 and 6), for Public Servers.
 
Last edited:

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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