[ntp:questions] Loop Frequency and Offset
mail at miguelgoncalves.com
Tue Sep 27 10:42:14 UTC 2011
On 27 September 2011 10:35, David Woolley <david at ex.djwhome.demon.invalid>wrote:
> Applying a static correction to the clock frequency only helps if the
> static error is close to or greater than 500ppm. However, if that is the
> case, the right thing to do is to replace the motherboard, with a better one
> as it is likely that the clock is unstable as well as having a high static
One had 180 ppm sand the other 46 ppm without fiddling with machdep.tsc_freq
sysctl variable. After the correction I am getting -0.041 ppm for the first
and -0.045 ppm for the second.
> performance? The machines I have at the moment are showing worse than 1 us
>> performance perhaps because I am not using GPS timing receivers.
> Make sure the system is only used as a time server. Keep its temperature
> very constant. Disable any form of power management (in particular variable
> clock rates). Disable spread spectrum clocks.
Embedded machines running NanoBSD and they don't do anything else besides
running NTP. They sit in a temperature controlled room at 20 ºC. Power
management has been disabled. I checked the BIOS and did not see any
reference to spectrum clocks.
> Calibrate the systematic error by outputting a hardware pulse within the
> kernel at a precisely known system clock time and using hardware to measure
> the offset from the PPS input pulse. You will need to also output the
> system time at which you did this, but that needn't be in real time.
> Do not try to do this on the second.
Makes sense... I'll investigate a way of doing this.
> I know... :-) My cable connection is really bad for NTP... I can't get
>> better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite.
> Reading that as 3ms. The time you serve will have that sort of jitter in,
> it so there is little point in being accurate to better than about 100
> microseconds of jitter/wander.
You read well :-)
More information about the questions