Re: [ntp:questions] Why can't clocks do inital synchronization?
Well, no promises, but I am shooting for one of the next two releases of OpenSolaris. A backport to Solaris 10 is a possibility, but not highly probable. As for the version of NTP, I am constantly working with the latest development release. At some I'll have to freeze that of course. For political reasons, it seems like a good time would be when 4.2.5 becomes the new stable branch. David J Taylor wrote: Brian Utterback wrote: David J Taylor wrote: If Solaris or HP-UX is still supplying NTP 3, I would be rather worried. Be worried then. The latest bundled version of NTP on Solaris is xntpd 3-5.93e. Not too worried though. I hope to have V4 available in OpenSolaris soon. Brian Utterback Perhaps I should have added If I were using that software... as well. Glad to hear that an update is due, Brian. Do you know which version of NTP and Solaris? Thanks, 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?
David J Taylor wrote: If Solaris or HP-UX is still supplying NTP 3, I would be rather worried. Be worried then. The latest bundled version of NTP on Solaris is xntpd 3-5.93e. Not too worried though. I hope to have V4 available in OpenSolaris soon. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Brian Utterback wrote: David J Taylor wrote: If Solaris or HP-UX is still supplying NTP 3, I would be rather worried. Be worried then. The latest bundled version of NTP on Solaris is xntpd 3-5.93e. Not too worried though. I hope to have V4 available in OpenSolaris soon. Brian Utterback Perhaps I should have added If I were using that software... as well. Glad to hear that an update is due, Brian. Do you know which version of NTP and Solaris? Thanks, 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?
David J Taylor wrote: Unruh wrote: [] Of course if the unix system time were TAI then the leapsecond issue would not arise as far as the kernel were concerned. It would be cleaner to have the kernel on TAI and the translation to user space time via zoneinfo using a leapseconds file. I don't like that idea, initially, but I /can/ see the sense in it. Are any of the major UNIXes considering a similar change? Linux ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
Danny Mayer wrote: David J Taylor wrote: Unruh wrote: [] Of course if the unix system time were TAI then the leapsecond issue would not arise as far as the kernel were concerned. It would be cleaner to have the kernel on TAI and the translation to user space time via zoneinfo using a leapseconds file. I don't like that idea, initially, but I /can/ see the sense in it. Are any of the major UNIXes considering a similar change? Linux Thanks, Danny. I was thinking more of FreeBSD, Apple, Sun, HP etc. 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?
j...@specsol.spam.sux.com wrote: [] Solaris 10 Update 6 IS the latest release of Solaris and the provided NTP is nowhere near the latest downloadable version of NTP. I would have to check, but I am pretty sure the same is true for HP-UX. Not everyone runs Linux nor do they usually choose a OS for a rather obscure feature like NTP. To get back to the original topic, it seems to me if one really cares about absolute time, having just one hardware clock is not a very robust solution no matter what OS or version of NTP is being used. I have one client that does care and has GPS timeserver appliances at several sites with all the sites using all the NTP servers as potential sources so failing a major catastrophe at all sites, there is redundancy. If Solaris or HP-UX is still supplying NTP 3, I would be rather worried. I don't run Linux either. Yes, and I would want mixed-source reference clocks - i.e. some GPS and some radio. I suppose some atomic, although I've never needed timekeeping to that level. 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?
Seemed I made myself not totally clear: The system has NO network connection to the outside world, but will be the time source of a little network. (NOT internet-connected, for security reasons.) NTPDATE (which is deprecated anyway) does not work with reference clocks, it can query servers only. 'ntpd -g does not work, because clocks are treated different from servers and the code of NTPD inhibits corrections of more than CLOSETIME (4h) difference. So basically it looks like we would have to bypass sanity checks when '-g' is given. Or write a small program that does talk to your refclock and sets the time. Then run it before starting ntpd. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes: Seemed I made myself not totally clear: The system has NO network connection to the outside world, but will be the time source of a little network. (NOT internet-connected, for security reasons.) NTPDATE (which is deprecated anyway) does not work with reference clocks, it can query servers only. 'ntpd -g does not work, because clocks are treated different from servers and the code of NTPD inhibits corrections of more than CLOSETIME (4h) difference. So basically it looks like we would have to bypass sanity checks when '-g' is given. Or write a small program that does talk to your refclock and sets the time. Then run it before starting ntpd. That is of course rediculous since that is what ntp -g is supposed to do. REplying to a bug report that you can write your own program is true, but not helpful. Removing the CLOSETIME check would seem the simplest thing to do. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
ma...@ntp.isc.org (Danny Mayer) writes: Folkert van Heusden wrote: I don't recall ever seeing a report of NTP causing problems with normal operations. Sorry for being anal on this but: Well almost: certain versions of the linux kernel under certain specific conditions would panic when ntp introduces a leap second. http://markmail.org/message/dhm5byrbfcarpiet?q=leap+second+list:org.kernel.vger.linux-kernel Ok it's a bug in the linux kernel but it is only triggered by ntp. No, it is triggered by anything which uses adjtimex with the leapseconds flag set. I just saw something about this in the NTP WG from the linux kernel wranglers who seem to be totally confused about NTP. They should fix the kernel bug and not start talking about TAI. They certainly should fix the bug. And they certainly seem totally confused about the definition of UTC. They do have a valid point, that has long long been debated in NTP forums re whether the Unix computer clock should show TAI or UTC. That is a valid debate to have (again). Of course it is trivial to convert from one to the other, assuming you have the leapseconds file. Of course if the unix system time were TAI then the leapsecond issue would not arise as far as the kernel were concerned. It would be cleaner to have the kernel on TAI and the translation to user space time via zoneinfo using a leapseconds file. Danny Folkert van Heusden ___ 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: [] Of course if the unix system time were TAI then the leapsecond issue would not arise as far as the kernel were concerned. It would be cleaner to have the kernel on TAI and the translation to user space time via zoneinfo using a leapseconds file. I don't like that idea, initially, but I /can/ see the sense in it. Are any of the major UNIXes considering a similar change? 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?
In article 9bca36-5p@mail.specsol.com j...@specsol.spam.sux.com writes: 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. FWIW, and still quite irrelevant to the original question, while the version shipped with Solaris 10 (xntpd actually) is indeed based on ancient code, it does have a -g option: # uname -sr SunOS 5.10 # /usr/lib/inet/xntpd -v /usr/lib/inet/xntpd: option requires argument -v usage: /usr/lib/inet/xntpd [ -abdgmx ] [ -c config_file ] [ -e e_delay ] [ -f freq_file ] [ -k key_file ] [ -l log_file ] [ -p pid_file ] [ -r broad_delay ] [ -s statdir ] [ -t trust_key ] [ -v sys_var ] [ -V default_sysvar ] It's not documented, and may not do exactly what the current version of -g does, but something pretty close. --Per Hedeland p...@hedeland.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?
David J Taylor david-tay...@blueyonder.neither-this-bit.nor-this-bit.co.uk wrote: 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 What planet do you people live on? I have one client that will not even allow Windows critical security updates to be installed until a extensive formal test is done to prove the updates won't effect operations. This is hardly a unique operation. -- 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: [] What planet do you people live on? I have one client that will not even allow Windows critical security updates to be installed until a extensive formal test is done to prove the updates won't effect operations. This is hardly a unique operation. Well, I can appreciate that makes sense, as I have known some updates to affect normal operations, although in those circumstances I used to recommend separate PCs for Internet operations. I don't recall ever seeing a report of NTP causing problems with normal operations. 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?
I don't recall ever seeing a report of NTP causing problems with normal operations. Sorry for being anal on this but: Well almost: certain versions of the linux kernel under certain specific conditions would panic when ntp introduces a leap second. http://markmail.org/message/dhm5byrbfcarpiet?q=leap+second+list:org.kernel.vger.linux-kernel Ok it's a bug in the linux kernel but it is only triggered by ntp. Folkert van Heusden -- Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
David J Taylor david-tay...@blueyonder.neither-this-bit.nor-this-bit.co.uk wrote: j...@specsol.spam.sux.com wrote: [] What planet do you people live on? I have one client that will not even allow Windows critical security updates to be installed until a extensive formal test is done to prove the updates won't effect operations. This is hardly a unique operation. Well, I can appreciate that makes sense, as I have known some updates to affect normal operations, although in those circumstances I used to recommend separate PCs for Internet operations. I don't recall ever seeing a report of NTP causing problems with normal operations. David Nor would I ever expect to. The point is LOTS of places have extensive procedures in place that must be followed before any software on production systems can be changed, including applying vendor supplied and recommended patches. While I have free reign to do anything I want with my systems, such is not the case for many of my client's systems. -- 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?
Folkert van Heusden wrote: I don't recall ever seeing a report of NTP causing problems with normal operations. Sorry for being anal on this but: Well almost: certain versions of the linux kernel under certain specific conditions would panic when ntp introduces a leap second. http://markmail.org/message/dhm5byrbfcarpiet?q=leap+second+list:org.kernel.vger.linux-kernel Ok it's a bug in the linux kernel but it is only triggered by ntp. Folkert van Heusden Thanks for that. I do wish it were easier to test these leap-second issues. 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?
j...@specsol.spam.sux.com wrote: [] The point is LOTS of places have extensive procedures in place that must be followed before any software on production systems can be changed, including applying vendor supplied and recommended patches. While I have free reign to do anything I want with my systems, such is not the case for many of my client's systems. Oh, indeed, but I might ask why my client was still running, or had chosen to install in the first place, such outdated versions of software, before taking on those systems. But that's life, I suppose. 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?
David J Taylor david-tay...@blueyonder.neither-this-bit.nor-this-bit.co.uk wrote: j...@specsol.spam.sux.com wrote: [] The point is LOTS of places have extensive procedures in place that must be followed before any software on production systems can be changed, including applying vendor supplied and recommended patches. While I have free reign to do anything I want with my systems, such is not the case for many of my client's systems. Oh, indeed, but I might ask why my client was still running, or had chosen to install in the first place, such outdated versions of software, before taking on those systems. But that's life, I suppose. Cheers, David Solaris 10 Update 6 IS the latest release of Solaris and the provided NTP is nowhere near the latest downloadable version of NTP. I would have to check, but I am pretty sure the same is true for HP-UX. Not everyone runs Linux nor do they usually choose a OS for a rather obscure feature like NTP. To get back to the original topic, it seems to me if one really cares about absolute time, having just one hardware clock is not a very robust solution no matter what OS or version of NTP is being used. I have one client that does care and has GPS timeserver appliances at several sites with all the sites using all the NTP servers as potential sources so failing a major catastrophe at all sites, there is redundancy. -- 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?
Terje Mathisen wrote: 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 Before creating a bug report I searched the database for CLOSETIME and found a bug report had already been opened. The status is NEW, which seemed to imply someone following this email discussion beat me to the punch. However, the existing bug report was opened in April of 2005. There is some back-and-forth discussion between the developers (including Dave Mills), but clearly there was no consensus on how it needs to be fixed and there has been no discussion since August 2005. There were some patches submitted that either did not address the exact problem we are discussing here or the patches were never accepted. Not sure what the protocol is for this situation, but it appears the original bug report needs a bump: https://support.ntp.org/bugs/show_bug.cgi?id=417 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?
Folkert van Heusden wrote: I don't recall ever seeing a report of NTP causing problems with normal operations. Sorry for being anal on this but: Well almost: certain versions of the linux kernel under certain specific conditions would panic when ntp introduces a leap second. http://markmail.org/message/dhm5byrbfcarpiet?q=leap+second+list:org.kernel.vger.linux-kernel Ok it's a bug in the linux kernel but it is only triggered by ntp. I just saw something about this in the NTP WG from the linux kernel wranglers who seem to be totally confused about NTP. They should fix the kernel bug and not start talking about TAI. Danny Folkert van Heusden ___ 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 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] 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
