[ntp:questions] What prevents continuous time within an operating system ?
Brian.Inglis at SystematicSw.ab.ca
Fri Jan 22 14:57:00 UTC 2016
On 2016-01-22 05:05, Charles Elliott wrote:
>> Affinity is best set to CPU (nprocs-1) to minimize cache thrashing, and
> ensure that time stamps >are consistent, as not all systems sync their
> clocks across all CPUs at startup, leading to skews >between time stamps
> from different CPUs.
> My bosses will not let me do this, citing:
> 1. There is little if any evidence that limiting NTPD to one CPU is
> 2. NTPD's main loop experiences between 1 and 7 context switches a second.
> Two other threads run
> sporadically, but apparently at no fixed frequency, one of them very
> often. Two threads, on
> Windows, just sit there. One can see this with Process Explorer. This
> implies two
> A. Occasionally, NTPD needs more than one CPU simultaneously.
> B. When NTPD requests a CPU, and another process at a lower priority owns
> NTPD's assigned CPU,
> then NTPD has to wait one time slice for access. It is called priority
> inversion and is the
> bane of systems everywhere.
> In addition, it is not clear to me that limiting NTPD to one CPU is NTP
> official policy.
> Do you have any hard evidence that limiting NTPD to one CPU has any
> beneficial impact?
I have managed to keep a Windows system running stable for a couple of years now
with a Garmin 18xLVC and NMEA user mode PPS, as PPSAPI unsupported on PCI serial,
and approx stats:
offset <1us 50us
jitter 15us 30us
drift 1ppm 1.01ppm
wander 0.2ppb 0.4ppb.
Prior to that I kept the same system with only network sources within ~20us,
once poll stabilized at 1024s, but the ref clock bug hit fairly soon.
Power management and spread spectrum frequency fuzzing is switched off in the BIOS,
and the OS runs a performance power management policy.
I have so far resisted becoming a time nut with Rb and Cs clocks requiring use
of a soldering iron.
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
More information about the questions