| Re: [chrony-users] makestep in Chrony |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Tue, 15 May 2018, Hei Chan wrote:
Thanks for your reply.
See my comment inline.
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
That is a terrible way of usign chrony. One of the key features of both chrony
and ntpd is that it disciplines not only the offset but also the the rate of
the clock. And the rate can only be determine over a (lengthy ) time period.
Why would you run it like this?
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:
No. See above.
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.
You have a very sophisticated program whose whole purpose is to continuously
set the translation between the tsc and the UTC. And you throw it all away and
use it in the way that Unix time was disciplined 40 years ago.
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.
No idea what this is all about. I have never seen this. If it truely does
this, that is bug, and needs to be reported.
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