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

Charles Elliott elliott.ch at comcast.net
Fri Jan 22 12:05:51 UTC 2016


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

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
    conclusions:
  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?

Charles Elliott

-----Original Message-----
From: questions
[mailto:questions-bounces+elliott.ch=comcast.net at lists.ntp.org] On Behalf Of
Brian Inglis
Sent: Thursday, January 21, 2016 9:01 PM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] What prevents continuous time within an
operating system ?

On 2016-01-20 12:37, MAYER Hans wrote:
>> Set a preferred source to label the PPS ticks e.g. server ... prefer.
>> Add good LAN or nearby internet sources.
>
> Here I can't follow you.
> I have two PPS sources at the same server. The measured offset for 
> each is  typically in a range of +- 5 us ( see image ) Any time source
over the network is much worse.  Typically by a factor of 10.
> And I need this with a poll interval of 64 time seconds or less.
> Finally I don't want to poll a foreign time server in minute intervals.

With PPS sources you also need some GPS or network source(s) to provide UTC
time to "label" the PPS ticks, otherwise the PPS sources can not be used to
discipline UTC time. If a source is marked prefer, and is selected, that
will be used to provide the UTC "label" for the PPS interrupt.
Any selected network source is better than the alternative of using the
local clock driver and the "wristwatch and eyeball" method of setting the
system time, or using an RTC if your system even has one.

>> Have you set affinity for ntpd or is it pinned to a non-zero CPU to 
>> reduce contention?
>
> What do you mean ?  Never heard "non-zero CPU"
> I googled a little bit but results didn't make sense for me.

Primary (boot) CPU core is normally labelled zero - try:
	less /proc/cpuinfo
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.

>> Have or can you disable any power management features?
>
> There is nothing like this. Always running, always idle.

Many systems nowadays, even single board SoCs, apply power management to
reduce energy use, so they drop the CPU clock speed, and power down internal
components, when they become idle, causing variations in timing, and delays
coming out of "sleep" states, which make it difficult for ntpd to correctly
estimate the CPU clock frequency drift. To reduce RFI at the clock
frequency, they may also vary the clock frequency randomly, often called
"Spread Spectrum", which allows them to pass government RFI interference
tests that could restrict their use from retail or commercial premises. For
example, you may not want to run a system with a 1.5GHz clock (or
submultiple) near a GPS receiver!

These "green" power saving features can often be disabled in the BIOS or
system configuration by digging into "advanced" menus and checking config
docs.

Newer AMD/Intel systems have a time stamp counter (TSC) which is invariant
(/proc/cpuinfo should show ...constant_tsc...nonstop_tsc) regardless of the
CPU power management state. Some BIOSes/OSes/clock drivers can sync the TSC
values across cores on the same socket at startup, and may set up machine
status registers (TSC AUX MSRs) with identifiers or offsets per CPU,
readable using recently added instructions.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
_______________________________________________
questions mailing list
questions at lists.ntp.org
http://lists.ntp.org/listinfo/questions



More information about the questions mailing list