A few days ago I ran into an announcement concerning the new ISC NTP Forum. This newly formed organization has been created to provide better support for hard- and software vendors who use NTP in their products.
This sounds like a good idea to me, quite a lot of commercial vendors are shipping all kinds of versions of NTP with their products, including Operating Systems (every single Unix-like OS I know comes with a version of the NTP reference implementation from ntp.org) and hardware (like Meinberg's time server products or reference clocks) and although people are working hard on a NTPv4 standard, the new NTP Forum could help vendors to manage their NTP involvement in a more reliable and better way.
Problems with NTP in the past included code changes that introduce new features (great), new bugs (well...) and changed configuration option interpretations (ouch!). The current status quo means that every single vendor needs to run extensive quality checks on every single NTP version which is released. Having someone as a point of contact who deals with that and takes care of the quality of the code is great. The volunteer-based NTP public services project did a great job in the past but, with an ever growing user base, will reach its limit at some point in the future.
IMHO the end users will benefit from this as well, because a quality improvement will help to reduce downtimes and most probably reduces the number of bugs that hit the street. Testing an NTP release is a very time consuming effort, due to the long term nature of its main task and the variety of environments it runs in - it can be a simple client synchronizing the system time of a Windows workstation PC, running on a central network server serving time to hundreds and thousands of clients or quietly synchronize a subsystem in a spaceship on its way to Mars. Perfoming a test suite that validates the behavior of NTP in all those fields is a demanding undertaking which cannot be provided by volunteers and which often is not carried out in full scale at the vendors site.
I hope that this will succeed and that big OS players like Red Hat, IBM, Novell and probably even Microsoft will join and help to ensure that John Doe can download his fully tested stable NTP software while the cracks and especially the mastermind Dr. Mills can work on pushing time synchronization via a simple network link to new limits - just like Dave did in the past decades - without affecting the source code of the stable version until the new features are ready to be deployed in mission critical systems.
Merry Christmas to all of you and a Happy New Year 2008!
//Heiko
Tuesday, December 18, 2007
Wednesday, December 5, 2007
New Version of NTP for Windows Installer
I just uploaded the new NTP Installer for Windows on our NTP Download page. Besides replacing the previous ntp version with the current stable ntp 4.2.4p4 release I fixed a number of bugs which have been annoying users for quite a while now. Especially the unattended mode (UAM) has been fixed and has been tested extensively on several different machines in different environments.
While the performance on XP seems to be good, Windows Vista is a different story. In our tests on the 32bit and 64bit versions of Microsoft's draft OS showed that they behave differently when running exactly the same ntpd version.
Nailing the polling interval at 16s seems to at least help a bit, but this is of course only possible when you either operate your upstream NTP server yourself or have the permission of the server's operator to crank up the request rate with "minpoll4 maxpoll 4".
However, this would only be a temporary workaround and further tests indicate that the basic problem is still there and using the 16 seconds interval simply reduces the effect of it up to a certain degree.
I am happy to receive feedback and comments regarding the NTP Installer, so please feel free to contact me via mail (ntp-support@meinberg.de) or use the "comment" feature of this blog.
While the performance on XP seems to be good, Windows Vista is a different story. In our tests on the 32bit and 64bit versions of Microsoft's draft OS showed that they behave differently when running exactly the same ntpd version.
Nailing the polling interval at 16s seems to at least help a bit, but this is of course only possible when you either operate your upstream NTP server yourself or have the permission of the server's operator to crank up the request rate with "minpoll4 maxpoll 4".
However, this would only be a temporary workaround and further tests indicate that the basic problem is still there and using the 16 seconds interval simply reduces the effect of it up to a certain degree.
I am happy to receive feedback and comments regarding the NTP Installer, so please feel free to contact me via mail (ntp-support@meinberg.de) or use the "comment" feature of this blog.
Subscribe to:
Posts (Atom)