[email protected] wrote:
After waking this morning and reviewing the data I discovered that the
Azure VMs did in fact leap. The data below was taken from a system that
was set up on purpose to NOT leap. So I had no issues with the NTP
server/clients as far a time goes. As indicated below some systems were
reporting tai=1 in "ntpq -c rv" output after the leap. This appears to
be due to the fact that they no leap second history (no leapsecond file)
and no ref clock. It seems that the current value is not transmitted in
the NTP packets.
Correct. The normal packets only transport a leap second warning flag,
not a TAI offset. The TAI offset can be determined locally from a leap
second file, or remotely from an NTP server via autokey. However, for
the latter there was recently an issue. See NTP bug 2830:
"ntpd doesn't always transfer the correct TAI offset via autokey"
http://bugs.ntp.org/show_bug.cgi?id=2830
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: [email protected]
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
