Re: [PATCH v2 0/2] clk: add clk accuracy support

Re: [PATCH v2 0/2] clk: add clk accuracy support

[colin]

Um, do you have a definition somewhere (like in comments) of the definition
of the accuracy you're using?  So multiple people can add consistent values?

Is this the standard deviation (67% confidence), 2 standard deviations
(95%), 3 (99%), or something else?

What averaging time is this computed over?  Usually clock stability (which
I recognize is not accuracy) is expressed using the Allan deviation,

http://tf.nist.gov/general/glossary.htm#allandeviation

This is because real clocks have unbounded asymptotic error.  Over long
time intervals, have a random frequency walk characteristic, where the
frequency error after time T is proportional to sqrt(T).

So an oscillator which is stable to 1ppb over a T second interval will be
stable to 2ppb over a 4T second interval, 3ppb over a 9T second interval,
and so on.

Since accuracy is limited by stability, and there's no upper bound on
instability, there's actually no upper bound on inaccuracy, either.

(Admittedly, your typical crystal oscillators have their stability
limited by environmental instability, particularly temperature, which
dwarfs the frequency flicker noise limit.)


On the flip side, some systems are synchronized to UTC by various means.
This means (if we either neglect UTC's far sub-ppb instability, or just
define it as "perfect") that the inaccuracy over a long enough averaging
interval is zero.

But if it only synchronizes once a day, there can be significant
inaccuracy between synchronization.  Should the accuracy specification
reflect that shorter-term instability?


Finally, you can't specify *too* short an interval, because clocks also
have increasing error over small time intervals.  Below 10 seconds or
so, white noise cycle-to-cycle jitter dominates, and the fewer cycles
you average over, the larger it appears to be.


A clear definition would help people understand what numbers to put in.

Re: [PATCH v2 0/2] clk: add clk accuracy support

[boris brezillon]

Hello,

On 28/11/2013 00:11, colin@horizon.com wrote:
> Um, do you have a definition somewhere (like in comments) of the definition
> of the accuracy you're using?  So multiple people can add consistent values?
>
> Is this the standard deviation (67% confidence), 2 standard deviations
> (95%), 3 (99%), or something else?
>
> What averaging time is this computed over?  Usually clock stability (which
> I recognize is not accuracy) is expressed using the Allan deviation,
>
> http://tf.nist.gov/general/glossary.htm#allandeviation
>
> This is because real clocks have unbounded asymptotic error.  Over long
> time intervals, have a random frequency walk characteristic, where the
> frequency error after time T is proportional to sqrt(T).
>
> So an oscillator which is stable to 1ppb over a T second interval will be
> stable to 2ppb over a 4T second interval, 3ppb over a 9T second interval,
> and so on.
>
> Since accuracy is limited by stability, and there's no upper bound on
> instability, there's actually no upper bound on inaccuracy, either.
>
> (Admittedly, your typical crystal oscillators have their stability
> limited by environmental instability, particularly temperature, which
> dwarfs the frequency flicker noise limit.)
>
>
> On the flip side, some systems are synchronized to UTC by various means.
> This means (if we either neglect UTC's far sub-ppb instability, or just
> define it as "perfect") that the inaccuracy over a long enough averaging
> interval is zero.
>
> But if it only synchronizes once a day, there can be significant
> inaccuracy between synchronization.  Should the accuracy specification
> reflect that shorter-term instability?
>
>
> Finally, you can't specify *too* short an interval, because clocks also
> have increasing error over small time intervals.  Below 10 seconds or
> so, white noise cycle-to-cycle jitter dominates, and the fewer cycles
> you average over, the larger it appears to be.
>
>
> A clear definition would help people understand what numbers to put in.

Thanks for these informations, it helped me understand the different sources
of inaccuracies of a crystal.
As I said earlier, I'm not an expert in this area, and all your comments and
feedbacks are welcome.
BTW does this apply to other clk generators (RC oscillators, PLLs, ...), 
or is this only
applicable to crystal oscillators ?

Regarding the exact definition of accuracy, I guess in case of crystals 
this has more
to do with stability.

I found something called "Total stability" in several datasheet
(e.g. http://www.silabs.com/Support%20Documents/TechnicalDocs/si510-11.pdf).
Is this something applicable to our case ?

Keep in mind that the primary goal of the clk accuracy retrieval is to 
give a clock
user a way to choose the most accurate clock among several available clocks.
This means we don't need the value to be extremely precise, but at least 
(as you
stated) these values should represent the same things.

Best Regards,

Boris

[PATCH v2 0/2] clk: add clk accuracy support

[Boris BREZILLON]

Hello,

This patch series adds support for clock accuracy retrieval in the common clk
framework.

Best Regards,

Boris

Changes since v1:
 - remove HAVE_CLK_GET_ACCURACY option and enable clk accuracy support only
   when using the CCF
 - export __clk_get_accuracy (might be used by clk-providers)
 - fix documentation (s/recalc_rate/recalc_accuracy/)
 - move fixed_accuracy field addition (struct clk_fixed_rate) from the 1st
   patch to the 2nd patch of this series

Boris BREZILLON (2):
  clk: add clk accuracy retrieval support
  clk: add accuracy support for fixed clock

 Documentation/clk.txt                              |    4 +
 .../devicetree/bindings/clock/fixed-clock.txt      |    3 +
 drivers/clk/clk-fixed-rate.c                       |   43 ++++++--
 drivers/clk/clk.c                                  |  109 +++++++++++++++++++-
 include/linux/clk-private.h                        |    1 +
 include/linux/clk-provider.h                       |   15 +++
 include/linux/clk.h                                |   17 +++
 7 files changed, 182 insertions(+), 10 deletions(-)

-- 
1.7.9.5