Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2019 10:10:35 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        Ross Alexander <rwa@athabascau.ca>
Cc:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: rpi3 clock drift
Message-ID:  <65be6d3628a8d35084f7c98266582090f59b18be.camel@freebsd.org>
In-Reply-To: <alpine.BSF.2.21.99999.352.1911282333250.90234@autopsy.pc.athabascau.ca>
References:  <alpine.BSF.2.21.99999.352.1911271039470.281@autopsy.pc.athabascau.ca> <MWHPR06MB3134EC22EC3148DA800B2B7DAA440@MWHPR06MB3134.namprd06.prod.outlook.com> <alpine.BSF.2.21.99999.352.1911272214050.28592@autopsy.pc.athabascau.ca> <20191129052800.GA37113@server.rulingia.com> <alpine.BSF.2.21.99999.352.1911282333250.90234@autopsy.pc.athabascau.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-11-28 at 23:51 -0700, Ross Alexander wrote:
> On Fri, 29 Nov 2019, Peter Jeremy wrote:
> 
> > [...]
> 
> BTW, another *significant* source of jitter is the brand and age of
> the sd/mmc card used.  As they age, the write speed decreases and
> block write latency gets less uniform; this shows up as system clock
> jitter in the loopstats.  After a few years (3 or 4), the box becomes
> a complete falseticker and you need to replace the sd/mmc card.
> 

I'm having a real hard time with this one, conceptually.  This is
exactly what every one of our products at $work does:  precision timing
including ntpd and kernel time tracking UTC(GPS) to within a few nanos.
We've had products in the field for 15 years still using the original
sdcard and still hitting the same on-time performance numbers as the
day they were shipped (tracking UTC(GPS) +-10ns RMS).

I'm having a hard time picturing how sdcard write performance could
impact kernel timekeeping that much.  I say this as a person who has
spent years working on both the sdcard drivers and the kernel
timekeeping code in freebsd.  An sdcard driver that used PIO instead of
DMA might even cause a bit of jitter in measuring a PPS signal due to
interrupt latency (mostly if the interrupt thread priorities weren't
right), but even that would be nowhere near enough jitter to become a
falseticker, it would be on the order of a few dozen microseconds.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65be6d3628a8d35084f7c98266582090f59b18be.camel>