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!

The poll times start off around 6 but then seem to drift to 10, is there somewhere I can edit this?
in the .conf file
You'll need to spend some time with the manual for chrony...scroll through posts looking for link to it
 
that'll tighten things up significantly on your network...a lot can happen in a million or so nanoseconds ;-p
Make sure* people aren't being misled on the actual benefits of accurate timekeeping.
A nice stable clock will help with timestamping of events occurring on your network, but it will provide no benefit to the routing or QoS performance of the router itself. NTP is for maintaining accurate time-of-day information, and determining sequence of events across systems which maintain separate clocks, and not for measuring packet latency or switching delays within the router itself.
 
Last edited:
I’m a maths/physics kind of person and I find it entirely logical that the more accurate your timestamped packets are, the better performance in real time for gaming. There doesn’t seem to be much research/studies done on this subject as that’s not what NTP was intended for.

But in gaming, where every ms counts, I seem to have found very tangible benefits from the improvement in my time stamping. 2 nights running I’ve had a much improved experience with online multiplayer gaming, particularly hit marker registration.
I’d be interested to hear other opinions on the matter as always.
 
I’m a maths/physics kind of person and I find it entirely logical that the more accurate your timestamped packets are, the better performance in real time for gaming. There doesn’t seem to be much research/studies done on this subject as that’s not what NTP was intended for.
To put it another way. Assume your router's clock drift is 10ppm, and your average packet RTT is 100ms.

Even if the NTP algorithm was capable of making that fine of an adjustment, you are talking a difference of 1µs. (Though I am no expert in the internal workings of chronyd or ntpd, so not sure how the slewing algorithm works on each clock tick)
But a time variance of 1µs over that 100ms is really going to make no difference to your router's packet handling.
 
I'm no expert in the inner workings of ntpd or chronyd either - but I respectfully disagree @Wade Coxon:

The more we subdivide (the faster we want to pass a bit through space, speed being throughput over time), the better defined the time that bit occupies has to be

for ease of math, lets say we have a "1Gbps-capable" connection - one BILLION bits per second. that means this connection can pass one bit per nanosecond (a billionth of a second).
a bit is a bit, either a 1 or zero, electrons pass or they don't...if the space that bit occupies is a bit small (1,000,000,001 bits per second) or a bit roomy (999,999,999 bits per second), the processor on the other end has to think about how that odd stream of bits is different compared to how it operates...and now it can't operate at its optimum "speed"

that's just talking router to an upstream server. by broadcasting that time reference to every device on our LAN, every device following it will transmit and receive data based on that time reference, reducing (or hopefully eliminating) as many (cumulative!) errors between "here" and "there" as possible...that one bit here and/or there adds up at every hop/waypoint on the path - in BOTH directions.
 
Had not known that multiple pool statements are supported by chrony, so I tried the most common ones.
Here are my settings.
Code:
allow 192.168.50.0/24
driftfile /opt/var/lib/chrony/drift
dumpdir /opt/var/lib/chrony
dumponexit
lock_all
logchange 0.1
makestep 1.0 3
pidfile /opt/var/run/chrony/chronyd.pid
pool time.apple.com
pool time.cloudflare.com
pool time.facebook.com
pool time.google.com
pool time.nist.gov
pool time.windows.com
server 192.168.50.230 iburst minpoll 3 maxpoll 3 xleave
Here are the results after a day. I have a GPS connected NTP server on my LAN. From suburban Boston, Apple appears to be the winner. I have no idea how Windows can have consistently accurate offsets with such high standard deviations.
Code:
===============================================================================
Reference ID    : C0A832E6 (LeoNTP)
Stratum         : 2
Ref time (UTC)  : Wed Feb 10 20:14:58 2021
System time     : 0.000003385 seconds fast of NTP time
Last offset     : +0.000005048 seconds
RMS offset      : 0.000036477 seconds
Frequency       : 4.940 ppm slow
Residual freq   : +0.236 ppm
Skew            : 1.167 ppm
Root delay      : 0.000601320 seconds
Root dispersion : 0.000024176 seconds
Update interval : 8.0 seconds
Leap status     : Normal
===============================================================================
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* LeoNTP                        1   3   377     4  +6959ns[  +12us] +/-  301us
^- usqas2-ntp-001.aaplimg.c>     1   9   377   686  -1617us[-1645us] +/- 9045us
^- usnyc3-ntp-004.aaplimg.c>     1   9   377   201  -2310us[-2306us] +/- 6868us
^- usnyc3-ntp-003.aaplimg.c>     1  10   377   513  -2397us[-2415us] +/- 7071us
^- usnyc3-ntp-002.aaplimg.c>     1   9   377   650  -2912us[-2945us] +/- 7583us
^- time.cloudflare.com           3  10   377   411  -2346us[-2364us] +/-   12ms
^- time.cloudflare.com           3  10   377   785  -1786us[-1819us] +/-   11ms
^- time.cloudflare.com           3  10   377   779  -2148us[-2191us] +/-   12ms
^- time.cloudflare.com           3  10   377   849  -1751us[-1725us] +/-   11ms
^- time5.facebook.com            1  10   377   284  -2282us[-2288us] +/-   23ms
^- time4.facebook.com            1  10   377    94  -3536us[-3518us] +/- 5241us
^- time4.facebook.com            1  10   377   791  -2440us[-2462us] +/- 4145us
^- time1.facebook.com            1  10   377   749  -4226us[-4266us] +/-   17ms
^- time3.google.com              1  10   377   108  -2336us[-2318us] +/-   13ms
^- time2.google.com              1  10   377   528  -2580us[-2598us] +/-   17ms
^- time1.google.com              1  10   377   726  -2122us[-2160us] +/-   17ms
^- time4.google.com              1  10   377   393  -2321us[-2335us] +/-   13ms
^- time-d-b.nist.gov             1  10   377   635  -1738us[-1773us] +/-   28ms
^- time-d-b.nist.gov             1  10   377   185  -2117us[-2109us] +/-   28ms
^- time-d-g.nist.gov             1  10   377   777  -1940us[-1984us] +/-   11ms
^- time-a-wwv.nist.gov           1  10   377   613  -2367us[-2395us] +/-   29ms
^- 40.119.6.228                  3  10   377   321    -72us[  -76us] +/-   64ms
^- 13.86.101.172                 3  10   377   507   +179us[ +162us] +/-   54ms
==============================================================================
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
LeoNTP                      7   5    48     +0.236      2.699  +1159ns    16us
usqas2-ntp-001.aaplimg.c>  16   9  138m     -0.128      0.030  -1492us    75us
usnyc3-ntp-004.aaplimg.c>   9   5  111m     -0.130      0.044  -2061us    53us
usnyc3-ntp-003.aaplimg.c>   6   3   85m     -0.145      0.071  -1901us    29us
usnyc3-ntp-002.aaplimg.c>   6   3   51m     -0.215      0.246  -2213us    45us
time.cloudflare.com         7   3  103m     -0.161      0.294  -2252us   221us
time.cloudflare.com        13   8  224m     -0.132      0.046  -1447us   154us
time.cloudflare.com         9   7  137m     -0.160      0.078  -1565us    98us
time.cloudflare.com         8   6  120m     -0.159      0.081  -1742us    87us
time5.facebook.com         14   8  223m     -0.125      0.036  -1694us   123us
time4.facebook.com         15   9  241m     -0.112      0.034  -2256us   148us
time4.facebook.com         15   9  293m     -0.087      0.061  -1743us   277us
time1.facebook.com         12   7  163m     -0.121      0.213  -2328us   420us
time3.google.com           10   6  155m     -0.126      0.185  -2065us   324us
time2.google.com           15   8  198m     -0.131      0.012  -1580us    38us
time1.google.com           10   5  120m     -0.123      0.033  -1903us    42us
time4.google.com           13  11  207m     -0.142      0.029  -1641us    96us
time-d-b.nist.gov           8   5  120m     -0.183      0.163  -1657us   178us
time-d-b.nist.gov          12   7  189m     -0.126      0.021  -1671us    57us
time-d-g.nist.gov           8   5  120m     -0.125      0.052  -1904us    59us
time-a-wwv.nist.gov        16   8  129m     -0.132      0.083  -1359us   205us
40.119.6.228                9   5  137m     -0.125      0.199   +146us   295us
13.86.101.172              11   5  172m     -0.226      0.181   -212us   413us
==============================================================================
Wed Feb 10 15:15:05 EST 2021
 15:15:05 up 24 days,  2:31,  load average: 2.01, 1.95, 1.96
==============================================================================
 
explain, then, please. something in each router has to be the final arbiter for everything else...
The bus and CPU clocks control very low level movement of bits around the system. The NIC will have its own clocks derived from that to manage outbound communications. These are all clocks as in CLK which you see annotated on circuit diagrams. They just "tick" to ensure that low level operations happen in a sequence.

The system clock, which is what is influenced by NTP, is a literal clock that tells time (like the one you have hanging on the wall).
This clock is used when a timestamp is placed on an item like a whole packet or a file that is written to your harddisk.
 
On the topic of NTP servers, do not mix servers which smear leap seconds with servers that do not smear leap seconds.
In my case, I have commented out Facebook and Google NTP servers which smear leap seconds.
My GPS-connected NTP server, Apple, Cloudflare, NIST and Microsoft do not smear leap seconds as far as I know.
Code:
server 192.168.50.230 iburst minpoll 3 maxpoll 3 xleave
pool time.apple.com
pool time.cloudflare.com
!pool time.facebook.com
!pool time.google.com
pool time.nist.gov
pool time.windows.com
 
On the topic of NTP servers, do not mix servers which smear leap seconds with servers that do not smear leap seconds.
In my case, I have commented out Facebook and Google NTP servers which smear leap seconds.
My GPS-connected NTP server, Apple, Cloudflare, NIST and Microsoft do not smear leap seconds as far as I know.
Code:
server 192.168.50.230 iburst minpoll 3 maxpoll 3 xleave
pool time.apple.com
pool time.cloudflare.com
!pool time.facebook.com
!pool time.google.com
pool time.nist.gov
pool time.windows.com
Interesting. Are you running ntpd or chronyd on your local server?
It somewhat looks like servers switching to chrony tend to smear.
 
Interesting. Are you running ntpd or chronyd on your local server?
It somewhat looks like servers switching to chrony tend to smear.
When I refer to smearing, I mean the avoidance of default leap second behavior when a second is added to UTC by adjusting the speed of the clock. Most folks would consider this an esoteric topic because the last leap second was in 2017.
The server on my LAN is NTP. It is a LeoNTP which is GPS connected with NTP implemented in firmware.
The router is running chrony.
I prefer not to use smearing.
If you prefer to use smearing, then you can use Facebook and Google NTP pools and configure your chrony daemon to use smearing.
Code:
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponly
Chrony does not require a leap second configuration file but NTP does. Here is the current one.
Code:
#    ATOMIC TIME.
#    The Coordinated Universal Time (UTC) is the reference time scale derived 
#    from The "Temps Atomique International" (TAI) calculated by the Bureau 
#    International des Poids et Mesures (BIPM) using a worldwide network of atomic 
#    clocks. UTC differs from TAI by an integer number of seconds; it is the basis 
#    of all activities in the world. 
#
#
#    ASTRONOMICAL TIME (UT1) is the time scale based on the rate of rotation of the earth. 
#    It is now mainly derived from Very Long Baseline Interferometry (VLBI). The various 
#    irregular fluctuations progressively detected in the rotation rate of the Earth lead 
#    in 1972 to the replacement of UT1 by UTC as the reference time scale. 
#
#
#    LEAP SECOND
#    Atomic clocks are more stable than the rate of the earth rotation since the latter 
#    undergoes a full range of geophysical perturbations at various time scales: lunisolar 
#    and core-mantle torques, atmospheric and oceanic effetcs, etc.
#    Leap seconds are needed to keep the two time scales in agreement, i.e. UT1-UTC smaller 
#    than 0.9 second. Therefore, when necessary a "leap second" is applied to UTC.
#    Since the adoption of this system in 1972 it has been necessary to add a number of seconds to UTC, 
#    firstly due to the initial choice of the value of the second (1/86400 mean solar day of 
#    the year 1820) and secondly to the general slowing down of the Earth's rotation. It is 
#    theorically possible to have a negative leap second (a second removed from UTC), but so far, 
#    all leap seconds have been positive (a second has been added to UTC). Based on what we know about  
#    the earth's rotation, it is unlikely that we will ever have a negative leap second.
#
#
#    HISTORY
#    The first leap second was added on June 30, 1972. Until yhe year 2000, it was necessary in average to add a 
#       leap second at a rate of 1 to 2 years. Since the year 2000 leap seconds are introduced with an
#    average interval of 3 to 4 years due to the acceleration of the Earth rotation speed.
#
#
#    RESPONSABILITY OF THE DECISION TO INTRODUCE A LEAP SECOND IN UTC
#    The decision to introduce a leap second in UTC is the responsibility of the Earth Orientation Center of 
#    the International Earth Rotation and reference System Service (IERS). This center is located at Paris 
#    Observatory. According to international agreements, leap seconds should only be scheduled for certain dates:
#    first preference is given to the end of December and June, and second preference at the end of March 
#    and September. Since the introduction of leap seconds in 1972, only dates in June and December were used.
#
#        Questions or comments to:
#            Christian Bizouard:  christian.bizouard@obspm.fr
#            Earth orientation Center of the IERS
#            Paris Observatory, France    
#            
#
#
#
#    VALIDITY OF THE FILE
#    It is important to express the validity of the file. These next two dates are
#    given in units of seconds since 1900.0.
#
#    1) Last update of the file. 
#
#    Updated through IERS Bulletin C (ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
#
#    The following line shows the last update of this file in NTP timestamp: 
#
#$    3819011916 
#     
#    2) Expiration date of the file given on a semi-annual basis: last June or last December
#
#    File expires on 28 December 2021
#
#    Expire date in NTP timestamp: 
#
#@    3849638400
#
#
#    LIST OF LEAP SECONDS
#    NTP timestamp (X parameter) is the number of seconds since 1900.0
#
#    MJD: The Modified Julian Day number. MJD = X/86400 + 15020
#
#    DTAI: The difference DTAI= TAI-UTC in units of seconds
#    It is the quantity to add to UTC to get the time in TAI
#
#    Day Month Year : epoch in clear
#
#NTP Time      DTAI    Day Month Year
#
2272060800      10      # 1 Jan 1972
2287785600      11      # 1 Jul 1972
2303683200      12      # 1 Jan 1973
2335219200      13      # 1 Jan 1974
2366755200      14      # 1 Jan 1975
2398291200      15      # 1 Jan 1976
2429913600      16      # 1 Jan 1977
2461449600      17      # 1 Jan 1978
2492985600      18      # 1 Jan 1979
2524521600      19      # 1 Jan 1980
2571782400      20      # 1 Jul 1981
2603318400      21      # 1 Jul 1982
2634854400      22      # 1 Jul 1983
2698012800      23      # 1 Jul 1985
2776982400      24      # 1 Jan 1988
2840140800      25      # 1 Jan 1990
2871676800      26      # 1 Jan 1991
2918937600      27      # 1 Jul 1992
2950473600      28      # 1 Jul 1993
2982009600      29      # 1 Jul 1994
3029443200      30      # 1 Jan 1996
3076704000      31      # 1 Jul 1997
3124137600      32      # 1 Jan 1999
3345062400      33      # 1 Jan 2006
3439756800      34      # 1 Jan 2009
3550089600      35      # 1 Jul 2012
3644697600      36      # 1 Jul 2015
3692217600      37      # 1 Jan 2017
#
#    A hash code has been generated to be able to verify the integrity
#    of this file. For more information about using this hash code,
#    see the README file in the 'sources' directory.
#
#h    89073fa8 9e913fd7 60559aa5 29d1feee 5b0f6c91
 
Thank you. (edits above are my own; the "inconceivable" attitude is what I feel we're brushing up against)
I don't know about you, but I'd like a better picture as to why the RTC wouldn't defer to an IP-referencing NTP source that's indisputably more accurate, and why that wouldnt affect everything that relies on timing in a positive way

The main documented benefit of an accurate computer clock is for security purposes.

There is no documented or proven impact to first-person shooters "hit box registration" due to a slightly out-of-sync computer clock.

Remember folks, it's always good to look for scientific sources when it comes to proving things like this.
If we want to throw science out the window, then we might as well inject ourselves with Lysol to prevent covid, like a certain former president wanted everyone to do.
 
I stated previoiusly it may be a co-incidence and am a maths and science person. I don't go off whims, but look for proof to underline things I find.

One thing is for certain, I've gone from +/- 1.5ms to less than +/- 0.1ms... I've found better performance outside of things that have been mentioned, which may be entirely a co-incidence. I'm happy to be presented with facts and evidence to support or otherwise, over hysterical responses.
 

Attachments

  • Screenshot 2021-02-13 at 21.25.49.png
    Screenshot 2021-02-13 at 21.25.49.png
    66 KB · Views: 128
  • Screenshot 2021-02-13 at 21.26.03.png
    Screenshot 2021-02-13 at 21.26.03.png
    70.9 KB · Views: 106
I stated previoiusly it may be a co-incidence and am a maths and science person. I don't go off whims, but look for proof to underline things I find.

One thing is for certain, I've gone from +/- 1.5ms to less than +/- 0.1ms... I've found better performance outside of things that have been mentioned, which may be entirely a co-incidence. I'm happy to be presented with facts and evidence to support or otherwise, over hysterical responses.
car people call it a "butt dyno" as in "it feels quicker/more powerful from the driver's seat"...until it can be documented, its all feel. <thumbs up>
 
Does "believing the science" include making up fake statements that never happened?
 
What are you referring to?
The conversation I was trying to expand, but Jack asked a mod to prune it away to keep this thread on-topic.
I'll edit mine if Wade et al will edit theirs...Jack's right and it deserves a thread of its own
 

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