[ntp:questions] Leap second resources
Brian.Inglis at SystematicSw.ab.ca
Tue Jun 30 07:16:29 UTC 2015
As of today UTC, ntpq -crv should now be reporting something like:
associd=0 status=4419 leap_add_sec, sync_uhf_radio, 1 event, leap_armed,
version="ntpd 4.2.6p5 at 1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2)",
processor="x86", system="Windows", leap=01, stratum=1, precision=-21,
If it is not, your system may not handle the leap second correctly.
Take care. Thanks, Brian Inglis
On 2015-06-05 03:40, Marco Marongiu wrote:
> On 05/06/15 10:59, Miroslav Lichvar wrote:
>> On Thu, Jun 04, 2015 at 05:52:47PM +0200, Marco Marongiu wrote:
>>> As you may have noticed from my messages in this list, I've also been
>>> running leap second simulations with ntpd on Debian during the past few
>>> weeks. If you're using Debian Linux systems you may find the post I've
>>> just published useful:
>> That is an interesting idea to use -x on both server and client. Does
>> it make the leap second correction easier for the clients to follow
>> and reduce the offset between them?
> First and foremost, it doesn't allow them to step. Which they may do,
> since (as you have seen), their offset from the server may grow more
> than tolerable. And they will receive the leap warning nonetheless.
> Maybe I'm overcautious, but... better safe than sorry.
>> In your offset plot there are two large (~0.5 second) swings. It
>> doesn't look like the client is fast enough to follow that, but maybe
>> the course of the correction is less variable?
> I'm still experimenting a lot to collect a fair amount of cases. That
> image comes from a simulation where the client was configured to use
> only one server but with a reduced maxpoll (7 instead of 10). In the
> latest simulation I ran between yesterday and today I had only one
> client polling three servers with maxpoll 8, and the curve is definitely
> The servers themselves were following three "stepping" upstreams and
> didn't manage to stay very close in the beginning, but ntpd on the
> clients will take care of that:
>> In my tests when only clients were using -x I saw offsets between them
>> up to 0.8 seconds when one client overshoot a lot and the other
> That's a possibility, unfortunately. That's why I'm using a reduced
> maxpoll on the clients to try to reduce spikes and convergence time as
> much as possible. Our clients use only our servers, so that we don't
> obsess public sources while reducing maxpoll. I would never do that
> against public sources.
More information about the questions