heysoundude
Part of the Furniture
in the .conf file
You'll need to spend some time with the manual for chrony...scroll through posts looking for link to it
ntpMerlin ntpMerlin v3.x
- Thread starter Jack Yaz
- Start date
You'll need to spend some time with the manual for chrony...scroll through posts looking for link to it
Wade Coxon
Senior Member
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.
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.
Wade Coxon
Senior Member
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.
heysoundude
Part of the Furniture
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.
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.
EmeraldDeer
Very Senior Member
Had not known that multiple pool statements are supported by chrony, so I tried the most common ones.
Here are my settings.
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.
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
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
==============================================================================Wade Coxon
Senior Member
The router's system clock has absolutely no impact on that level of the router's operation.
Don't confuse the system clock with the bus or CPU clocks, these are entirely different things.
Wade Coxon
Senior Member
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.
EmeraldDeer
Very Senior Member
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.
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
JGrana
Very Senior Member
Interesting. Are you running ntpd or chronyd on your local server?
It somewhat looks like servers switching to chrony tend to smear.
EmeraldDeer
Very Senior Member
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
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 5b0f6c91The 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.
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
heysoundude
Part of the Furniture
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>
bluzfanmr1
Senior Member
Does "believing the science" include making up fake statements that never happened?
What are you referring to?
heysoundude
Part of the Furniture
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
I'll take the high road as long as someone else does first.
Similar threads
Similar threads
| Thread starter | Title | Forum | Replies | Date |
|---|---|---|---|---|
| W | ntpMerlin ntpMerlin and timeserverd ntp_ready tests | Asuswrt-Merlin AddOns | 1 | |
| D | NTPmerlin config log not found | Asuswrt-Merlin AddOns | 2 | |
| A | ntpMerlin Problems with ntpMerlin | Asuswrt-Merlin AddOns | 9 |
Similar threads
-
ntpMerlin ntpMerlin and timeserverd ntp_ready tests
- Started by Wyehoota
- Replies: 1
-
-
Latest threads
-
I want to learn and would appreciate some help.
- Started by Currently Studying
- Replies: 0
-
-
-
-
Issue with selective VPN Routing on ASUS GS-AX3000 (WireGuard & VPN Fusion)
- Started by BerkayDrsn
- Replies: 2
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!