During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.

Known Hardware Issues


These can cause problems for maintaining clock accuracy. See the APIC and ACPI topics under ConfiguringTrimblePalisadeAcutimeRefclocks for more information.

Variable Speed Processors

Variable speed processors speed up or slow down to handle the workload and cooling requirements. This processor feature is quite common in laptops and according to Wolfgang Rupprecht is now also starting to appear in some desktop machines.

Since NTP uses the CPU clock cycle for timekeeping, variable speed processors upset timekeeping calculations -- possibly leading to wildly incorrect times. BradKnowles has pointed out that ntpd was never intended to be able to handle variable speed processors and it might require a ground-up rewrite of some or all of the algorithms in the protocol.

These kinds of issues have come up before on the newsgroup comp.protocols.time.ntp. For example, see these threads:


  1. Lock the frequency of the processor. Obviously the benefits of reduced power consumption and dynamically adjusting to workload will be lost.
  2. For Unix systems, SteveKostecke and BradKnowles recommend calling 'ntpd -gq' from cron to periodically correct the time only when it is not feasible to run ntpd as a daemon. You should be able to do the same sort of thing for other OSes, although the implementation details may differ. Of course, you will want to make use of the "iburst" option for the server configuration lines, etc.... Doing so will reduce your "startup" time, and the chances of your being negatively impacted by CPU clock speed changes during the process. See ConfiguringNTP and SelectingOffsiteNTPServers for more information.
  3. More recent operating systems solve this problem by not using the CPU time stamp counter in the timekeeping APIs, but using the power management timer (or another stable source) instead. The following are known-good configurations in which vairiable clock speed power management and ntpd play nicely together:
    1. ntpd 4.2.0a running on Ubuntu 6.10 (Linux Kernel 2.6.17, ACPI and 'ondemand' processor scaling enabled) running on a Dell 700m (Pentium M 2.0 Ghz, Intel 855GME/ICH4-M Chipset) -- RyanMalayter - 24 Mar 2007

One possible improvement to ntpd would be to detect that the processor is not fixed speed and to block its use. Of course, this would need to be done in a cross-platform manner, which would be a rather non-trivial task.

Help! ntpd has upset my platform's clock:

  • If ntpd has been used on a system with variable clock speed, you are probably observing very wrong clock times. This is due to the drift factor being incorrectly adjusted. To restore the clock to an accuracy of tenths of a second per day see ManualCalibration.

-- ParkerJones - 25 Nov 2004

Dell Inspiron 8100

BIOS version A11 has been reported to cause ntpd instability problems: excessive jitter and offset, rapid time loss 4-5 seconds every minute. It has been reported that, according to research conducted on Google, these problems were caused by apm BIOS calls. Upgrading the BIOS to version A15 is reported to cure this problem.

-- SteveKostecke - 05 Nov 2003

Sun Fire V100, Netra X1, etc.

Unpatched Solaris 8 and 9 have serious problems with the time-of-day clocks used in the following models: Netra X1; Sun Blade 1000 and 2000; and Sun Fire V100, 280R, V480, V880, and V880z. To fix these problems in Solaris 8, install patches 112170-02 and 109888-22 (or later); for Solaris 9, install 114338-01 and 114126-02 (or later).

These patches are essential for the above-mentioned models, at least for hosts whose clocks you care about. As usual, these patches depend on other patches (for example, as of 2003-11-26 Sun patch 109888 depends on patches 108528 and 110460) so it may be best to install all the Sun-recommended patches, which you can get from sunsolve.sun.com.

For more information, please see Sun Alert Notification 49016 and Sun bugs 4721451 and 4809862.

While we're on the subject of Netra X1 clocks (why am I thinking of the "troublesome trucks" in Thomas the Tank Engine?), there's also a firmware patch for the Netra X1 that fixes some clock problems. It's Sun patch 111952-03, though I think anything from -01 on should suffice.

-- PaulEggert - 28 Jan 2004

Disable your FIFO for lower jitter with serially-attached refclocks

The FIFO (first-in,first-out) character buffer contained in most modern UART chips (the devices that handle serial port communications) can raise havoc with the performance of reference clocks that send their timestamp via reference to a character in the serial ASCII data stream. Both Linux and FreeBSD provide ways to disable the FIFO, and doing so can make a big difference. The normal jitter of my Spectracom 8170 WWVB clock on a FreeBSD system with NTP v4.1.1 dropped from about 3ms down to a few microseconds with this change.

The method to disable the FIFO varies with the operating system.

Disabling your FIFO under Linux

On Linux, I believe (but I have not verified) that you can disable the FIFO for a serial port by specifying its UART type as an 8250 (which lacks a FIFO) via the setserial command. There is also a setserial option called "low_latency" that claims to remove 5-10ms of delay when set (at the expense of higher CPU utilization) and this may also be interesting to play with.

-- JohnAckermann - 06 Mar 2004

The flag low_latency works and reduces jitter a lot. Specifying the UART as 8250 will reduce the delay. In my case the delay went down about 8 ms. You can use the following command before starting ntpd:

setserial /dev/ttyS0 uart 8250 low_latency

The refclock driver will take care of the other parameters.

-- RuneMagnussen - 28 Feb 2007

Disabling your FIFO under FreeBSD 5.x/6.x

FreeBSD 5.x and newer allow you to pass these options to the driver via the /boot/device.hints file. Place your options in this format into /boot/device.hints:


Here are the various flag bits, from the manual page for the sio driver:

     Meaning of flags:
           0x00001   shared IRQs
           0x00002   disable FIFO
           0x00004   no AST/4 compatible IRQ control register
           0x00008   recover sooner from lost output interrupts
           0x00010   device is potential system console
           0x00020   device is forced to become system console
           0x00040   device is reserved for low-level IO (e. g. for remote
                     kernel debugging)
           0x00080   use this port for remote kernel debugging
           0x0??00   minor number of master port
           0x20000   device is assumed to use a 16650A-type (extended FIFO)

Alter the flag option for the serial device to include the 0x00002 bit, and any others you need. Settings may be confirmed by checking dmesg after startup for syslog entries that confirm the flags value in use.

-- MajdiAbbas - 07 Jul 2006

Disabling your FIFO under older versions of FreeBSD

Prior to FreeBSD 5.0, this would be accomplished by adding or changing the flags parameter in the configuration file used to build the kernel.

The following lines appear in the GENERIC kernel configuration file under FreeBSD 4.10:

# Serial (COM) ports
device          sio0    at isa? port IO_COM1 flags 0x10 irq 4
device          sio1    at isa? port IO_COM2 irq 3

Here are the various flags, from the manual page for the sio driver:

     Meaning of flags:
           0x00001   shared IRQs
           0x00002   disable FIFO
           0x00004   no AST/4 compatible IRQ control register
           0x00008   recover sooner from lost output interrupts
           0x00010   device is potential system console
           0x00020   device is forced to become system console
           0x00040   device is reserved for low-level IO (e. g. for remote
                     kernel debugging)
           0x00080   use this port for remote kernel debugging
           0x0??00   minor number of master port
           0x20000   device is assumed to use a 16650A-type (extended FIFO)

Alter the flag option for the serial device to include the 0x00002 bit, then rebuild and install your kernel. Confirm these settings with the output of dmesg after startup.

-- MajdiAbbas - 07 Jul 2006

Mac Mini (and other machines having poor TICK settings)

With default adjtimex values of TICK=10000 and FREQ=0, Mac Minis (and possibly other G4 systems, as well as some systems using other CPU architectures, such as Intel x86) can lose 8-12 seconds off their clock every hour. This will cause problems for ntpd, as it has a max drift threshold of about 43 seconds a day. The solution is to install adjtimex and calculate a more accurate TICK setting for your particular Mini. For Debian GNU/Linux 3.1-ppc (Sarge), the adjtimexconfig command is NOT reliable. Consider a script like the following:

hwclock -w
echo 'Starting at '`date` > $LOGFILE
echo >> $LOGFILE

for i in 1 2 3 4 5; do
  sleep 3600
  echo "After $i hours" >> $LOGFILE
  clock | head -n 1 >> $LOGFILE
  echo "   sysclock is "`date -u` >> $LOGFILE
  echo >> $LOGFILE

Take the difference in seconds after five hours and divide by 1.8 to get the change in ticks. After five hours, my hardware clock time minus system clock time was 54 seconds. 54/1.8=30 so I add 30 ticks to the nominal value of 10000, and run adjtimex --tick 10030. Following this change, run the above script again. This second time, the difference between hardware and system clocks should be less than 2 seconds after five hours. If so, save the new value of TICK in your system configuration files so they will be saved for future reboots.

Another user talks about the same technique here: https://lists.debian.org...

See also ManualCalibration for a slightly different take on this same concept.

-- MichaelLee - 21 Aug 2005

nForce2 motherboards: HAL issues and FSB Spread Spectrum

If you are using a motherboard with an nForce2 chipset, and NTP won't keep time well, it may be that it is failing to synchronise because the system clock is too unstable. There have been reports of recurrent problems with erratic system clocks on nForce2 motherboards.

HAL issues

Under Windows XP (and 2000), one possible solution is to use a different HAL (Hardware Abstraction Layer). In one case, the problem was solved by switching from "ACPI Uniprocessor PC" to "Advanced Configuration and Power Interface (ACPI) PC".

Available HALs are documented at https://support.microsoft.com/?kbid=309283.

It may be that this HAL change works because it disables the APIC (Advanced Programmable Interrupt Controller): see APIC and ACPI.

Warning: changing HALs is risky: it should not be done without careful reflection and a willingness to reinstall Windows if something goes wrong.

This site (in German) gives some more information: https://www.planet3dnow.de/artikel/diverses/nf2config/3.shtml#config_apic

Moral of the story: if NTP seems to stop working properly and you have an nForce2 motherboard (a) the problem is quite possibly not NTP and (b) you may not need a new motherboard...

FSB Spread Spectrum

nForce2 motherboards have a BIOS option called "FSB Spread Spectrum", which affects the FSB (Front Side Bus) frequency a way which might affect the stability of the system clock.

Some initial observations for combinations of HAL and FSB Spread Spectrum settings are:

Motherboard: A7N8X-X (nForce2) Windows XP SP 2

HAL DLL HAL uses APIC FSB Spread Spectrum System clock result NTP result
ACPI Uniprocessor PC halaacpi.dll yes 0.50% unstable did not synchronise
ACPI Uniprocessor PC halaacpi.dll yes disabled unstable did not synchronise
Advanced Configuration and Power Interface (ACPI) PC halacpi.dll no 0.50% stable synchronised
Advanced Configuration and Power Interface (ACPI) PC halacpi.dll no disabled stable synchronised

This evidence is somewhat anecdotal, but it seems that FSB Spread Spectrum may not make a big difference.

It should be mentioned that according to the Microsoft KB article https://support.microsoft.com/?kbid=821893 there is a quite fundamental difference between the two DLLs:

Halaacpi.dll: uses the Real Time Clock (RTC) to generate clock interrupts (note: the KB article actually says Halaapic.dll, but I assume this is a misprint, since as far as I know there is no such .dll file in Windows XP)

Halacpi.dll: uses the 8254 Programmable Interval Timer (PIT) to generate clock interrupts

-- JohnAllen - 17 Dec 2005 (minor correction 15 Apr 2007)

PPS signals via RS-232 serial port

If using a serial port for a PPS signal, the width of the PPS pulse provided by some sources may be too short to register. If possible, changing the polarity may make a difference. For example, when using a Trimble Thunderbolt source, the PPS pulse is approximately 10-20 us wide. It has been observed that a negative-going RS-232 signal can work when a positive-going one does not. If possible, inverting the polarity at the source may avoid the need for a hardware pulse stretcher.

-- MikeS - 2011-01-17
Topic revision: r28 - 04 Oct 2022, TodaysTest
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.