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@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:
http://syslog.me/2015/06/04/a-humble-attempt-to-work-around-the-leap-second-2015-edition/
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
better:
https://twitter.com/brontolinux/status/606723588427776000
https://pbs.twimg.com/media/CGuDi6nVAAAie4q.png:large
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:
https://pbs.twimg.com/media/CGuDhfRUgAAdLL_.png:large
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
didn't.
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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
