time.google.com offset difference

[Michael Bruce]

I've recently stopped using us.pool.ntp.org as the servers that are returned vary in reliability/connectivity considerably.

Replaced it with time.google.com but have noticed that it shows a larger offset compared to other stratum 1 servers.  There have been a few times it is tagged a falseticker

# ntpq -p

     remote           refid      st t when poll reach   delay   offset    disp

==============================================================================

+india.colorado.  .NIST.           1 u  581 1024  377    39.66   -0.024    0.09

-time2.google.co  .GOOG.           1 u  812 1024  377    57.28   -4.821    0.26

-ussjc2-ntp-002.  .GPSs.           1 u  617 1024  377    19.17   -1.402    0.17

+ntp0.xxxxxxxxxxx .MRS.            1 u  301 1024  377     3.72   -0.048    0.03

+phdns2.xxxxxxxxx utcnist2.colora  2 u  366 1024  377    14.62    0.235    0.21

*ntp3.xxxxxxxxxxx .MRS.            1 u  309 1024  377     6.87   -0.060    0.55

-phdns5.xxxxxxxxx utcnist2.colora  2 u  741 1024  377    21.70   -1.418    0.72

The MRS sources are internal GPS locked timeservers

[Michael Shields]

This is most likely due to network asymmetry. Unfortunately we have
little control over this, since we can only influence the routing of
packets to you, not from you.

> --
> You received this message because you are subscribed to the Google Groups "public-ntp-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to public-ntp-disc...@googlegroups.com.
> To post to this group, send email to public-nt...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/public-ntp-discuss/d472ba4a-dd81-4c65-90fe-3e2057bfe8e2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alexander Dupuy]

Wouldn't the smeared leap seconds from time.google.com cause much larger offsets (and trigger falseticker detection) around the leap seconds if you are also using NTP sources without smeared leap seconds? I would have thought this was an unsupported configuration.

To view this discussion on the web visit https://groups.google.com/d/msgid/public-ntp-discuss/CALvMCHJvw%2BMwdNc5ENv7A-EVeKiWkRxYsxv4zGSJNTxA1RWiWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alexander Dupuy |

Software Engineer |

alex...@google.com |

+1 646-462-3568

[Jamie Wilkinson]

In this example, it is quite probable that time2.google.com will get marked as a falseticker during the next leapsecond, because it'll be off by up to 0.5 of a second in the middle of the smear (i.e right around midnight UTC.)  Exactly how falseticky it is depends on the parameters of the whole group, though.

If you run with a majority of smearing peers then I'd expect that the nonsmearing peers get marked as falsetickers because they'd be in the minority group, differing in frequency ever so slightly.

This configuration is documented as unsupported because of the nondeterminism here making it hard to predict what will happen, and nondeterministic behaviour in time dissemination rightly makes people uneasy.  I wouldn't do it on a production network, but I run a mix of smear and nonsmear peers at home just to observe what happens.

Depending on Michaels' requirements, having one peer go on a short excursion one day every few years and be excluded from the selection algorithm might be totally acceptable.  Given the adverse conditions on the Internet ("servers vary in reliability/connectivity") already impacting the error bounds that seems like a low risk to me (but I don't have all the details of the setup, YMMV, this email may contain broad forward looking statements, is not financial advice, etc).

To view this discussion on the web visit https://groups.google.com/d/msgid/public-ntp-discuss/CAFdvYXf_BwMGSMg5LoMWtJ2Gd574emMQt%2Bge_KV%3DbdMAqxDkHw%40mail.gmail.com.

[Jamie Wilkinson]

I'm curious if it's consistently off by that much or if the offset changes over time.  You can turn on peerstats logging in ntpd to log the peer statistics on each packet exchange:

http://www.ntp.org/ntpfaq/NTP-s-trouble.htm

[Michael Bruce]

I'm aware of the leap smear issue, but since no leap seconds are scheduled anytime soon, I'm testing stratum 1 servers to use.

Will likely use smeared seconds when the next leap second occurs.

On Monday, September 10, 2018 at 9:07:59 PM UTC-7, Alex Dupuy wrote:

Wouldn't the smeared leap seconds from time.google.com cause much larger offsets (and trigger falseticker detection) around the leap seconds if you are also using NTP sources without smeared leap seconds? I would have thought this was an unsupported configuration.

On Mon, Sep 10, 2018 at 6:24 PM 'Michael Shields' via public-ntp-discuss <public-nt...@googlegroups.com> wrote:

This is most likely due to network asymmetry.  Unfortunately we have
little control over this, since we can only influence the routing of
packets to you, not from you.
On Mon, Sep 10, 2018 at 1:35 PM Michael Bruce <msb...@gmail.com> wrote:
>
> I've recently stopped using us.pool.ntp.org as the servers that are returned vary in reliability/connectivity considerably.
>
> Replaced it with time.google.com but have noticed that it shows a larger offset compared to other stratum 1 servers.  There have been a few times it is tagged a falseticker
>
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset    disp
> ==============================================================================
> +india.colorado.  .NIST.           1 u  581 1024  377    39.66   -0.024    0.09
> -time2.google.co  .GOOG.           1 u  812 1024  377    57.28   -4.821    0.26
> -ussjc2-ntp-002.  .GPSs.           1 u  617 1024  377    19.17   -1.402    0.17
> +ntp0.xxxxxxxxxxx .MRS.            1 u  301 1024  377     3.72   -0.048    0.03
> +phdns2.xxxxxxxxx utcnist2.colora  2 u  366 1024  377    14.62    0.235    0.21
> *ntp3.xxxxxxxxxxx .MRS.            1 u  309 1024  377     6.87   -0.060    0.55
> -phdns5.xxxxxxxxx utcnist2.colora  2 u  741 1024  377    21.70   -1.418    0.72
>
> The MRS sources are internal GPS locked timeservers
>
>
> --
> You received this message because you are subscribed to the Google Groups "public-ntp-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to public-ntp-discuss+unsub...@googlegroups.com.

> To post to this group, send email to public-nt...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/public-ntp-discuss/d472ba4a-dd81-4c65-90fe-3e2057bfe8e2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "public-ntp-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to public-ntp-discuss+unsub...@googlegroups.com.

To post to this group, send email to public-nt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/public-ntp-discuss/CALvMCHJvw%2BMwdNc5ENv7A-EVeKiWkRxYsxv4zGSJNTxA1RWiWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Bruce]

Yes, it seems very consistent for the offset.  The dispersion is very very low, so it seems to be very reliable other than the offset.

On Monday, September 10, 2018 at 10:19:04 PM UTC-7, Jamie Wilkinson wrote:

I'm curious if it's consistently off by that much or if the offset changes over time.  You can turn on peerstats logging in ntpd to log the peer statistics on each packet exchange:

http://www.ntp.org/ntpfaq/NTP-s-trouble.htm

On Tue, 11 Sep 2018 at 06:35, Michael Bruce <msb...@gmail.com> wrote:

I've recently stopped using us.pool.ntp.org as the servers that are returned vary in reliability/connectivity considerably.

Replaced it with time.google.com but have noticed that it shows a larger offset compared to other stratum 1 servers.  There have been a few times it is tagged a falseticker

# ntpq -p

     remote           refid      st t when poll reach   delay   offset    disp

==============================================================================

+india.colorado.  .NIST.           1 u  581 1024  377    39.66   -0.024    0.09

-time2.google.co  .GOOG.           1 u  812 1024  377    57.28   -4.821    0.26

-ussjc2-ntp-002.  .GPSs.           1 u  617 1024  377    19.17   -1.402    0.17

+ntp0.xxxxxxxxxxx .MRS.            1 u  301 1024  377     3.72   -0.048    0.03

+phdns2.xxxxxxxxx utcnist2.colora  2 u  366 1024  377    14.62    0.235    0.21

*ntp3.xxxxxxxxxxx .MRS.            1 u  309 1024  377     6.87   -0.060    0.55

-phdns5.xxxxxxxxx utcnist2.colora  2 u  741 1024  377    21.70   -1.418    0.72

The MRS sources are internal GPS locked timeservers

--
You received this message because you are subscribed to the Google Groups "public-ntp-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to public-ntp-discuss+unsub...@googlegroups.com.

[Michael Shields]

It would also be reasonable to use both smearing and non-smearing servers most of the time, since their behavior is the same outside a smear window, with the plan to disable one group or the other before an actual smear happens.

[Michael Bruce]

Just an FYI, thought I'd track all four time.google.com servers.  While time1 and time2 have smaller delay, time3 and time4 present better time

     remote           refid      st t when poll reach   delay   offset    disp

==============================================================================

-time-b-g.nist.g .NIST.           1 u   86  256  377    80.29    0.880    0.05

-time1.google.co .GOOG.           1 u  389 1024  377    57.07   -3.956    0.66

-time2.google.co .GOOG.           1 u  396 1024  377    57.19   -3.898    0.11

+time3.google.co .GOOG.           1 u   74  128  377   146.79    0.352    0.17

+time4.google.co .GOOG.           1 u   92  128  377   135.76    0.232    0.29