chance of getting a solution.
cpu, to hibernation, etc. Ie, I am not at all sure that the tsc is as good a
"clock" as you think. I would trust the the chrony time more than the txc
counter.
flakey. Don't do it. If someone puts a bullet through your computer, the tsc
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
On Fri, 11 May 2018, Hei Chan wrote:
> 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.
> > >
> > >
> >
> >
>
>