Hi Bill,
Really appreciate your reply.
I removed the group to avoid spamming the group too much as my use case is a bit
unique/dumb.
Yes, invariant TSC only means that the frequency won't change due to power, ACPI, etc.
But due to the physical property as you stated, temperature might affect TSC frequency.
And this is exactly why I would like to do some estimate of time based on TSC +
clock_getttime().
Here is my use case:
- I use rdtsc(p) (+CPUID) everywhere to stamp all the event happens in my application
and store somewhere (e.g. db, file, etc)
- Then, I would like to convert them back to timestamp.
You would wonder why I don't call clock_gettime() directly because
clock_gettime(CLOCK_REALTIME) has a while loop inside and occasionally it will fail and
then it will loop for quite some time before returning the time.
I am trying to avoid this kind of jitter in my application but at the same time, I
would like to have as accurate as possible timestamp without PTP (my data center
doesn't have PTP and disallow setting my own GPS clock).
So basically no jitter and low latency are more important to me than accuracy of
timestamp. Hence, I sacrifice the accuracy by a bit, in return I get no jitter and low
latency.
Hope the picture is more complete now :)
On Friday, May 11, 2018, 11:10:26 AM GMT+8, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
I guess I am still confused. The system clock usually uses something like the
tsc as the clock, and all chrony does is to change the interpretation (clicks
per second) of that reading. Now you want to use the system time to determine
the clicks per second of the tsc? Ie, it is unclear to me why you want to do
this.
It is of course true that your system might use another clock (HPET,...) whose
clicks it counts and interprets to get the system time.
You might want to look at the reports from adjtimex to see what the relation
is between the hardware and the time.
Note that the tsc is not invariant. it depends on the computer's crystal which
can speed up and slow down as temperature changes, or other things
From wikipedia Time_Stamp_counter
" The Time Stamp Counter was once an excellent high-resolution, low-overhead
way for a program to get CPU timing information. With the advent of
multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating
operating systems, the TSC cannot be relied upon to provide accurate results
--unless great care is taken to correct the possible flaws: rate of tick
and whether all cores (processors) have identical values in their time-keeping
registers. There is no promise that the timestamp counters of multiple CPUs on
a single motherboard will be synchronized. Therefore, a program can get
reliable results only by limiting itself to run on one specific CPU. Even
then, the CPU speed may change because of power-saving measures taken by the
OS or BIOS, or the system may be hibernated and later resumed, resetting the
TSC. In those latter cases, to stay relevant, the program must re-calibrate
the counter periodically."
So, again it would seem to be better to just use the system time, disciplined
by chrony. But then I may be misinterpreting completely what you want to do.
On Fri, 11 May 2018, Hei Chan wrote:
> Hi Bill,
>
> Sorry that I wasn't clear.
>
> What I tried to do is to call clock_gettime() and rdtsc(p) as soon as chrony finishes
> synch so that I can get the best estimate when I try to derive time from (invariant)
> tsc.
>
> Ideally, I have a C application that calls chrony's API (if there is one) similar to
> "chronyd -q" to block till it finishes or gets a callback.
>
> Any suggestion?
>
> On Thursday, May 10, 2018, 10:05:04 PM GMT+8, Bill Unruh <unruh@xxxxxxxxxxxxxx>
wrote:
>
>
> I am not sure what you mean. chrony syncs constantly, and once it is running,
> it, unless some disaster comes along, like you deciding to "test" it by
> changing the clock out from under chrony, it will keep the clock within the
> tightest bounds possible given the server/refclock it uses.
> Just leave it be, and it will have your clock synced to the source as well as
> possible. So, I am not sure what you have in mind. So, if you could tell us
> what problem you are trying to fix, rather than asking what the best solution
> to an unknown problem is, it would make answering much easier.
>
>
> William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
> Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
>
> On Thu, 10 May 2018, Hei Chan wrote:
>
> > Thanks Miroslav and Bill!
> >
> > One last related question -- how can I be able to tell the sync/calibration is done
> > after I manually ask chrony to synch/calibrate?
> >
> > I saw one of the posts 4 years ago suggesting that there is no way?
> >
> > Which command is better to force chrony to synchronize time right now -- chronyc
> burst
> > or chronyc waitsync?
> >
> > WHICH COMMAND IS BETTER TO FORCE CHRONY TO SYNCHRONIZE TIME RIGHT NOW --...
> >
> >
> > Or even better -- is there a way that I can call through a C API and get a callback
> or
> > get blocked after it is done?
> >
> > Thanks!
> >
> > On Wednesday, May 9, 2018, 2:58:44 PM GMT+8, Bill Unruh <unruh@xxxxxxxxxxxxxx>
wrote:
> >
> >
> >
> >
> > William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
> > Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
> > UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> > Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
> >
> > On Wed, 9 May 2018, Miroslav Lichvar wrote:
> >
> > > On Sun, May 06, 2018 at 10:30:48AM +0000, Hei Chan wrote:
> > >> Hi,
> > >> I am reading this:https://chrony.tuxfamily.org/manual.html#makestep-command
> > >> It mentions, "Normally chronyd will cause the system to gradually correct any
time
> > offset, by slowing down or speeding up the clock as required". Most of the Linux
> > machines are using TSC as the source:$ cat
> > /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
> > >> Given a machine using TSC as the clock source and new Intel CPUs have invariant
> TSC,
> > how can chrony slow down or speed up the clock? I am sure I misunderstand the doc.
> > >
> > > The clocksources don't change their frequency. It's the software
> > > system clock maintained by the kernel, whose frequency is adjusted by
> > > the adjtimex(2) system call.
> >
> > To expand, there is counter that counts the pulses in TSC, but those pulses
> > need to be converted into seconds. That conversion factor can get changed by
> > the adjtimex.
> >
> >
>
>