Re: Proposal for kernel clock changes

[David Laight <david%l8s.co.uk@localhost>]

On Fri, Mar 28, 2014 at 06:16:23PM -0400, Dennis Ferguson wrote:
> I would like to rework the clock support in the kernel a bit to correct
> some deficiencies which exist now, and to provide new functionality.  The
> issues I would like to try to address include:

A few comments, I've deleted the body so they aren't hidden!

One problem I do see is knowing which counter to trust most.
You are trying to cross synchronise values and it might be that
the clock with the best long term accuracy is a very slow one
with a lot of jitter (NTP over dialup anyone?).
Whereas the fastest clock is likely to have the least jitter, but
may not have the long term stability.

There are places where you are only interested in the difference
between timestamps - rather than needing them converting to absolute
times.

I also wonder whether there are timestamps for which you are never
really interested in the absolute accuracy of old values.
Possibly because 'old' timestamps will already have been converted
to some other clock.
This might be the case for ethernet packet timestamps, you may want
to be able to synchronise the timestamps from different interfaces,
but you may not be interested in the absolute accuracy of timestamps
from packets takem several hours ago.

This may mean that you can (effectively) count the ticks on all your
clocks since 'boot' and then scale the frequency of each to give the
same 'time since boot' - even though that will slightly change the
relationship between old timestamps taken on different clocks.
Possibly you do need a small offset for each clock to avoid
discrepencies in the 'current time' when you recalculate the clocks
frequency.

If the 128bit divides are being done to generate corrected frequences,
it might be that you can use the error term to adjust the current value
- and remove the need for the divide at all (after the initial setup).

One thought I've sometimes had is that, instead of trying to synchronise
the TSC counters in an SMP system, move them as far from each other
as possible!
Then, when you read the TSC, you can tell from the value which cpu
it must have come from!

        David