[Dprglist] Stability of CPU oscillator
John Swindle
swindle at compuserve.com
Thu Jun 4 22:13:23 PDT 2020
Murray and Dave,
Thank you both for your ideas.
I've taught classes on Intel and AMD Family 6 Instruction Set Architecture and several microarchitectures of that family. I know how to correctly use the Time Stamp Counter and the Performance Monitoring Counters. The TSC will work perfectly well for my application, but only if the CPU's oscillator is stable.
An oven-controlled crystal oscillator (OCXO) or GPS-disciplined oscillator (GPSDO) would be great, but I want something that fits on a robot, doesn't weigh much, doesn't draw much current, and doesn't cost much. FM radio 19kHz stereo pilot works great, but FM does not penetrate metal buildings. AC line frequency jitters far too much and is only guaranteed to be stable on a 24-hour basis. TSC is by far the simplest solution, so long as the XTAL is stable. I wonder what the typical spec is for the stability of the 100MHz reference clock in a consumer PC.
Thanks again.
John Swindle
-----Original Message-----
From: David Anderson via DPRGlist <dprglist at lists.dprg.org>
To: dprglist at lists.dprg.org
Sent: Thu, Jun 4, 2020 11:08 pm
Subject: Re: [Dprglist] Stability of CPU oscillator
Following on from Murray's comment. The standard in seismology these
days where very accurate time is required is to use GPS disciplined hi
resolution clocks. So the one PPS signal from the GPS is used to
correct the drift of (an otherwise extremely accurate) hardware clock.
John, I don't know if this is helpful, but DPRG friend Mark Sims
developed one a few years ago that has become common in a lot of
research and national laboratories. Wonder if he might have some
advice to offer. Mark are you out there?
One of the profs at SMU used to do an exercise for his students where
they synchronized two very hi-precision clocks, and then sent one up to
the third floor. Sure enough, because of relativistic effects, the one
on the third floor runs faster; it's higher in the gravity well. They
had to calculate how much faster. He told me at the time that the
coming clock technology would reduce that to about a meter. So a clock
on the table would run measurably faster than one on the floor.
cheers,
dpa
On 06/04/2020 10:30 PM, Murray Altheim via DPRGlist wrote:
> Hi John,
>
> In a former life I had to cause to deal with something akin to this and
> noted that given consumer PCs have had no reason to have stable clocks,
> they generally don't. This kind of specification isn't published because
> it doesn't matter to most people (apart from kernel developers) and it's
> not competitive to do so.
>
> You may have run upon this before, but to quote:
>
> "The time stamp counter (TSC) provided by x86 processors is a
> high-resolution counter that can be read with a single instruction
> (RDTSC), which makes it a tempting target for applications that
> need fine-grained timestamps. Unfortunately, it is also rather
> unreliable, so the kernel jumps through hoops to decide whether
> to use it and to try to detect when it goes awry. An effort to
> export the kernel's knowledge about the reliability of the TSC
> has met strong resistance for a number of reasons, but the biggest
> is that the kernel developers don't think that applications should
> be accessing the counter directly."
>
> The trouble with the TSC (2010)
> https://lwn.net/Articles/388188/
>
> also:
>
> Internal Clock Drift Estimation in Computer Clusters (2008)
> https://www.hindawi.com/journals/jcnc/2008/583162/
>
> I don't know if things have improved since then, my guess would be
> probably not. A few years ago I bought a top of the line Dell 13"
> XPS laptop and found I could hear the coil whine -- it turns out
> mine was a 7th generation laptop and the whine had been there since
> the beginning. Dell just never bothered to fix it since few of their
> customers could hear the noise and even fewer apparently complained.
> Commercial PC manufacturers don't fix things unless they need to.
>
> The closest thing I can think of as a really stable clock source for
> about US$30 would be to use the PPS signal off of a GPS sensor, though
> this isn't strictly a high speed clock these typically have an accuracy
> in the 10ns range. I would assume since the application is GPS the
> stability must be very good, somewhere in the same range, dunno, that's
> probably more your department. It's possible that some of the GPS units
> have other pin outputs that might be helpful. I know this isn't what
> you're looking for (since it's not a typical commercial product like a
> PC) but GPS clocks would seem to be the cheapest and most reliable I
> can think of.
>
> Cheers,
>
> Murray
>
> On 5/06/20 2:55 pm, John Swindle via DPRGlist wrote:
>> Folks:
>>
>> What is the typical stability of the oscillator in a consumer x86
>> platform?
>>
>> I don't find that specified for systems, or I don't know where to
>> look for the spec. The part numbers on the crystal often don't
>> seem to be sufficient to find the stability in the XTAL datasheet.
>>
>> I don't have access to test equipment to measure it.
>>
>> I appreciate any help, but just to be clear: I'm asking about the
>> stability, not the accuracy, so it would be ppm of drift and/or
>> jitter over time, not ppm of accuracy.
>>
>> I intend to use the invariant TSC in x86 processors, but if the
>> oscillator
>> is not stable, then the invariant TSC numbers will not be as useful
>> to me.
>
> ...........................................................................
>
> Murray Altheim <murray18 at altheim dot com> =
> = ===
> http://www.altheim.com/murray/ === ===
> = = ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
_______________________________________________
DPRGlist mailing list
DPRGlist at lists.dprg.org
http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200605/f08f0fcf/attachment-0001.html>
More information about the DPRGlist
mailing list