On Friday, May 11, 2018, 4:26:14 PM GMT+8, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Fri, May 11, 2018 at 12:30:30AM +0000, 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.
Ok, so the assumption here is that once the system clock is
"synchronized" by chronyd there will be a linear function between the
tsc and system time? And the goal is to have a clock that can be read
in constant time and it doesn't have to be very accurate, but still
track the real time?
Yes to both :)
I'm not sure if that's possible. The tsc is the direct source for the
CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
adjustments, i.e. it's sensitive to temperature changes etc. The
constants of the linear function would have to be periodically updated
and then you would need to deal with locking, which would increase the
maximum latency in the reading of the clock.
Here is the design I am thinking.
I don't have chronyd run in backgroud, and periodically (through cronjob) to issue the command chronyd -q 'pool [some NTP server/switch which is 1 switch away] iburst', then as soon as it returns (the clock is synchronized right?), then I do something like:
s = cpuid + rdtsc
clock_getime(REALTIME_CLOCK, &t)
e = rdtscp + cpuid
Then, log it.
So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.
Then, I can use the map to estimate the TSC frequency every 2 t's with the assumption that t is correct and TSC will change between two t's.
Then, for everything I track with rdtsc, I can estimate the absolute epoch time in nano.
You might question why I don't just have chronyd running in background and call clock_gettime(CLOCK_REATIME, &t) for all the stamping I do with rdtsc. The main issue is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but sometimes, it just fails internally and loops and then take a long time to return.
Any issue you see?
P.S. calling chronyd and creating the map file will be done by one dedicated core at C0 (i.e. off OS scheduler to improve accuracy)
> 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?
There is no C API for chrony (yet). Instead, you could use adjtimex()
and check the frequency and maxerror fields. The maxerror value
increases slowly and drops only when chronyd updates the clock. When
it drops below a threshold and the frequency didn't change
significantly, the system clock could be considered to be
synchronized.
--
Miroslav Lichvar
--
To unsubscribe email
chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email
chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email
listmaster@xxxxxxxxxxxxxxxxxxxx.