[ntp:questions] NTP.ORG MEINBERG KEEP TIME ACCURATE to 10MS

David Woolley david at ex.djwhome.demon.invalid
Tue Nov 13 22:44:33 UTC 2012


gbusenberg at yahoo.com wrote:
[ Very long lines re-flowed ]

 > NTP.ORG MEINBERG KEEP TIME ACCURATE to 10MS

I don't see the relevance of Meinberg.  If you have a software only 
solution, Meinberg only produce the installer, and only for Windows. 
They do produce hardware based solutions.

> I am not sure if this is possible. I have a requirement from a
+ customer that the time must be within 10ms of the parent server which is

If you have a reasonably stable clock on all the machines, and the 
maximum difference in frequency error between any two is significantly 
less than 500ppm, 10ms should be trivially achievable on Unix or Linux 
based systems (you should be one or two orders of magnitude better than 
this).

With an unloaded, modern, Windows, system you should be able to do quite 
a bit better than 10ms.  Loaded Windows systems may be a bit worse, but 
even quite old, loaded, Windows systems were typically within 20ms.

These are actually something like 95 percentile offset values.  The 
actual time should be a few times better.

+ on the same LAN. I have tried several different things without an luck.
+ NTP Time seems to get up to 400ms with defaults.

That sort of error only really happens on an overloaded ADSL connection, 
and if you are getting something like this, the last thing you want to 
do is to tinker stepout.  If anything, you want to increase it, rather 
than reduce it, although huff and puff is the official work round for 
overloaded ADSL.


> 
> I have tried to put the following within my ntp.conf file
> 
> tinker panic 0 step .3 stepout 60

Tinkering is not a good idea until you have the system working well with 
defaults, to provide a baseline.  Ideally you should not tinker.

> driftfile <default>

I don't think <default> is a magic token here, even on Windows, but I 
could be wrong.

> server 10.1.126.204 iburst minpoll 5

You should easily obtain 10ms with the default poll rate limits.

> server 127.127.1.0
> fudge 127.127.1.0 stratum 12

I'm assuming this is a time island, and this is the client 
configuration.  You should not have 127.127.1.0 defined at all.  It may 
well be making the configuration unworkable.

If you have a single machine that defines the local concept of time, and 
which is not synchronised to anything else, or is synchronised by means 
other NTP (but it must still be quality synchronisation, stepping the 
clock to correct it at the beginning of the day doesn't count), it may 
be reasonable to have that with 127.1.0 as its only server.  The clients 
should then have that machine as their only server.

(There are a lot of bad sample configuration files that, 
inappropriately, include 127.127.1.0.)

The normally recommended mechanism for time islands with modern versions 
of ntpd is to use orphan mode, which uses a distributed algorithm to 
choose one machine as the reference source of time.
> 
> If it is not possible to do 10ms, then I want to get the time as
+ close as possible.  I really don't know much about NTP.  I have tried
+ my best to search the web as much as possible however most people
+ inclucding myself never use the tinker other than with panic 0.

Generally you should not use tinker at all.  Given the existence of the 
-g option, there is little excuse for using panic 0, as -g deals with 
any mis-setting at startup and after that a time change of more than the 
default panic setting really indicates that the world is falling to pieces.

step = .3 will degrade time keeping on Linux and probably FreeBSD, as it 
disables the kernel time discipline.  If you are getting 300ms offsets, 
after startup, on a LAN, something is very broken.

stepout = 60 is trying to make ntpd react quickly to something that 
should never happen.  If you think you need it, you need to look closely 
at why you think you need it and try and fix the problem at source. 
Note that NTP is not designed to reliably track time that does not 
progress monotonically at very close to 1 second per second.  It is not 
a mechanism for distributing manual changes in the system clock.



More information about the questions mailing list