[time-nuts] Re: NIST NTP servers way off for anyone else?

[Adam Space]

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 at lists.febo.com> wrote:

> 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:
> > 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 at roetto.org> wrote:
> >
> >> On 12/14/21 5:23 PM, Hal Murray wrote:
> >>>> Out of curiosity, since you monitor NIST Gaithersburg, if you were to
> >> average
> >>>> over the offsets for a whole month, what kind of value would you get?
> >> Surely
> >>>> it is close to zero but I am curious how close. Within 1ms?
> >>> 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.
> >>>
> >>>
> >> 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
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send
> >> an email to time-nuts-leave at lists.febo.com
> >> To unsubscribe, go to and follow the instructions there.
> >>
> >>
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send an email to time-nuts-leave at lists.febo.com
> >> To unsubscribe, go to and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delay_hists.png
Type: image/png
Size: 29771 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20211215/2e47e224/attachment.png>