[Dprglist] Stability of CPU oscillator

[David Anderson]

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