[chrony-users] chronyc tracking question |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: [chrony-users] chronyc tracking question
- From: Chris Perl <cperl@xxxxxxxxxxxxxx>
- Date: Wed, 19 Apr 2017 14:34:21 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=8kavmW/eDCGjJX+ZKHWDTdlCNrnpX+OGWArFVog04KU=; b=s10c1bdXGEqBfWyYX2pqePTS4U11pQWlaIFOu5abRBgZ2lMRkU67tAQ6M21G4qzxwk gx1Kj3fSTdXjw4G5rOFsIR6c06IFCGhCYGbG2taETzA3CV9V3AQmxvYLwuF0g+xzYWzX uGemcx3mqHqIMFPdG/wpbTYUhbEpWGXjykEc0=
I'm trying to figure out what metric(s) from `chronyc tracking' I
should be logging and graphing to answer the question of "how far off
is my system from its reference".
I believe the "Last offset" field is the most recent offset that
chrony has received from the source that it has selected to
synchronize from (e.g. the `SRC_Instance' which is `SRC_SELECTED').
So, if you were running `chronyc tracking' in a loop and tailing
`tracking.log', I think this field should line up with the "Offset"
column from the tracking file.
I also believe that the "System time" field represents chrony's notion
of how far the system clock is off from the "true" time. And that its
the samples from the sources that allow chrony to update its notion of
the "true" time.
I've been doing some testing, purposely attempting to cram 10 Gb/s
worth of traffic into a 1 Gb/s host running chrony-3.1 (from the
release tarball) at irregular intervals.
As one might expect, this causes lots of variability in the delay
measurements, and causes "test C" to fail a bunch of the time (as
indicated in the `measurements.log' file). This is obviously good and
by design to stop chrony from using bogus samples and jumping all over
the place (and I believe can be controlled by adjusting
`maxdelaydevratio').
What I've observed is that if chrony can't get a good sample for a
long period of time (with chrony polling every second, say it can't
get a sample to pass "test C" for something like 60s), the "System
time" is driven to zero.
Is the gist something like the following?
The System time field from `chronyc tracking' represents the
difference between what chrony believes the "true" time to be and the
system time. But, chrony is constantly updating its notion of what
the "true" time is. In the absence of updates, it simply does its job
and drives that difference to 0.
If that is true, does that mean that I should be graphing the "System
time", but that I need to be sure I've got sufficiently fresh samples
to make sure the notion of the "true" time is correct? Or, should I
just be graphing the "Last offset", or perhaps something else
entirely?
Obviously I don't expect chrony to run like this in a real world
scenario, I'm just trying to test out some of the worst cases.
--
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.