[ntp:questions] Re: Ntpd time offset threshold

David Woolley david at djwhome.demon.co.uk
Thu Jun 9 19:51:33 UTC 2005

In article <mailman.82.1118307363.91305.questions at lists.ntp.isc.org>,
Eric Liu <EricLiu at moxrd.com> wrote:

> The offset threhold is 128ms by default. I think it is a so large value.
> I want 1ms accuracy among all clients over LAN. So, do I have to set it to a
> smaller value? As for 1ms accuracy, set it to 0.5ms.

You DO NOT want to do that.  The 128ms is a panic threshold after which
ntpd starts taking drastic measures to work round a presumed broken
time source.  It will take around quarter of hour to do so and throw
away most of what it has learned.  If you set this value any less than
30ms on the system you have, it will really start to have bad times on
the clients.  (Also, setting many of these sort of parameters, turns off
the more sophisticated algorithms.)

The single most important thing you can do is to eliminate Windows
completely from any timing critical part of the system.  If you are
running any application on Windows that needs better than 20ms (more
realistically 40ms) accuracy, you have made a fundamental design
error, or you know so much about timekeeping software that you
wouldn't be asking these questions.

The next thing you need to do is to do a thorough interrupt and
scheduling latency analysis on the PC 104 systems, to make sure that
whatever external event you are measuring to 1ms accuracy actually 
will cause the code that reads the clock to be scheduled in rather
less than 1ms.

You should then do a similar analysis on the LAN, to ensure that LAN
induced jitter on NTP packets is acceptable.  Operating in broadcast
mode may be advantageous, if you have a broadcast network, as all the
client will see the same jitter pattern.

What you do next depends on the maximum time between measurements for
which you need 1ms accuracy.  If it's of the order of a second or less,
you can use the local clock on a Linux or FreeBSD machine, dedicated
as a timeserver.   If you are measuring over extended periods, you will
need a true UTC time source.

As noted before, offset represents sampling variations, it doesn't measure
the true clock error.

PS Please note that this mailing list is gatewayed to USENET and USENET
is the primary forum.  Although the gateway is known to be broken, you
should still not keep starting explicit new threads.  The gateway manages
to break threads without anyone's help!  If at all possible, use the
USENET forum directly, or through Google groups.

More information about the questions mailing list