[ntp:questions] What prevents continuous time within an operating system ?
mayer at iiasa.ac.at
Sun Feb 14 21:26:59 UTC 2016
Dear Brian, Charles, Leon,
thanks for your feedback.
> Primary (boot) CPU core is normally labelled zero - try:
> less /proc/cpuinfo
> Affinity is best set to CPU (nprocs-1) to minimize cache thrashing,
# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 4 (v7l)
processor : 0
BogoMIPS : 1431.55
processor : 1
BogoMIPS : 1436.46
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 4
Hardware : sun7i
Revision : 0000
Serial : 06c347f74848484880485667165166c8
Is there a way to set 'affinity' in the config ?
Couldn't find anything. Except a discussion in this mailing list years ago about changing source code.
> Many systems nowadays, even single board SoCs, apply power management
> to reduce energy use, so they drop the CPU clock speed, and power down
Yes, I know. My system could do the same.
But I double-checked. max and min cpu governor is set to the same value
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
There should be no way to go to sleep.
Charles, I can follow your arguments. I can't see a disadvantage having a second CPU.
But I can also see Brians argument it would be better to bind ntpd to a specific CPU. But how ?
> median max
> offset <1us 50us
> jitter 15us 30us
> drift 1ppm 1.01ppm
> wander 0.2ppb 0.4ppb.
I have a similar situation.
Offset is between 45 us ( see https://www.flickr.com/photos/138429897@N02/24910748882/in/datetaken/lightbox/ )
RMS Jitter is slightly smaller in my case. It's never below 2 us and almost not higher than 10 us
average is about 4.7 us ( see https://www.flickr.com/photos/138429897@N02/24401948593/in/datetaken/lightbox/ )
This is also not really clear for me, why is RMS jitter so strictly above 1.9 us and never below.
But again looking to the offset.
The system behaves quite normal till around 8:00
and currently offset is about 25 us ahead
( and the reason is not the time source. I have a second one with exactly the same behavior )
and it takes around 6 hours to find back to an offset of 0 us +- ( at around 14:00 )
maxpoll is set to 5 because there was also the comment to reduce the poll intervall. But actually it does not help.
Not enough after 14:00 offset runs into a negative part. Finally after around 22:00 offset was stable. ( Seeing this in the graph of next day, which I didn't upload )
From: questions [questions-bounces+mayer=iiasa.ac.at at lists.ntp.org] On Behalf Of Brian Inglis [Brian.Inglis at SystematicSw.ab.ca]
Sent: Friday, January 22, 2016 3:57 PM
To: NTP Questions
Subject: Re: [ntp:questions] What prevents continuous time within an operating system ?
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
questions mailing list
questions at lists.ntp.org
More information about the questions