EditWYSIWYGAttachPrintable

r25 - 2013-06-29 - 22:38:37 - HarlanStennYou are here: NTP >  Support Web > WebOrder > KnownHardwareIssues

NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to use in a distributed denial-of-service (DDoS) attack. Please also take this opportunity to defeat denial-of-service attacks by implementing ingress and Egress filtering through BCP38.

ntp-4.2.8p2, released on 7 April 2015, addresses two issues with crafted packets involving symmetric key encryption and Message Authentication Codes.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

See KnownHardwareIssuesDev for discussion of this topic.

9.1. Known Hardware Issues

9.1.1. APIC and ACPI

9.1.2. Variable Speed Processors

9.1.3. Dell Inspiron 8100

9.1.4. Sun Fire V100, Netra X1, etc.

9.1.5. Disable your FIFO for lower jitter with serially-attached refclocks

9.1.5.1. Disabling your FIFO under Linux

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

9.1.5.3. Disabling your FIFO under older versions of FreeBSD

9.1.6. Mac Mini (and other machines having poor TICK settings)

9.1.7. nForce2 motherboards: HAL issues and FSB Spread Spectrum

9.1.8. PPS signals via RS-232 serial port

9.1.1. APIC and ACPI

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

9.1.2. 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:

<Time problems with embedded Linux system (offset does not stabilize>

<ntp, adjtimex, etc.>

<MAXDISPERSE is too high! was Re: is there a way to "lock" thedrift frequency>

Solutions:

Lock the frequency of the processor. Obviously the benefits of reduced power consumption and dynamically adjusting to workload will be lost.

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.

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:

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

9.1.3. 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

9.1.4. 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

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.

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

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:

hint.sio.0.at="isa"
hint.sio.0.port="0x3f8"
hint.sio.0.flags="0x10"
hint.sio.0.irq="4"

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)
chip

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

9.1.5.3. 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)
chip

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

9.1.6. 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:

#!/bin/bash
hwclock -w
LOGFILE="/tmp/driftlog"
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
done

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: http://lists.debian.org...

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

-- MichaelLee - 21 Aug 2005

9.1.7. 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, e.g., these threads:

http://www.nforcershq.com/forum/1-vt19631.html

http://kerneltrap.org/node/4872

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 http://support.microsoft.com/?kbid=309283.

It may be that this HAL change works because it disables the APIC (Advanced Programmable Interrupt Controller): see 9.1.1. 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: http://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 http://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)

9.1.8. 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

WebForm

NtpVersion

NtpFourTwo

OperatingSystem

OsLinux, OsWin

OsVersion

2.6.17

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r25 < r24 < r23 < r22 < r21 | More topic actions

Support

Log In or Register

Support Web

Quick Start

Installation

Configuration

Operation

Troubleshooting

FAQ

Background

Index

Bugs & Issues

Documentation

Donations

Mailing Lists

Time Servers

Changes

Index

Notify

Search

Statistics

Users

SSL ON

SSL OFF

Webs

Main

NTP Support

Time Servers

Development

Site Users

System

Sandbox

Committers

Operations

Site Staff

Security

Copyright &© 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback