NTP 4.2.6p4 Released
NTP Public Services Project
(http://support.ntp.org/) is pleased to announce that NTP 4.2.6p4,
a Point Release of the NTP Reference Implementation from the
NTP Project, is now available at http://www.ntp.org/downloads.html and
http://support.ntp.org/download.
File-size: 4194210 bytes
MD5 sum: 1447121a07b49361677ffda4f6e29527 ntp-4.2.6p4.tar.gz
Changes:
* Distribute ntp-wait.html
* Update config.guess and config.sub for AIX
* Upgrade required version of autogen and libopts for building
from our source code repository
ntpd
* Backported several fixes for Coverity warnings from ntp-dev
* Fix a rare boundry condition in UNLINK_EXPR_SLIST()
* Allow "logconfig =allall" configuration directive
* Bind tentative IPv6 addresses on Linux
* Correct WWVB/Spectracom driver to timestamp CR instead of LF
* Improved tally bit handling to prevent incorrect ntpq peer status reports
* Exclude the Undisciplined Local Clock and ACTS drivers from the initial
candidate list unless they are designated a "prefer peer"
* Prevent the consideration of Undisciplined Local Clock or ACTS drivers for
selection during the 'tos orphanwait' period
* Prefer an Orphan Mode Parent over the Undisciplined Local Clock or ACTS
drivers
* Improved support of the Parse Refclock trusttime flag in Meinberg mode
* Backport utility routines from ntp-dev: mprintf(), emalloc_zero()
* Added the NTPD_TICKADJ_PPM environment variable for specifying baseline
clock slew on Microsoft Windows
* Code cleanup in libntpq
ntpdc
* Fix timerstats reporting
ntpdate
* Reduce time required to set clock
* Allow a timeout greater than 2 seconds
sntp
* Backward incompatible command-line option change:
-l/--filelog changed -l/--logfile (to be consistent with ntpd)
Documentation
* Update html2man. Fix some tags in the .html files
* Fix checking for struct rtattr
Please report any bugs, issues, or desired enhancements at
http://bugs.ntp.org/.
The NTP (Network Time Protocol) Public Services Project, which is
hosted by Internet Systems Consortium, Inc. (http://www.isc.org/),
provides support and additional development resources for the
Reference Implementation of NTP produced by the NTP Project
(http://www.ntp.org/).
_______________________________________________
announce mailing list
anno...@lists.ntp.org
http://lists.ntp.org/listinfo/announce
Richard B. Gilbert
> Redwood City, CA - 2011/09/23 - The NTP Public Services Project
> (http://support.ntp.org/) is pleased to announce that NTP 4.2.6p4,
> a Point Release of the NTP Reference Implementation from the
> NTP Project, is now available at http://www.ntp.org/downloads.html and
> http://support.ntp.org/download.
>
> File-size: 4194210 bytes
>
> MD5 sum: 1447121a07b49361677ffda4f6e29527 ntp-4.2.6p4.tar.gz
>
> Changes:
>
> * Distribute ntp-wait.html
> * Update config.guess and config.sub for AIX
> * Upgrade required version of autogen and libopts for building
> from our source code repository
>
> ntpd
>
> * Backported several fixes for Coverity warnings from ntp-dev
<snip>
Chuck Swiger
>> * Backported several fixes for Coverity warnings from ntp-dev
>
> WTF is "Coverity"? My dictionary does not list it!
It's a code analysis tool which looks for software bugs.
Regards,
--
-Chuck
David J Taylor
news:E1R8ZLK-...@mail.kostecke.net...
> Redwood City, CA - 2011/09/23 - The NTP Public Services Project
> (http://support.ntp.org/) is pleased to announce that NTP 4.2.6p4,
> a Point Release of the NTP Reference Implementation from the
> NTP Project, is now available at http://www.ntp.org/downloads.html and
> http://support.ntp.org/download.
> ntpd
>
> * Added the NTPD_TICKADJ_PPM environment variable for specifying
> baseline
> clock slew on Microsoft Windows
Does NTPD_TICKADJ_PPM allow the use of clocks which are more than 500 ppm
out? Sorry if I missed any earlier discussion on this (and I don't run
Linux). How does one go about determining the value to set - just
guesswork?
I'm interested because someone has just reported problems with NTP on a
system which gain (or loses) 1 second in 10 minutes! 1 part on 600! This
adjustment could be most helpful.
Thanks,
David
David J Taylor
>>> * Added the NTPD_TICKADJ_PPM environment variable for specifying
>>> baseline
>>> clock slew on Microsoft Windows
>>
>> Does NTPD_TICKADJ_PPM allow the use of clocks which are more than 500
>> ppm
>> out? Sorry if I missed any earlier discussion on this (and I don't run
>> Linux). How does one go about determining the value to set - just
>> guesswork?
>
> systems. You can determine the value to set any way you like, from
> measurement to guesswork to dart throws. The adjustment is done at a
> low level in the Windows ntpd port, invisible to the portable ntpd
> code, but is expressed in PPM with the same sign ntpd uses. If ntpd
> is bouncing up against the +500 PPM limit occasionally, using a
> positive NTPD_TICKADJ_PPM should improve the situation.
>> I'm interested because someone has just reported problems with NTP on a
>> system which gain (or loses) 1 second in 10 minutes! 1 part on 600!
>> This
>> adjustment could be most helpful.
>
> consistent enough that after the extreme compensation, it stays well
> under 500 PPM.
>
> Cheers,
> Dave Hart
Dave,
That's brilliant! I didn't know about it, and I don't know how I missed
it. Anyway, it's now found, so I've passed on the information and
recommended this version:
http://davehart.net/ntp/win/x86/ntp-4.2.6p4-win-x86-bin.zip
The chap involved is a C programmer on Windows, so he should be able to
handle it OK. Of course, if the problem is missed interrupts rather than
a simple clock-rate issue, it may not help at all. I had not involved you
earlier as I feel I've loaded you enough already, and had hoped to solve
this problem directly.
Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-...@blueyonder.co.uk
unruh
1 sec, sometimes 3 sec sometimes nothing). He is eitehr running a
virtual machine, in which case he should not be using ntpd, or his
operating system is doing an attrocious job of setting the system time
rate of his clock.
David J Taylor
news:slrnj86n3g...@wormhole.physics.ubc.ca...
[]
> Is he using a virtual system? Is that loss constant ( or is it sometimes
> 1 sec, sometimes 3 sec sometimes nothing). He is eitehr running a
> virtual machine, in which case he should not be using ntpd, or his
> operating system is doing an attrocious job of setting the system time
> rate of his clock.
Thanks for your thoughts, Bill. No, this is a real PC, which used to work
correctly. There is a question as to (a) whether the PC has become
faulty, (b) whether something had changed in the software, or (c) whether
some other program is interfering with the time. Nothing is supposed to
have changed in the software, and there are no restore points early enough
to check (b). The obvious candidates for (c) are not present, which
leaves (a) as the obvious cause, but I has my doubts that a PC would
suddenly start to lose 1 second every ten minutes.
I don't know whether the loss is constant, as with NTP running it keeps
resetting, and investigations are continuing. It's at the point where I'm
running out of ideas, so I may, very reluctantly, ask Dave H to get
involved, if the current tests prove unsuccessful. These tests are now to
try and run as plain an NTP as possible, but a more recent version
(4.2.6p4). I'll post the outcome here.
Cheers,
David
unruh
> news:slrnj86n3g...@wormhole.physics.ubc.ca...
> []
>> Is he using a virtual system? Is that loss constant ( or is it sometimes
>> 1 sec, sometimes 3 sec sometimes nothing). He is eitehr running a
>> virtual machine, in which case he should not be using ntpd, or his
>> operating system is doing an attrocious job of setting the system time
>> rate of his clock.
>
> Thanks for your thoughts, Bill. No, this is a real PC, which used to work
> correctly. There is a question as to (a) whether the PC has become
> faulty, (b) whether something had changed in the software, or (c) whether
> some other program is interfering with the time. Nothing is supposed to
> have changed in the software, and there are no restore points early enough
> to check (b). The obvious candidates for (c) are not present, which
> leaves (a) as the obvious cause, but I has my doubts that a PC would
> suddenly start to lose 1 second every ten minutes.
>
> I don't know whether the loss is constant, as with NTP running it keeps
No way. ntpd will not reset the clock. If it finds the rate that far
out, it will shut down.
> resetting, and investigations are continuing. It's at the point where I'm
> running out of ideas, so I may, very reluctantly, ask Dave H to get
> involved, if the current tests prove unsuccessful. These tests are now to
> try and run as plain an NTP as possible, but a more recent version
> (4.2.6p4). I'll post the outcome here.
The question is whether or not it is consistant, in which case it sounds
like the system is not setting the intial clock rate properly. The
system has an internal crystal, and a timer chip which counts a certain
number of oscillations and interrupts. It also calibrates the cpu
counter against the timer ticks. Now it is hard to imagine how that
hardware would go wrong.
a)find out if the time rate loss is consistant.
b) Try running chrony instead of ntpd and find out what the rate
correction is and see if it is consistant.
>
> Cheers,
> David
>
David J Taylor
[]
> out, it will shut down.
> The question is whether or not it is consistant, in which case it sounds
> like the system is not setting the intial clock rate properly. The
> system has an internal crystal, and a timer chip which counts a certain
> number of oscillations and interrupts. It also calibrates the cpu
> counter against the timer ticks. Now it is hard to imagine how that
> hardware would go wrong.
>
> a)find out if the time rate loss is consistant.
> b) Try running chrony instead of ntpd and find out what the rate
> correction is and see if it is consistant.
that much, which is why I didn't immediately just say "faulty hardware".
I just checked chrony and it does not appear to be available for Windows.
In any case, this system worked correctly before with ntp, so there's no
need to change. Work is in progress, and I will report back.
Cheers,
David