Dave Hart davehart at gmail.com
Tue Nov 13 23:11:16 UTC 2012

On Tue, Nov 13, 2012 at 9:24 PM,  <gbusenberg at yahoo.com> wrote:
> 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 on the same LAN.  I have tried several different things without an luck.  NTP Time seems to get up to 400ms with defaults.
> I have tried to put the following within my ntp.conf file
> tinker panic 0 step .3 stepout 60
> driftfile <default>
> server iburst minpoll 5
> server
> fudge stratum 12
> 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.

Since you mention Meinberg, I'm guessing you're using the Meinberg
Windows ntpd installer?  The latest version they offer is based on
code that's quite a few years out of date, and in particular is
missing a re-write of the Windows-specific clock interpolation that
gives ntpd on Windows reasonable precision (as opposed to the native
Windows clock precision which is often 15.6 msec).  Assuming so, what
version of Windows are you using it with?  If it's Windows XP/2003 or
earlier, you can likely improve the results you see by picking up a
set of binaries for a more recent ntpd version from

Vista and later versions of Windows are more challenging if the system
clock ticks more frequently than every 10 msec.  Most of the systems
running newer Windows default to ticking the system clock every 15.6
msec at startup, but may reduce that to every 1.0 or 0.5 msec by the
time an interactive user runs certain timing-sensitive
(audio/multimedia) programs or runtimes (e.g. Flash, Java).  That has
two deleterious effects -- first, the interpolation will not work (and
is disabled in ntpd 4.2.6 and later if the problematic clock rate is
in effect at its startup) so at best the precision is the same as the
Windows clock, around 1 msec.  Secondly and so far unresolved, the
SetSystemTimeAdjustment API on Vista and later has a serious bug in
that it silently rounds the requested change per tick as the API
"pretends" the clock rate is fixed when starting with Vista it can
change rate after startup.  ntpd feeds small changes which get rounded
away if the rate is increased, until the clock gets far enough off
that the requested slew is big enough to not be rounded, by which
point ntpd is overreacting and the clock discipline loop is
destabilized.  Fixing this would be easiest if Microsoft changes
GetSystemTimeAdjustment from simply parroting what Set... was fed to
reporting the effective value after rounding -- otherwise, ntpd is
stuck trying to infer the effective clock tick size on an ongoing
basis, so the rounding can be anticipated and worked around.

Dave Hart

Dave Hart

More information about the questions mailing list