It depends.  Mostly on the routing between you and NIST.  If you are closer,
the routing is more likely to be symmetric.

From my experience, routing is generally stable on the scale of months.  There
are short (hours) changes when a fiber gets cut or a router gets busted.
There are long term changes as people add fibers and/or change business deals.

There are some cases where a stable routing will produce 2 answers: x% of the
packets will be slightly faster/slower than most of them.  I think what's
going on is that the routers are doing load sharing on multiple paths, hashing
on the address+port.  Or something like that.  So it's a roll of the dice
which path you get.

I'm in California.

NIST has NTP servers at 3 locations in the Boulder CO area: NIST, WWV, and
Univ of Colorado.  (Google maps says WWV is 60 miles north of Bouler.  Univ of
Colorado is a few miles from NIST.)

From a cheap cloud server (Digital Ocean) in San Francisco, the RTT to NIST is
31.5 ms, to WWV is 32.1 ms, to Univ of Colorado is 54.5 ms.  The time offsets
are about 1 ms for NIST and WWV and 12 ms for Univ of Colorado.

From my home (AT&T via Sonic), 30 miles south of San Francisco, the RTTs are
61 ms for NIST and WWV and 81-82 for Univ of Colorado.  Offsets are 6-7 ms for
NIST and WWV and 4-5 ms in the other direction for Univ of Colorado.

--
These are my opinions.  I hate spam.

On 12/14/21 5:23 PM, Hal Murray wrote:

Might be a localized routing phenomenon.  Using my verizon connection from
Northern Virginia the results are awful for time-e-g.nist.gov:

  remote           refid      st t when poll reach   delay   offset  jitter

---============
-192.168.1.219  68.69.221.61    2 u  56  64  377    0.400  -0.290  0.035
*192.168.1.224  .PPS.            1 u    1  16  377    0.184    0.087  0.017
-129.6.15.26    .NIST.          1 u  32  64  377  93.087  -37.940  7.867

However from my AWS machine in Oregon:

MS Name/IP address        Stratum Poll Reach LastRx Last sample

---=============
^- 152.63.13.177                3  6  377    63  -2011us[-2011us] +/-  128ms
^+ 209.182.153.6                2  7  377    65  -959us[ -959us] +/-  86ms
^- 64.139.66.105                3  6  377  128  -5838us[-5838us] +/-  134ms
^+ 129.6.15.26                  1  6  377    64  -2075us[-2075us] +/-  37ms
^* 173.66.105.50                1  8  377  438  -448us[ -870us] +/-  38ms

-mike

Yeah I think it is localized. Network paths have been quite variable for
me. Every once in a while I start getting massive delays from the NIST
servers to my system, resulting in results like yours.

Interestingly though, time-e-g was one of the only servers that didn't have
this problem for me. This is a recent wedge plot for it. seems to be
working fine for me now, just with a variable outgoing delay causing
positive offsets, which seems to be more of a problem with my connection
than anything else.

On Tue, Dec 14, 2021 at 9:04 PM K5ROE Mike K5ROE@roetto.org wrote:

From the point of view of my local probers, it's transmit to time-e-b.nist
that's flaky.

[image: Screenshot 2021-12-15 at 16.41.04.png]

On Wed, Dec 15, 2021 at 4:32 PM Adam Space time.isanapp@gmail.com wrote:

--
Michael Rothwell
michael@rothwell.us
(828) 649-ROTH

Hi,

Expect network routes to be more dispersed these days, as it is needed.

While the wedge plot is a classic for NTP, it may be interesting to plot
forward and backward path histograms independently.

Cheers,
Magnus

On 2021-12-15 16:25, Adam Space wrote:

On 12/15/21 7:53 AM, Magnus Danielson via time-nuts wrote:

I assume someone, somewhere has run some recent tests and maybe
published them. All those plots and behaviors from the early days of NTP
might have significantly changed, due to the plethora of new kinds of
network routes.  Two things strike me as being "very different" from,
say, 10-20 years ago - 20 years ago, most routers were "store and
forward" - the entire packet would be received, and then decoded, and
sent onward.  These days, many routers start sending the packet to the
destination before the entire packet has been received.  To do S&F would
take too much memory with multi Gbps speeds and long packets.  I recall
being at a conference at least 10 years ago where they were talking
about the sophistication required in 10G routers - cut through routing,
adaptive equalization, etc.

The other thing that has changed is a modern diversity of kinds of
networks. 20 years ago, it was basically wired connections of some kind
with concentrators/deconcentrators/switches/routers - all of which have
moderately well defined latency and statistics.

Now, though, there's a lot of over the air (cell phones, WISP, 5,6,7G
nanocells injected surreptitiously - at least my neighbor claims that's
what they're doing).  The latency on a WiFi connection, in a busy
environment - It's 8PM, and all the neighbors are streaming "The Wheel
of Time" (appropriately, for time-nuts) - varies wildly over a short
time. (I will say that WiFi latency improves dramatically during a power
failure in a residential neighborhood when you have backup power, and
your neighbors do not)

Imagine NTP running over Starlink, especially when there are multi hop
crosslinks between satellites.  At 7 km/s orbital velocity, the range is
changing as much as 21 microseconds/second to a "stationary" observer. 
Now consider two satellites in different orbital planes. The dynamics of
the latency get quite complex.

On 12/15/21 7:53 AM, Magnus Danielson via time-nuts wrote:

I assume someone, somewhere has run some recent tests and maybe
published them. All those plots and behaviors from the early days of NTP
might have significantly changed, due to the plethora of new kinds of
network routes.  Two things strike me as being "very different" from,
say, 10-20 years ago - 20 years ago, most routers were "store and
forward" - the entire packet would be received, and then decoded, and
sent onward.  These days, many routers start sending the packet to the
destination before the entire packet has been received.  To do S&F would
take too much memory with multi Gbps speeds and long packets.  I recall
being at a conference at least 10 years ago where they were talking
about the sophistication required in 10G routers - cut through routing,
adaptive equalization, etc.

The other thing that has changed is a modern diversity of kinds of
networks. 20 years ago, it was basically wired connections of some kind
with concentrators/deconcentrators/switches/routers - all of which have
moderately well defined latency and statistics.

Now, though, there's a lot of over the air (cell phones, WISP, 5,6,7G
nanocells injected surreptitiously - at least my neighbor claims that's
what they're doing).  The latency on a WiFi connection, in a busy
environment - It's 8PM, and all the neighbors are streaming "The Wheel
of Time" (appropriately, for time-nuts) - varies wildly over a short
time. (I will say that WiFi latency improves dramatically during a power
failure in a residential neighborhood when you have backup power, and
your neighbors do not)

Imagine NTP running over Starlink, especially when there are multi hop
crosslinks between satellites.  At 7 km/s orbital velocity, the range is
changing as much as 21 microseconds/second to a "stationary" observer. 
Now consider two satellites in different orbital planes. The dynamics of
the latency get quite complex.

Good idea. Doing so reveals the expected outcome from the wedge plot:
variable forward path delay, shifted in the positive direction, and a
pretty stable negative path delay. Is this the norm for consumer grade
connection? It seems to be for me.

On Wed, Dec 15, 2021 at 10:53 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:

Hi

One really big thing that has changed is the number of folks doing this
sort of thing via a dsl or cable modem that has > 20 ms of asymmetry.
You will not find many NTP papers studying that sort of network connection.

Bob

In modern IP/MPLS routing, forward and backward paths is indivudally
routed and becomes re-routed do spread traffic load or overcome loss of
links. Analyzing it makes much more sense in this form. You can draw the
same conclusion from the wedge-plot of TE vs RTT, but it may be less
clear, so shift plot-form to match the problem.

At ITSF 2021 GMV had a presentation where they used NTP based on Chrony
between two RPis which had good GNSS timing on both ends between two FTH
accesses. They showed significant noise and asymmetry. In parallel they
where using a different equipment which was able to chew way into the
noise, and see other variations.

Cheers,
Magnus

On 2021-12-15 17:43, Adam Space wrote: