On 01/26/2015 01:03 PM, Terje Mathisen wrote:
> One of the good points about Google's smear is the fact that they use a
> half cosine to distribute the offset, which means that they have a time
> function which is both continuous and monotonic, as well as having an
> infinite number of defined derivatives, i.e. it is maximally smooth.
I noticed that it lends itself to such properties (even if Googles
specific implementation fails to do so). However, you pay for it either
in a long window needed to perform the smear, on in some of said
derivatives going *way* off their normal values.
> The _huge_ problem with their approach is that they have to make d***
> sure there will never be any time leaks between their internal smeared
> timebase and any external UTC/TAI clocks as long as the adjustment is
> taking place.
Because they chose the long window (about one day) and made it exceed
the time an NTP peering needs to *act* on the perceived offset, yes. If
it weren't announced that NTPv5 will support labelling the actual
timescale used, I'ld propose that future kernels SHOULD not only accept
"leap second upcoming" bits from an NTP client s/w, but also hand "leap
second handling in progress" bits back, so as to allow the s/w to mark
itself as "unsynced" via NTP until the effects are over.
Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
