Re: [ntp:questions] NTP offset doesn't change.

[catherine . wei1989]

By the way, the ntp version I'm using is 4.2.8p1.
Catherine.

On Tuesday, February 10, 2015 at 1:15:21 PM UTC+8, catherin...@gmail.com wrote:
> Hi, I'm using the ntpd to sync time. When I change the current date for 
> exampe to 0210020215 (2015-02-10 02:02), the actually current time is 
> 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't 
> change at all.
>  ~ # ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *zse18adnss1.ea. 10.6.151.123 2 u58  377  280.663  2520785  16.037
> 
> ~ # ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *ns3.swelin.arri 10.6.151.123 2 u38  377  280.774  2520785  16.089
> 
> However, when I wait for several minutes, the time can be adjusted to the 
> right time. I couldn't see the gradual changes of offset. Is that normal?
> 
> Appreciate your help, thank you.
> Catherine.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] NTP offset doesn't change.

[catherine . wei1989]

Hi, I'm using the ntpd to sync time. When I change the current date for exampe 
to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 
03:02, then I run "ntpq -p" for several times, the offset doesn't change at all.
 ~ # ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
*zse18adnss1.ea. 10.6.151.123 2 u58  377  280.663  2520785  16.037

~ # ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
*ns3.swelin.arri 10.6.151.123 2 u38  377  280.774  2520785  16.089

However, when I wait for several minutes, the time can be adjusted to the right 
time. I couldn't see the gradual changes of offset. Is that normal?

Appreciate your help, thank you.
Catherine.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp-4.2.8 problem

[catherine . wei1989]

On Saturday, February 7, 2015 at 9:10:01 AM UTC+8, Harlan Stenn wrote:
> This problem was fixed right after 4.2.8 was released.
> 
> And now, folks should be running 4.2.8p1.
> 
> H
> --
> William Unruh writes:
> > On 2015-02-04, Wei, Catherine  wrote:
> > > Hi,
> > > I met a problem when I was building ntp-4-2.8 on Linux. The log is
> > > on below. I really appreciate if you could you give me some advice? It
> > > was used OK with ntp-4.2.6 before I upgraded.
> > >
> > >  CCLD   ntp-keygen
> > > ../libntp/libntp.a(ntp_crypto_rnd.o): In function `ntp_crypto_random_buf':
> > > /home/catherine/work/KREATV-27230/platform/3pp/ntp/bcm45/ntp-4.2.8/libntp/n
> > tp_crypto_rnd.c:93:
> > > undefined reference to `arc4random_buf'
> > > collect2: ld returned 1 exit status
> > > make[6]: *** [ntp-keygen] Error 1
> > > make[5]: *** [all] Error 2
> > > make[4]: *** [all-recursive] Error 1
> > > make[3]: *** [all] Error 2
> > > make[2]: *** [bcm45/ntp-4.2.8/.done] Error 2
> > > make[1]: *** [.target_bcm45_] Error 2
> > 
> > You do not seem to have arc4. Perhaps somehow you are compiling witht he
> > HAVE_ARC4RANDOM flag set when you do not have it?
> > 
> > Look in the make files whether that flag is being defined somewhere.
> > 
> > ___
> > questions mailing list
> > questions@lists.ntp.org
> > http://lists.ntp.org/listinfo/questions
> >

Yes, you're right. I'm now using the latest version 4.8.1p1. The problem 
resolved.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd -x and leap seconds

[Mike S]

On 2/9/2015 5:49 AM, Miroslav Lichvar wrote:

The -x option disables the kernel discipline, so the kernel is not
told about pending leap seconds and its up to ntpd to do whatever is
needed. Older ntpd versions (before 4.2.6) didn't handle leap second
in the daemon loop and -x could be used to avoid the backward step in
the Unix time scale and possibly upset the applications running on the
system.


One wonders why NTP doesn't simply follow its own RFC 5905, which 
clearly states:


"A timescale is a frame of reference where time is expressed as the 
value of a monotonically increasing binary counter with an indefinite 
number of bits... In the date and timestamp formats, the prime epoch, or 
base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. 
It should be noted that strictly speaking, UTC did not exist prior to 1 
January 1972, but it is convenient to assume it has existed for all 
eternity, even if all knowledge of historic leap seconds has been lost. 
 Dates are relative to the prime epoch; values greater than zero 
represent times after that date; values less than zero represent times 
before it.  Note that the Era Offset field of the date format and the 
Seconds field of the timestamp format have the same interpretation."


A couple of points on the above. The statement regarding knowledge of 
historic leap seconds is nonsensical - there were none prior to 1972 to 
loose knowledge of, the length of the second varied to match the 
heavens. the NTP protocol requires no knowledge of leap seconds, other 
than a pending one for purposes of announcing it. The RFC makes no 
mention of NTP timestamps being discontinuous around leap seconds, in 
fact it states that timestamps are to be "monotonically increasing." It 
doesn't naively and incorrectly define a day as having exactly 86400 
seconds, as POSIX does. (It does, however, give incorrect and 
self-contradictory timestamps for the dates 1Jan1972 and 31Dec1999).


Since RFC 5905 defines NTP timestamps in terms of monotonically 
increasing seconds since 1900, NTP (the implementation) should do 
exactly that. Instead, the implementation of NTP is incorrect in that it 
mimics POSIX by both assuming fixed length days and counting time 
discontinuously and non-monotonically in violation of the RFC.


Mills offers the following explanation 
(https://www.eecis.udel.edu/~mills/leap.html), which contradicts the RFC:


"The NTP and POSIX timescales are based on the UTC timescale, but not 
always coincident with it. The origin of the NTP timescale, the prime 
epoch, is 0h 1 January 1900, while the prime epoch of the POSIX 
timescale is 0h 1 January 1970. Both timescales reckon in standard (SI) 
seconds since the prime epoch... The insertion of leap seconds in UTC 
and subsequently into NTP..." A table is also included showing the 
non-monotonic discontinuity in NTP (implementation) timestamps.


Since the RFC says NTP is supposed to be counting seconds since 1900, 
there should be no "insertion of leap seconds in UTC and subsequently 
into NTP." NTP should simply keep right on ticking as stated in the RFC. 
The announcement of pending leap seconds is appropriate for a time 
dissemination service, but the conversion of NTP timestamps to UTC, 
accommodating leap seconds, is necessarily an OS function.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd -x and leap seconds

[Jochen Bern]

On 02/09/2015 11:49 AM, Miroslav Lichvar wrote:
> Should be leap seconds threated as a normal offset and not corrected
> by step when the threshold is larger than 1.0? Should there be a
> separate option for them?

I have practical use cases for *both* variants (*), so I'ld prefer being
given the possibility to do either. Whether I have an *option* to do
that or can effect it by *config* (setting the limit, which is otherwise
unused) is, however, secondary.

FWIW, I could also imagine people to be interested in having leap
seconds handled by the *kernel* even when steps are generally disabled -
*especially* if the method *how* a kernel handles them is going to
become a zoo of variants outside ntpd's control in the future ...

(*)
a) Even leap seconds should be *slews* when the reason to disable steps
   is that some software cannot handle such behavior of the OS clock.
b) We're distributing appliances where the ntpd on the appliance losing
   sync leads to alerts getting raised with the local admin. The server
   has steps disabled so as to prevent clients losing sync over a step.
   However, the clients can and will process leap seconds "normally", so
   the server should do the same.

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd -x and leap seconds

[Marco Marongiu]

On 09/02/15 11:49, Miroslav Lichvar wrote:
> I was wondering what others think about handling leap seconds when
> ntpd is running in the "slew only" mode (-x option).
[...]
> In 4.2.6 was added support for leap seconds in the daemon loop and
> ntpd now steps the clock by calling settimeofday() or clock_settime(),
> even if the step threshold (set by -x or tinker step) is larger than
> one second.

That was my plan (actually using tinker for that and explicitly
disabling the kernel discipline). My tests three years ago suggested
that the clock wasn't stepped but maybe I was using 4.2.4?

Anyway, I'll let you know as soon as I can set some time aside to do
these tests.

Ciao
-- bronto


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd -x and leap seconds

[Mike Cook]

As the man page for ntpd does not specifically exclude leap second ‘stepping’ 
from the -x behavior, I think that it could well be that the behavior that you 
describe is a bug. That said, it would be nice to have a  -x [ policy ] option 
for it, with the type of slewing for the leaping day ;-) . Could be [ linear | 
google | step | custom ].


> Le 9 févr. 2015 à 11:49, Miroslav Lichvar  a écrit :
> 
> I was wondering what others think about handling leap seconds when
> ntpd is running in the "slew only" mode (-x option).
> 
> The -x option disables the kernel discipline, so the kernel is not
> told about pending leap seconds and its up to ntpd to do whatever is
> needed. Older ntpd versions (before 4.2.6) didn't handle leap second
> in the daemon loop and -x could be used to avoid the backward step in
> the Unix time scale and possibly upset the applications running on the
> system.
> 
> In 4.2.6 was added support for leap seconds in the daemon loop and
> ntpd now steps the clock by calling settimeofday() or clock_settime(),
> even if the step threshold (set by -x or tinker step) is larger than
> one second.
> 
> Should be leap seconds threated as a normal offset and not corrected
> by step when the threshold is larger than 1.0? Should there be a
> separate option for them?
> 
> http://bugs.ntp.org/show_bug.cgi?id=2745
> 
> -- 
> Miroslav Lichvar
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] ntpd -x and leap seconds

[Miroslav Lichvar]

I was wondering what others think about handling leap seconds when
ntpd is running in the "slew only" mode (-x option).

The -x option disables the kernel discipline, so the kernel is not
told about pending leap seconds and its up to ntpd to do whatever is
needed. Older ntpd versions (before 4.2.6) didn't handle leap second
in the daemon loop and -x could be used to avoid the backward step in
the Unix time scale and possibly upset the applications running on the
system.

In 4.2.6 was added support for leap seconds in the daemon loop and
ntpd now steps the clock by calling settimeofday() or clock_settime(),
even if the step threshold (set by -x or tinker step) is larger than
one second.

Should be leap seconds threated as a normal offset and not corrected
by step when the threshold is larger than 1.0? Should there be a
separate option for them?

http://bugs.ntp.org/show_bug.cgi?id=2745

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions