[LEAPSECS] Another vote on UTC, facebook

[Michael Rothwell]

On Thu, Mar 19, 2020 at 4:38 PM Judah Levine via LEAPSECS <
leapsecs at leapsecond.com> wrote:

> There are troubling aspects about the facebook method:
>
> 1. The time *accuracy* of a client system that uses a public network
> connection to any time server will be limited by the asymmetry in the
> inbound-outbound network delays. The end-point application cannot
> improve on this, and hardware time-stamping by the client will not help.
> (A client with a local primary reference, such as a local GPS receiver,
> is a different matter.)
>
> 2. The time *stability* of a client system that uses a public network
> connection can be improved by hardware time-stamps and by rather
> complicated statistics. (There are a lot of my papers on the NIST web
> page at tf.nist.gov that discuss this question.)
>
> It is important to distinguish between these two parameters.
>
> 3. The time to synchronize the clock on a client system following a cold
> start is often faster with Chrony, but this is a trade-off against
> increased sensitivity to false-tickers (servers transmitting the wrong
> time with no indication). The shorter synchronization time is likely to
> be particularly troublesome on networks with unstable delays. Your
> mileage may vary.
>
> 4. The facebook method of applying the smear *after* the leap second is
> the most troubling aspect of the process. It is not consistent with the
> definition of UTC or with the other smear methods that apply the smear
> before the leap second. The question of whether smear methods are "good
> enough" has no absolute answer. They are very definitely *NOT* good
> enough to satisfy the European rules for time-stamp accuracy of
> financial transactions, and these rules are likely to be adopted by the
> regulators in the US in the foreseeable future.


Fringe use-case, and I doubt any financial institutions will be using
Facebook Time Service.


> A client system that
> sends requests to servers with different smearing algorithms will be
> really confused in the vicinity of a leap second. In the worst case, the
> client may reject all of the replies as requiring a time-step that
> exceeds some maximum threshold, such as 128 milliseconds.
>
> 5. If your application requires time stamps that are legally traceable
> to national or international standards or if it depends on international
> time coordination, then you should seek competent advice. Your mileage
> is guaranteed to vary.
>
> Judah Levine
> Time and Frequency Division
> NIST Boulder
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>


-- 
Michael Rothwell
michael at rothwell.us
(828) 649-ROTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200319/faf3ae5e/attachment.html>