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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	27 Nov 2013 18:11:25 -0500
From:	colin@...izon.com
To:	b.brezillon@...rkiz.com
Cc:	devicetree@...r.kernel.org, linux@...izon.com,
	linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] clk: add clk accuracy support

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/