[LEAPSECS] Bloomberg announced its smear

[Warner Losh]

On Tue, Sep 27, 2016 at 2:30 PM, Peter Vince <petervince1952 at gmail.com> wrote:
> On 27 September 2016 at 20:24, Michael Shields via LEAPSECS
> <leapsecs at leapsecond.com> wrote:
>>
>> On Tue, Sep 27, 2016 at 11:56 AM, Peter Vince <petervince1952 at gmail.com>
>> wrote:
>> > Thanks for your reply.  If there are no steps - how is it achieved?  Do
>> > you
>> > have a dedicated hardware clock(s) where the frequency of the master
>> > oscillator is wound down a bit, and your servers synchronise to that?
>>
>> No, the atomic frequency standards and GPS receivers continue to tick
>> SI seconds, and the smear is implemented entirely in software.  Maybe
>> I am not understanding your question.  Why do you think it would be
>> necessary to step?
>
> Thanks Michael. I am very unclear how a time server works. It presumably
> takes PPS pulses from a GPS receiver, and somehow synchronises a high
> resolution internal clock to those pulses.  But in order to provide the
> smeared time on to all its clients, it has to gradually increase the offset
> of its clock to the incoming PPS pulse.  So every second your clock needs to
> be 13.888888888888 microseconds later than last time with respect to the PPS
> pulse.  But with 100ns granularity on the system clock (I presume it is that
> same standard?), you can't do that accurately.  One way would be to have a
> dedicated hardware clock whose master frequency you offset, but I suspect
> your time server is a "standard" PC server?  Maybe you keep a high
> resolution floating point counter running in the PPS synchronising program
> and adjust your 100ns resolution clock to the nearest tick???
>
> Warner: Thank you, yes, having an externally adjustable oscillator for your
> clock would do the trick, but does that really happen?  I have been assuming
> that it is a PC that is running the time service, but perhaps there is some
> dedicated hardware that takes in GPS pulses and does indeed have a slewable
> oscillator???

The paper clock doesn't need an externally adjustable frequency. It
just pretends the frequency is different than it actually is when
making the calculations of time. There's two main places this
typically happens. All external frequency sources have some kind of
counter to count the number of ticks. When a purposeful error is
introduced, instead of each tick being, say 1.000 us, the computer
pretends it's really 0.999us or 1.001us (or whatever other error you
want to introduce, the example here is 1e-3 (or 1000 ppm)). Based on
this, the paper clock that exists in software gets updated by a rate
that will keep proper time (or will slew it a little to correct for
known errors). Since external frequencies sources are rarely very
good, a number of techniques have been devised to measure and correct.
Almost none of them are 'steerable', but that turns out not to matter
since you can fix it in software.

GPSes are rarely the direct frequency sources for software. Their PPS
provides a way to measure how good a computer's frequency source
really is so that very refined adjustments can be made to the estimate
of its frequency, as well as give a number of 'on time' points that
can be used to measure the phase error. Phase error is then usually
steered out with a tiny frequency error so as to present an orderly
view of time to the time consumers in the OS. ntp to a remote server
can also be used to measure how good the time is and provide an
estimate of frequency and phase error. The way stratum 1 ntp servers
work is they take a known good external reference, like GPS, an Atomic
clock, etc and use that reference to steer the system time (adjust the
paper clock) so that it is both on time and on frequency. When network
requests come in, it measures the time delta against the system's
realization of this paper clock and both sides are able to work out a
phase error. ntp works by combining these phase errors over time to
estimate the frequency error, which can then be used to steer the
system to be on time and on frequency.

Warner