On Tue, Nov 13, 2012 at 9:24 PM, <gbusenb...@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 10.1.126.204 iburst minpoll 5 > server 127.127.1.0 > fudge 127.127.1.0 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 http://davehart.net/ntp/win/x86. 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. Cheers, Dave Hart Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions