Brian Utterback wrote:
If a system implements the NTP reference nano-kernel, the system clock
still reads as monotonically increasing, even during a leap second
deletion. However, reading the system clock is a very hot code path, and
so very few, if any, operating systems actually guarantee this. But the
reference code is always monotonically increasing for clock offsets of
one second or less.
I do know this!
I assume Google looked at all their N*100K systems, with various
operating systems, and decided that it was much easier to do the slow
slew that would keep all delta time measurements accurate within those
35 ppm or better, even when measured between systems with and without
leap second support.
Terje
On 09/20/11 13:25, Terje Mathisen wrote:
Dave Hart wrote:
As I understand it, all POSIX ntpd will step backward one second to
accomplish a leap second insertion (we've yet to see a deletion).
Windows ntpd differs, and is closer to Google's smeared timescale in
spirit. Leap seconds are inserted by Windows ntpd by slewing the
clock for 2 seconds, that is, the clock is run at half speed for two
seconds. The Windows ntpd code doesn't yet accommodate leap second
deletions. The advantage of this approach is time moves unceasingly
forward. The disadvantage, particularly with such a short-lived
smear, is that interval timing that starts or ends during the special
two seconds will be inaccurate by up to a second.
Google's hack is to use a cos() function to smear the time delta, this
means that as long as they do the smearing over a sufficiently long time
period all client systems would stay in sync from start to end.
The key requirement is to keep the frequency delta well below the 500
ppm which is the maximum ntp slew rate, and since many systems need
50-200 ppm under stable conditions, I'd like to limit the additional
delta to 100 pm or so.
This would require 10000 seconds with linear slew, but lead to frequency
steps at both ends. Since Google used a cos() function they avoid any
step functions, but need to increase the time period by pi/2.
15.7 K seconds is still only 4+ hours, so if Google used the last 12
hours of the day they would keep the slew rate at around 35 ppm.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
