8. Troubleshooting

This message typically indicates that a connection could not be made because the service is not available. See Q: 8.2.1.1..

No response was received within the timeout interval. Either the network did drop the request or the answer, or it delayed it considerably, or the server did not respond. One reason for the latter would be a configuration line like this:[3]

restrict default ignore

If you see that message in your log file, the system time was not set by ntpdate. There are several possible reasons:

• ntpdate failed to communicate through UDP port 123. This could be caused by some packet filtering or by firewalls. Unfortunately, using option -d to turn on debugging also changes the port ntpdate uses.

  If ntpdate works with option -d, you should try option -u to use an unpriviledged port. In any case you should check your packet filtering.

The keyword precision is no longer known by the configuration parser. Most likely you are using a configuration file intended for an older version of the NTP software. See also Q: 8.2.6.1..

Using adjtime() your system clock can be corrected by some amount of time (See also Q: 5.1.6.1.). Normally xntpd will only use small amounts that can be applied within one second. However, if you disallow time steps, the last correction may be not completed yet, and xntpd is unable to apply another correction until the last one is finished. This is what the message says.

This message was seen in Windows/NT 4.0 with ntpd 4.0. The exact cause is not clear, but it seems some non-NTP applications also use port 123. The strange IP address (192.0.0.192) is a strong indication for this.

John Hay contributed the output of nslookup 192.0.0.192, namely 192.0.0.0-is-used-for-printservices-discovery----illegally.iana.net, and Professor David L. Mills stated: "Port 123 was assigned well before 1985 as per documented, but was in use probably from 1982." This means the address is not registered officially, and it should not be used. Also it seems some software for printers or printing is using that address together with NTP's port number.

Despite of worrying some system administrator the message indicates no trouble. Specifically no printer is known to need a NTP server to operate, nor do printers and NTP servers harm each other.[4]

Some people say the CMOS RTC is much more accurate than the timer interrupt in terms of frequency error. Actually I don't know, but I have one concrete example:

A PC used a stratum 1 server with PPS had had a hardware fault, and it had been powered off for about 18 days. When running the typical frequency error was 15 to 17 PPM and when the system was rebooted the RTC clock was off by 18 seconds. That would be an error of roughly 12 PPM.

Basically ntpd only sets the system time of the operating system. Therefore setting the CMOS clock is the responsibility of the operating system and its associated tools. To make things worse, typical PC operating systems and the BIOS set the RTC to local time, while UNIX-like operating systems set the RTC to UTC.

Let me quote an explanation written by Poul-Henning Kamp from the newsgroup:

I was gathering some data for Professor David L. Mills today and they looked lousy to put it mildly, every 300-400 seconds I had a 40-50 microsecond peak in my data. After some debugging I know know what it was: The SMM mode interrupts to the BIOS.

This machine is brand new, and I had never put a PPS signal on it before, it uses the PIIX4 chip from Intel and appearantly the SMM BIOS gets called at regular (but not very precise) intervals to monitor temperatures and fans and whats not.

Needless to say, this could not be disabled in the BIOS setup.

I found out I could disable the SMI output from the PIIX4 to the CPU by clearing bit zero in the GLBCTL register in the third function of the 82371AB chip. You need to find the IO base address from register 0x40 in the PCI header, and add the 0x28 to that address. For my motherboard that ended up being 0xe428, your milage will vary, and you should Do The Right Thing to find this location.

Needless to say, the SMM BIOS will not be able to check if your CPU is able to make toast on if you disable it this way, so you'd better know what you're doing.

The function set_rtc_mmss() updates minutes and seconds of the CMOS clock from system time. It does not update the hour or date to avoid problems with timezones.[5] The message shown was added to make users and implementers aware of the problem that not all time updates will succeed.

Imagine the system time is 17:56:23 while the CMOS clock is already at 18:03:45. Updating just minutes and seconds would set the hardware clock to 18:56:23, a wrong value. The solution for this problem is either to wait a few minutes, or to install a kernel patch that fixes the problem. Normally a wrong time in the hardware clock will not show up until after reboot, or maybe after APM slowed down your system.

This message only appears if you are using the new nanokernel clock model, usually by having applied a recent PPSkit. Thus the message is coming directly from the kernel, or more precisely from adjtimex(). That function is used to implement adjtime(), ntp_gettime(), and ntp_adjtime(). The constant ADJ_TICKADJ (0x2000) is an extension to ntp_adjtime() that allows to set the value of tickadj (similar extensions use constants named ADJ_OFFSET_SINGLESHOT or ADJ_ADJTIME, ADJ_TICK).

Unfortunately that value is also used for MOD_NANO in the latest kernel clock algorithm. Therefore it was decided to relocate conflicting bits, thereby causing incompatibilities with old software that uses these extensions. However the decision is not critical as only very few programs use these extensions. At this point, it's also clear that the kernel can't decide whether a new program is using a new function, or an old program is trying to use the old function (thus the vague wording).

If you really need the new functionality, you should recompile your application using the current timex.h header file. If it still fails, you'll have to recompile the C library, or write a replacement function that is linked instead of the routine from the C library.

Between releases 2.0 and 2.2 of the Linux kernel the serial driver has been optimized for throughput. The new driver does not generate an interrupt for each character received, but instead when either the UART's receive buffer exceeds a threshold of typically ten characters, or when the next timer interrupt is scheduled.

The new default introduces an inaccuracy for received characters up to 10ms. Fortunately you can tell the driver to deliver received characters as soon as possible using the flag ASYNC_LOW_LATENCY for the port. The command setserial /dev/refclock-0 low_latency in connection with a recent release of the setserial utility can do that.

Multiport serial cards are usually optimized for throughput, not for low latency. Therefore, some reference clock drivers may cause trouble.

In case you are already in trouble, and using a standard serial port is not an option, you can only try to find out what's wrong:

Somewhere in the code cleanup between NTP v3 and NTP v4, the code to set the modem lines of the serial port got lost. The port has to be set up in a special way to provide power to the receiver.

For my receiver the command setserialbits /dev/refclock-0 -rts turns on power while ntpd is running. Some receivers care about polarity, some don't. You might try substituting -rts with -dtr.

For the RAWDCF PARSE driver there is a mode 14, that turns on power on the port, but my receiver (and others, too) had errors about every 10 seconds. I have reported the problem to the original author.

Here is a solution provided by Wolfgang Barth for SuSE Linux 6.3 using the ipchains packet filter (originally in German):

Wolfgang Barth also suggests the following debugging procedure:

According to Hal Murray, at least RedHat Linux 7.1 was shipped with this line in /etc/ntp.conf:

restrict default ignore

Thus any NTP network messages are ignored. Either remove that offending line, or selectively allow individual addresses. Usually one would use the IP address, but see how the restrict directive really works. Consider this fragment:

restrict default ignore
server 10.9.8.7
restrict 10.9.8.7

There are several possibilities besides using the BIOS:

• You can read the clock using cat /proc/rtc (if CONFIG_RTC is set), or hwclock --show (hwclock is a newer replacement for the older clock program). C-programmers could use the ioctl() interface and RTC_RD_TIME (see /usr/include/linux/mc146818rtc.h and /usr/src/linux/Documentation/rtc.txt).

• You can set the clock using either hwclock --set (possibly with --utc) or the ioctl() interface and RTC_SET_TIME.

• The kernel will normally read the clock during boot (when it does not know the timezone yet) and when APM had been active. When the kernel PLL is used, the system time will be written to the clock periodically (see also Q: 8.3.1.1.2. and Q: 8.3.4.1.1.). Setting or adjusting the time by other means will not update the hardware clock.

  However beginning with PPSkit-0.9 the hardware clock will be updated if the system time is set. You can even set up the correct timezone (see Q: 8.3.4.4.2. for details).

See also Q: 8.3.1.1.2.. According to the README file that comes along with PPSkit-0.9, there are some new features:

• The hardware clock's date and time is set whenever it is updated. Previously only the minutes and seconds were updated. Naturally this requires different treatment depending on whether the hardware clock is expected to run in UTC or local time.

• The hardware clock is updated whenever the system time is set (actually it happens 0.5s after the next second begins, but that's only because of the strange hardware).

• The interval for automatic updates of the RTC can be modified. Automatic updates can be disabled completely.

These changes were designed to make everybody happy. Therefore some new sysctl() functions were introduced. These variables can be accessed through files in /proc/sys/kernel/time:

As up to these changes most people did not care much about the kernel's timezone, the time zone is not set correctly in many cases. There is a trick to copy the current timezone to the kernel.[6] I use the following code in /sbin/init.d/boot.local (SuSE Linux):

timezone=$(date +%z | sed -e 's/\([0-9][0-9]\)\([0-9][0-9]\)/(60*10#\1+10#\2)/')
TIMESYSCTL=/proc/sys/kernel/time
[ -w $TIMESYSCTL/timezone ] && echo $((-$timezone)) 0 >$TIMESYSCTL/timezone
[ -w $TIMESYSCTL/rtc_runs_localtime ] && echo 1 >$TIMESYSCTL/rtc_runs_localtime

For Slackware Linux the proper place seems to be rc.local. (Contributed by Richard M. Hambly)

You are using /sbin/kerneld for automatic module loading. Several modules do not take good care of the time during initialization. If you can spare the memory, please load the modules at boot time.

The original contributor remarks: "This once occured to me. The sound system was demand loaded. A small application told the time every 15 minutes (saytime running in cron). The ntp logging showed me that something strange happened every 15 minutes. I found out it was the loading of the sound module every 15 minutes."

In addition removal of modules also seems to block interrupts.

(According to John Sager) The interrupt frequency for DEC Alpha is 1024Hz. According to Section 3.2 the value of tick is 977µs. Unfortunately 1024*977 is 1000448, giving an intrinsic frequency error of 448PPM, even for a perfect crystal.[7]

As not all versions of the Linux kernel and of NTP daemons can handle such a large frequency error, there may be a problem. Watch out whether your frequency seems to get stuck at some magical value (See Section 8.1). Trying the latest versions might help.

It seems Microsoft® SQL server occupies the socket address used for NTP. These messages can be found in the event log:

The solution is to start NTP first, even though Microsoft® SQL server will complain about not getting a port or socket.

Nicholas Jenkins contributed:

(...) The obvious key to this all; however, that doesn't appear in the Microsoft® documentation is that the W32time service is, IN FACT, *NOT* running by default! So, the simple solution to the whole problem is to just change the "startup type" of the w32time service in the "services" control panel to automatic", rather than manual. Then, either reboot, or just "start" the service, and the time will sync as nicely as you could possibly want!

According to David Woolley there are some anomalies in the implementation of SNTP in Windows/2000:

I just discovered that the office Windows 2000 domain controller and IIS machine have been configured to synchronise to our *nix time server (net time /setsntp:). A quick look at their behavour raises some serious concerns:

the stratum is always 2, even when the upstream server was stratum 3, and even when it has never been synchronised.

xntpd and ntpd to at least 4.0.99j will synchronise to them even though they are only SNTP (and indicating a false level of reliability).

Never synchronised Windows 2000 servers respond with a zero reference time and reference ID and are ignored, even though the leap bits are valid and the stratum is 2. ntptrace reports a root dispersion and synchronisation distance of 1.0 in all cases, but everything else seems to report zero, which makes me wonder whether ntptrace has SNTP detection code that is missing from the real daemon.

The xntpd used was the original Windows port and the ntpd was a Linux port with a reduced max distance (although this is not relevant and the fact that the server sends a distance of zero would defeat this measure, anyway).

This is an ntptrace through two Windows 2000 machines (goonhilly and hercnode1) and a Linux machine (stock Red Hat, NTP 3(?), called mailgate). The firewall blocks the next hop.

D:\>ntptrace goonhilly
goonhilly.XXXXX.co.uk: stratum 2, offset -0.133238, synch distance 1.00000
hercnode1.XXXXX.co.uk: stratum 2, offset -0.141267, synch distance 1.00000
mailgate.XXXXX.co.uk: stratum 3, offset -0.018762, synch distance 0.04329
ntp1.uk.psi.net:        *Timeout*

For comparison, this is from another Red Hat box, cvs.

D:\>ntptrace cvscvs.XXXXX.co.uk: stratum 4, offset -0.020810, synch distance 0.05432
mailgate.XXXXX.co.uk: stratum 3, offset -0.021750, synch distance 0.04344
ntp1.uk.psi.net:        *Timeout*

This is a verbose trace, and after a rationalisation of the time service tree (taken from the NTP 4 Linux):

bicycle:~/ntp# ntptrace -v goonhillyserver 192.168.xx.xx, port 123
stratum 2, precision -7, leap 00
refid mailgate.XXXXX.co.uk delay 0.02638, dispersion 0.00000 offset -0.001865
rootdelay 0.00000, rootdispersion 1.00000, synch dist 1.00000
reference time:      be926721.7c2c2d85  Thu, Apr 26 2001 10:21:37.485
originate timestamp: be927134.9e76c8b4  Thu, Apr 26 2001 11:04:36.619
transmit timestamp:  be927134.9b90214a  Thu, Apr 26 2001 11:04:36.607

server 192.168.xx.xx, port 123
stratum 3, precision -17, leap 00
refid ntp1.uk.psi.net delay 0.00175, dispersion 0.00000 offset -0.002226
rootdelay 0.08713, rootdispersion 0.02473, synch dist 0.06830
reference time:      be92708a.3d74f000  Thu, Apr 26 2001 11:01:46.240
originate timestamp: be927134.a362f000  Thu, Apr 26 2001 11:04:36.638
transmit timestamp:  be927134.a3b80a9d  Thu, Apr 26 2001 11:04:36.639

ntp1.uk.psi.net:        *Timeout*

The relatively low difference between the offsets suggests that Windows/2000 does do frequency correction.

I found [RFC 2030] a little confusing, especially when combined with earlier versions, but my impression is that it is trying to say that SNTP servers should send stratum 0, leap 11 unless they are directly connected to a radio clock. (...)

Possibly the problems described in Q: 8.3.11.2.1. still apply. At least the following problems are known:

• Online help suggests that only SNTP servers may be used, but SNTP is a proper subset of NTP, so any NTP server should work.

• The client sends a symmetric active package, indicating its willingness to synchronize the server. However, most servers are set up to require authentication for symmetric active modes, and thus will ignore the request. Despite of that, it violates [RFC 2030].

David J. Taylor contributed:

I have heard that Win2K/XP syncs correctly to many Internet NTP servers using the Microsoft® provided protocol. Indeed, if it did not, I think there would knowledge around that it was broken. NIST provide some configuration information at:

http://www.boulder.nist.gov/timefreq/service/pdf/win2000xp.pdf

There are considerations about the role of the PC within the Domain that may prevent it from synchronising to a time source outside the Domain. Anyone having problems with this may wish to check the registry settings listed at:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q223184

Doug Hogarth wrote:

TimeServ is not a server -- it is a client (I am the author). Perhaps you just want the actual NTP binaries compiled for Windows/NT, such as a link near the bottom of http://www.five-ten-sg.com/.

Things may never be 100% clear because TimeServ (including SNTP client feature) was written before ntpd was ported to Windows/NT (if it had been ported then I wouldn't have too much need for writing TimeServ). Also the current version of "Windows/NT" (Windows/2000) includes built-in time service which can be SNTP client (and server, if configured appropriately) - so MS basically suggested that I stop working on TimeServ around 1.5 years ago.

Specifically if the error NetRemoteTOD failed for each PrimarySource occurs Doug Hogarth says: "Most likely reason for that error message is that your .ini file is in the wrong directory (typically it belongs in c:\winnt, don't forget to "timeserv -update" and restart the time service after correcting it). I am the author of TimeServ, feel free to email me if you have further questions - http://www.niceties.com/TimeServ.html"

Actually there is no special documentation for Windows/NT (AFAIK). Despite of that, the popular binary distribution seems to come without the HTML documentation from the source distribution. To make things worse, the URL found in the README file is rather unspecific.

Unless there is additional documentation it's recommended to get and unpack the source archive. The files you want can be found in the html subdirectory.