ntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin

[Centrifuge]

My Jitter data in the graphs is still 0.0 across the board, even though I have 3 servers that I have tested at server test. I've restarted several times.

/opt/etc/init.d/S77ntpd restart

current servers

server ntproundtop.hawaii.edu iburst
server ntp.hawaii.edu iburst
server 0.pool.ntp.org iburst

Results of ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*128.171.235.62  128.171.73.54    2 u   60   64   37   11.127   -0.903   2.471
+198.50.238.156  213.251.128.249  2 u   67   64   37  127.073    6.725   2.274

 

[L&LD]

My Jitter data in the graphs is still 0.0 across the board, even though I have 3 servers that I have tested at server test. I've restarted several times.

/opt/etc/init.d/S77ntpd restart

current servers

server ntproundtop.hawaii.edu iburst
server ntp.hawaii.edu iburst
server 0.pool.ntp.org iburst

Results of ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*128.171.235.62  128.171.73.54    2 u   60   64   37   11.127   -0.903   2.471
+198.50.238.156  213.251.128.249  2 u   67   64   37  127.073    6.725   2.274

How long are you waiting? Leave it for a few hours at the least before checking (on some routers, I have seen 24 hours needed or more).

 

[EmeraldDeer]

My Jitter data in the graphs is still 0.0 across the board, even though I have 3 servers that I have tested at server test. I've restarted several times.

/opt/etc/init.d/S77ntpd restart

current servers

server ntproundtop.hawaii.edu iburst
server ntp.hawaii.edu iburst
server 0.pool.ntp.org iburst

Results of ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*128.171.235.62  128.171.73.54    2 u   60   64   37   11.127   -0.903   2.471
+198.50.238.156  213.251.128.249  2 u   67   64   37  127.073    6.725   2.274

Is sys_jitter zero?

# ntpq -4 -c rv | grep jitter
mintc=3, offset=0.016365, frequency=1.424, sys_jitter=2.397723,
clk_jitter=0.081, clk_wander=0.084, tai=37, leapsec=201701010000,

 

[Swistheater]

 ntpq -4 -c rv | grep jitter
mintc=3, offset=-0.562293, frequency=4.861, sys_jitter=1.784094,
clk_jitter=1.780, clk_wander=0.342

Any advice on this?

 

[EmeraldDeer]

 ntpq -4 -c rv | grep jitter
mintc=3, offset=-0.562293, frequency=4.861, sys_jitter=1.784094,
clk_jitter=1.780, clk_wander=0.342

Any advice on this?

Update or reinstall. You had 1.78 milliseconds of jitter.

 

[Centrifuge]

How long are you waiting? Leave it for a few hours at the least before checking (on some routers, I have seen 24 hours needed or more).

Waiting did the trick.

ntpq -4 -c rv | grep jitter
tc=10, mintc=3, offset=-0.869096, frequency=-5.244, sys_jitter=7.609700,
clk_jitter=0.936, clk_wander=0.087

But I'm not sure that is all going on, I wonder if my two local stratum 2 servers were reporting jitter data. They had been used for over two days with restarts and no jitter data, but today I added 0.pool.ntp.org server, and it seemed to start working after that...idk

 

[Swistheater]

Update or reinstall. You had 1.78 milliseconds of jitter.

followed the advice still have system jitter

 

[EmeraldDeer]

followed the advice still have system jitter

Now we are getting into the graphing which is beyond what I am familiar with.

Check that the files are being updated every five minutes

/jffs/scripts/ntpdstats_rrd.rrd
/tmp/var/*ext/stats*

Beyond that, perhaps @Jack Yaz could assist.

This is an RT-AC5300, right?

 

[heysoundude]

People - jitter is the overall STABILITY of the clock source; offset is how much the router's crystals drift from being in sync with that.
2msec jitter (over the internet, and it's miles of cables and wires and transfers and switches) and sub 100 usec offset correction is about as close to the center of the bullseye as you can get short of running your own atomic clock compared to simply referencing the on-board crystals in our routers, which likely have ridiculous jitter specs related to voltage and temperature.
(From what I can tell from all the posted charts, the onboard crystals have a tendency to run fast and get ahead of things, which is why they're all offset in the -ve. I'd be willing to wager anyone who is doing anything to temp control their router -even if that means simply increasing airflow through it- will have better/lower offset numbers)
If you REALLY want to get OCD, are your modem and router connected to frequency regulated pure-sine power sources of the correct mains voltage? are your mains power factor corrected? Is your mains ground as close to a zero ohm path as you can make it?
As long as jitter is reliable/predictable and as low as possible, you won't be pushing your router's offset correction circuitry too hard, ok? this is like making sure your tire pressure is correct so you don't overstress your engine/transmission, get high fuel economy and/or not wear your tires out too soon...trust the engineers know what they're doing.
this ntp add-on is an improvement over stock, an optimization of the heart and soul of your network, the router; if your network speeds up/smooths out, or the router lasts 5 yrs instead of 4, you're doing the right things on top of the framework the engineers have designed and work to maintain.

 

[EmeraldDeer]

People - jitter is the overall STABILITY of the clock source; offset is how much the router's crystals drift from being in sync with that.

@Swistheater 's issue is graphing of jitter rather than a concern about the level of jitter. The graph data is based upon the sys_jitter output from "ntpq -4 -c rv". With one source server, this is zero for whatever reason. However @Swistheater has more than one server, sys_jitter is not zero, but the graph is either zero or empty.

2msec jitter (over the internet, and it's miles of cables and wires and transfers and switches) and sub 100 usec offset correction is about as close to the center of the bullseye as you can get short of running your own atomic clock compared to simply referencing the on-board crystals in our routers, which likely have ridiculous jitter specs related to voltage and temperature.

My graph with sub millisecond offset should be disregarded for comparison. The best you can do with internet NTP servers is single digit milliseconds. I have two GPS connected NTP servers on my LAN so the offset is an order of magnitude lower. Also, I am on the development branch of ntpMerlin so the the jitter graph might be from clk_jitter instead of sys_jitter.
EDIT: It is definitely sys_jitter at the moment. clk_jitter is much lower.

 

[L&LD]

@Swistheater 's issue is graphing of jitter rather than a concern about the level of jitter. The graph data is based upon the sys_jitter output from "ntpq -4 -c rv". With one source server, this is zero for whatever reason. However @Swistheater has more than one server, sys_jitter is not zero, but the graph is either zero or empty.

My graph with sub millisecond offset should be disregarded for comparison. The best you can do with internet NTP servers is single digit milliseconds. I have two GPS connected NTP servers on my LAN so the offset is an order of magnitude lower. Also, I am on the development branch of ntpMerlin so the the jitter graph might be from clk_jitter instead of sys_jitter.

On a few different routers and ISP connections using a stratum one time server locally, the offset is much less than a few ms ranges. From a low of 60u to around 200u is what I'm seeing (+ or -, in those values).

 

[XIII]

On a few different routers and ISP connections using a stratum one time server locally

Isn't that against their Rules of Engagement?

As the load on the hosts supporting NTP primary (stratum 1) time service is heavy and always increasing, clients should avoid using the primary servers whenever possible. In most cases the accuracy of the NTP secondary (stratum 2) servers is only slightly degraded relative to the primary servers and, as a group, the secondary servers may be just as reliable. As a general rule, a secondary server should use a primary server only under the following conditions:

1. The secondary server provides synchronization to a sizable population of other servers and clients on the order of 100 or more.
2. The server operates with at least two and preferably three other secondary servers in a common synchronization subnet designed to provide reliable service, even if some servers or the lines connecting them fail.
3. The administration(s) that operates these servers coordinates other servers within the region, in order to reduce the resources required outside that region. Note that at least some interregional resources are required in order to ensure reliable service.

 

[XIII]

What's better for accurate ntp results: configure a single server, or multiple?

(How many if multiple?)

 

[visortgw]

What's better for accurate ntp results: configure a single server, or multiple?

(How many if multiple?)

From the same https://support.ntp.org/bin/view/Servers/RulesOfEngagement link referenced above:

"In order to ensure reliability, clients should operate with several different servers and avoid common points of failure. As a general rule, between three and five servers are sufficient, but they should be selected from different networks. No more than two clients per network should use the same server on another network; however, in order to simplify management of host configuration tables, many hosts on the same network may use the same (redundant) servers on the same network."​

 

[L&LD]

Isn't that against their Rules of Engagement?

I don't see how it can be? Just the router to a public time server (instead of a whole network full of devices to it).

The most accurate results are the ones that fluctuate the least. That is usually the closest and highest stratum server.

Trying to have a closer server and one or more half-way across the country or world trying to keep in sync isn't something would make the clock more accurate. I think it would be the opposite.

But, if your choice of servers are all about the same distance from you? Then more servers may give you a more accurate time. I would still be testing to see which servers were more consistent though and weed out the outliers.

 

[EmeraldDeer]

In the context of random pool servers, multiple.

And of course multiple servers are much more resilient.

How many is debatable, but three to eight is the range of opinions. If you use pool instead of or in addition to server in your ntp.conf, then you will get eight. The NTP pool code will manage adding and removing unresponsive or way off servers.

 

[XIII]

What's the fair thing to do?

Use servers from the NTP Pool Project?

 

[XIII]

I don't see how it can be?

My initial concern: Do you connect "100 or more" devices to your router? (point 1)

However, their Open Access Guidelines seem more relaxed:

The following usage guidelines apply to Open Access Time Servers unless modified by the Time Server Operator:

1. iburst may be used
2. burst may not be used
3. minpoll/maxpoll may not be changed below the defaults of 64 seconds and 1024 seconds respectively
4. Clients should honor the KOD message
5. Time Server IP addresses and/or hostnames may not be hard-coded in any hardware, firmware, or software without advance explicit written permission from the time server operator

Does "our" ntp software honor the KOD message?

 

[EmeraldDeer]

My initial concern: Do you connect "100 or more" devices to your router? (point 1)

However, their Open Access Guidelines seem more relaxed:

Does "our" ntp software honor the KOD message?

Yes, it does

 

[Swistheater]

okay so it seems to be working now after letting it run a little while.