On Thu, Mar 19, 2020 at 4:38 PM Judah Levine via LEAPSECS < leapsecs@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@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs > -- Michael Rothwell mich...@rothwell.us (828) 649-ROTH
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs