[ntp:questions] What prevents continuous time within an operating system ?

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Mon Feb 15 03:10:01 UTC 2016

On 2016-02-14 14:26, MAYER Hans wrote:
> 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
> 720000
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
> 720000
> # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
> 720000
> 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 ?

Linux	taskset -c 1	 .../ntpd ...
Solaris	pbind -b -c 1 -e .../ntpd ...
BSD	schedctl -A 1	 .../ntpd ...


Watch out for commands like BSD/Solaris psrset, cpuset which may which dedicate exclusive use of a processor to a process!

Change /etc/init.d/ntp{,d} etc.
Your OS/distro startup commands may require working around.
You should conform to whatever approach your system setup uses for daemon startup config defaults.
Most support various tuning options *excluding* affinity.
You may also want to set some of those other startup options such as scheduling class FIFO and priority MAX.
Except at startup, ntpd mainly sleeps between timed polls, and handling ref clock and network I/O interrupts.
Your NIC will get hot from traffic before your CPU from ntpd load, and only if you provide NTP service to a lot of clients.

>>                 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.

Jitter is the short term error bound for offset, as wander is for drift: my interpretation is that it is the variation in the sampling on your system, possibly due to interrupts.

> 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 )

What does drift look like on the same scale?
Your loopstats should look identical to your ref clock peerstats if everything is set up and operating properly.
Could it be solar and/or programmed thermostat heating, assuming you are in a time zone near UTC, or showing local time?
Accurate clocks are good thermometers; environmentally controlled accurate clocks are good gravimeters and seismometers. ;^>

May want to reduce ref clock min/maxpoll to 4 and increase network minpoll to 6 (default) or higher.

At a lower level, ensure you are not requesting or sending too much data from your receiver to gpsd for the transmission medium, and are always sending the same messages after every PPS, preferably only the timing basics.
Having a bunch of GPS almanac or other irregularly available data dumped every so often will adversely impact timekeeping!

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

More information about the questions mailing list