> Note that this > is an instance of ntpd syncing against a single stratum 1 server. > Other configurations may have behaved differently.
Thank you for bringing this information to freshen up my understanding of the "leap" second and possible implications. This also reinvigorated my interest in an optimised ntpd.conf using a hand picked selection of stratum 1 servers of local vicinity for the main time service which local machines then use. While I had done that quite a while before using OpenNTPD, I recall with a smile back the days I rejoiced OpenNTPD appeared and went into service right away on my systems to replace the previously used software. Those were the days, and I was very confident later that it was also secure and immune to amplification attacks. For my systems now I see there is again value of using selected stratum 1 servers compared to a generic pool of time servers which mostly have lower quality time sources (network) and may carry over the ripples or otherwise bring slight inaccuracy depending on their configuration. Practical results are negligible yet for redundancy and reliability when one can't invest in a GPS time source, the selection of stratum 1 servers is worth it. At least to allow better observation in logs. > It took ntpd several poll intervals, adding up to 2+ hours, before > it was confident that there was a discrepancy to fix. It then > proceeded to correct the clock within a few minutes. Eventually > the frequency correction went off in one direction, then in the > other direction, before settling back to normal. The biggest offset > was 1.12 seconds, due to the frequency spike. Now, 12 hours later, > the last ripples are slowly dying out. Similar results seen here, it just worked OK as expected. I did not quite understand the frequency and ppm details at first, but passing flag -v to ntpd is good enough for me. What I also wanted to share is that some of the other implementations saw updates prior to the leap second timing (meaning they did fix their code again). This could be correlated to a spike (2x) of NTP packets seen on the graphs of one particular local time server before the leap second was inserted. Then again a bigger (4x) spike after the leap second on the following hours.
