netdev - Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock 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-prev] [day] [month] [year] [list]

Message-Id: <20101001.194450.1113329769525619655.imp@bsdimp.com>
Date:	Fri, 01 Oct 2010 19:44:50 -0600 (MDT)
From:	"M. Warner Losh" <imp@...imp.com>
To:	cl@...ux.com
Cc:	christian@...sch.at, giometti@...ux.it, peterz@...radead.org,
	johnstul@...ibm.com, devicetree-discuss@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-api@...r.kernel.org, tglx@...utronix.de,
	linuxppc-dev@...ts.ozlabs.org, richardcochran@...il.com,
	alan@...rguk.ukuu.org.uk, khc@...waw.pl
Subject: Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

In message: <alpine.DEB.2.00.1009271035110.9258@...ter.home>
            Christoph Lameter <cl@...ux.com> writes:
: On Thu, 23 Sep 2010, Christian Riesch wrote:
: 
: > > > It implies clock tuning in userspace for a potential sub microsecond
: > > > accurate clock. The clock accuracy will be limited by user space
: > > > latencies and noise. You wont be able to discipline the system clock
: > > > accurately.
: > >
: > > Noise matters, latency doesn't.
: >
: > Well put! That's why we need hardware support for PTP timestamping to reduce
: > the noise, but get along well with the clock servo that is steering the PHC in
: > user space.
: 
: Even if I buy into the catch phrase above: User space is subject to noise
: that the in kernel code is not. If you do the tuning over long intervals
: then it hopefully averages out but it still causes jitter effects that
: affects the degree of accuracy (or sync) that you can reach. And the noise
: varies with the load on the system.

Please see the earlier posts in this thread about why this doesn't
matter as much as you might think.  What matters is the measurements
(which are done in hardware and the results buffered), not the latency
in processing those messages through your servo.  This is due to the
fact that the errors that even long latencies introduce are
proportional to the change in fractional frequency[*] of the clock being
steered.  This change is usually on the order of a part per million.
Even with 10ms of latency would mean that you're introducing on the
order of sub-nanoseconds of phase error that will be measured in the
next cycle and steered out.

That's why latency doesn't matter.  Do you have other math to show
that it does?

Warner

[*] abs(1 - (clock_freq_old / clock_freq_new)) where clock_freq_old is
the old estimate of the clock and clock_freq_new is the new frequency
estimate of the clock.  Second to second, these change on the order of
a part per million or less...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html