Q @.. wrote:
I would of thought that a S1 server with an S0 GPS device would of been
'quite' by now. We shall see what happens come the end of the month.
If it only had the refclock configured it probably would be. The problem
comes from peer servers which pass the leap bits around, as
dwmal...@maths.tcd.ie (David Malone) wrote:
Exactly - I think this lingering-leapbits thing is a problem that
probably needs to be looked at, but it unlikely to cause many
problems in the near future. The rules for passing on leap bits
have gradually changed, and I guess what we are seeing is
Ronan Flood use...@umbral.org.uk writes:
Current ntp-stable has this comment in ntp_proto.c
* combining algorithm. Consider each peer in turn and OR the
* leap bits on the assumption that, if some of them honk
* nonzero bits, they must know what they are doing.
This has been changed in
Unruh unruh-s...@physics.ubc.ca wrote in message
news:jbmal.4597$ph1.2...@edtnps82...
dwmal...@maths.tcd.ie (David Malone) writes:
Well, the leap standard actually says that a leap second is possible at
the
end of any month, with June/dec being prefered, AprSep being next on the
list and
Is it me or are a *lot* of servers still advertising the leap from December
? 2 examples from one of my boxes, but most of the ones in the list are
showing leap_add_sec.
Or is there another leap coming in June, and everyone wants to get in early
advertising it ?
TIA.
ntpq -c rv
Q @.. writes:
Is it me or are a *lot* of servers still advertising the leap from December
? 2 examples from one of my boxes, but most of the ones in the list are
showing leap_add_sec.
I've been graphing this since late November:
Unruh unruh-s...@physics.ubc.ca writes:
Well, the leap standard actually says that a leap second is possible at the
end of any month, with June/dec being prefered, AprSep being next on the
list and the rest being down there.
Indeed - though that's not likely in the near future.
Now, ntp has
