Re: [ntp:questions] Why can't clocks do inital synchronization?
Andy Helten andy.hel...@dot21rts.com wrote:
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
Have you never heard of calling ntpdate before starting the NTP daemon?
--
Jim Pennino
Remove .spam.sux to reply.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
jimp wrote:
Andy Helten andy.hel...@dot21rts.com wrote:
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit
year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
Have you never heard of calling ntpdate before starting the NTP daemon?
Yes, I have heard of ntpdate and I use it when it works. Unfortunately,
maybe you haven't heard it doesn't work with reference clocks? Observe:
ntp2 root 10-ntpdate -b 127.127.16.0
5 Jan 12:13:30 ntpdate[4691]: no server suitable for synchronization found
Why doesn't it work? I don't know for certain but I'm guessing it is
because the simplistic ntpdate program thinks 127.127.16.0 is an actual
IP address. What next? Let me guess -- have I never heard of ntpd
-q? That doesn't work for the same reason that ntpd won't use the
reference clock time: the system time and ref clock differ by more than
the CLOSETIME value of 4 hours.
No one has answered the OP question and apparently no one understands
the behavior as well as myself and the OP. I was also curious about the
CLOSETIME behavior, but decided on a work around that, in my case,
wasn't that big of a deal.
Andy
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
j...@specsol.spam.sux.com writes:
Andy Helten andy.hel...@dot21rts.com wrote:
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit
year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
Have you never heard of calling ntpdate before starting the NTP daemon?
uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
used. If ntpd -g fails it is a bug.
--
Jim Pennino
Remove .spam.sux to reply.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Unruh wrote:
j...@specsol.spam.sux.com writes:
Andy Helten andy.hel...@dot21rts.com wrote:
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more
than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit
year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the
system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the
only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it
is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
Have you never heard of calling ntpdate before starting the NTP daemon?
uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
used. If ntpd -g fails it is a bug.
Then it is a bug because, as previously mentioned, no command line
argument or tinker can disable this behavior. I suppose the solution is
to skip the CLOSETIME check in clocktime() when '-g' is specified.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Andy Helten wrote: Unruh wrote: uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Then it is a bug because, as previously mentioned, no command line argument or tinker can disable this behavior. I suppose the solution is to skip the CLOSETIME check in clocktime() when '-g' is specified. Andy, I agree totally: With no remote reference clocks, only local hardware, said hardware has to skip the sanity checks during that initial -g adjustment. Andy, you should go on the ntp.org site and register this as a bug! Terje -- - terje.mathi...@hda.hydro.com almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] My extra second ...
Not 3 or 4 years, likely by June or December 2010. Rich Schmidt Unfortunately we will have to wait 3 or 4 years for the next test. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
On 2009-01-05, Andy Helten andy.hel...@dot21rts.com wrote: No one has answered the OP question and apparently no one understands the behavior as well as myself and the OP. It may well be that very few people have observed the behavior described by the OP. And none of those individuals frequent this news-group. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
j...@specsol.spam.sux.com wrote in message news:9bca36-5p@mail.specsol.com... Unruh unruh-s...@physics.ubc.ca wrote: uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. Yup. Legacy stuff doesn't go away by wishing it to. It's still a bug, though. Ntpdate is most unlikely to get fixed; ntpd -g at least has a chance. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Andy Helten wrote:
jimp wrote:
Andy Helten andy.hel...@dot21rts.com wrote:
Heiko Gerstung wrote:
Juergen Perlinger schrieb:
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more
than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-coded window of +/- 4h
around the sample time (== system time). This makes it impossible for
systems to recover from a loss of power if there is no battery-backup
driven hardware clock.
I appreciate the fact that there are clock signals that do not transmit
year
information (IRIG-B, as far as I know...) and that clocks using such
signals require some processing of the kind 'clocktime()' does.
But it's still a nuisance if you have a DCF77 or a GPS clock and the
system
does not synchronize after boot just because the CMOS is backed by a
GoldCap capacitor instead of a real battery. (And getting different
hardware is *not* an option for some of us!)
I think that the normal panic threshold ('tinker panic') should be the
only
limit for the acceptance of time stamps, and a disabled panic threshold
would permit the system to synchronize even without a backup CMOS clock.
While changing the behavior of NTPD wouldn't be too hard to implement I
would like to know *why* the clock processing is implemented the way it
is.
Does anybody know an could enlighten me?
Juergen, did you see the -g command line switch? This one will allow for
a one-time correction of the clock even if offsets are greater than the
panic threshold value.
Regards,
Heiko
No, I don't believe any flag or tinker can disable this behavior. This
question is referring to the use of the CLOSETIME macro as a rough
sanity check on the ref clock's time. In order to truly change this
behavior you would need to redefine the CLOSETIME macro and recompile.
On the other hand, we dealt with this problem by always setting system
time to the ref clock's time prior to starting up NTP. For us, this
required writing a simple piece of C code that was integrated with our
application that starts NTP. That was the only solution I found without
modifying NTP (and that was not considered a desirable option).
Andy
Have you never heard of calling ntpdate before starting the NTP daemon?
Yes, I have heard of ntpdate and I use it when it works. Unfortunately,
maybe you haven't heard it doesn't work with reference clocks? Observe:
ntp2 root 10-ntpdate -b 127.127.16.0
5 Jan 12:13:30 ntpdate[4691]: no server suitable for synchronization found
Why doesn't it work? I don't know for certain but I'm guessing it is
because the simplistic ntpdate program thinks 127.127.16.0 is an actual
IP address. What next? Let me guess -- have I never heard of ntpd
-q? That doesn't work for the same reason that ntpd won't use the
reference clock time: the system time and ref clock differ by more than
the CLOSETIME value of 4 hours.
No one has answered the OP question and apparently no one understands
the behavior as well as myself and the OP. I was also curious about the
CLOSETIME behavior, but decided on a work around that, in my case,
wasn't that big of a deal.
Andy
ntpdate is deprecated! Which is not to say that a lot of people don't
still use it. Just expect it to disappear from the distribution one of
these days!
ntpd -g is the preferred means of starting ntpd. The -g tells ntpd to
set the clock, stepping if necessary, on a once only basis.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
j...@specsol.spam.sux.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. So download the reference implementation from ntp.org and build your own! Both Sun's own development tools and gcc and other Gnu stuff are available in Solaris. Sun's development tools are a separate download from the web site. No vendor is going to include NTP V4 in their distribution until V4 is standardized. Which might happen some day or might not! A committee has been working on a V4 RFC for almost two years now. We might see results in another two or three years! IOW, don't hold your breath! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Richard B. Gilbert rgilber...@comcast.net wrote: j...@specsol.spam.sux.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. So download the reference implementation from ntp.org and build your own! Both Sun's own development tools and gcc and other Gnu stuff are available in Solaris. Sun's development tools are a separate download from the web site. You do understand there are lots of environments where it takes an act of God to be allowed to replace vendor utilities with self compiled versions, don't you? -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
j...@specsol.spam.sux.com wrote: Richard B. Gilbert rgilber...@comcast.net wrote: j...@specsol.spam.sux.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. So download the reference implementation from ntp.org and build your own! Both Sun's own development tools and gcc and other Gnu stuff are available in Solaris. Sun's development tools are a separate download from the web site. You do understand there are lots of environments where it takes an act of God to be allowed to replace vendor utilities with self compiled versions, don't you? Not at all! I own the machines so I AM GOD!!! YOUR mileage may vary!! If your God wants you to use NTP V3, that's your problem. And his! Good luck! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Richard B. Gilbert wrote: j...@specsol.spam.sux.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. So download the reference implementation from ntp.org and build your own! Both Sun's own development tools and gcc and other Gnu stuff are available in Solaris. Sun's development tools are a separate download from the web site. No vendor is going to include NTP V4 in their distribution until V4 is standardized. Which might happen some day or might not! A committee has been working on a V4 RFC for almost two years now. We might see results in another two or three years! IOW, don't hold your breath! It's in IESG review right now. We are hoping for an RFC number shortly. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
j...@specsol.spam.sux.com wrote: [] You do understand there are lots of environments where it takes an act of God to be allowed to replace vendor utilities with self compiled versions, don't you? Not a problem with Windows, fortunately. G David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
