<div style="color:black;font: 10pt Arial, Helvetica, sans-serif;">
<div><span style="font-size: 13.3333px;">Murray and Dave,</span></div>
<div><span style="font-size: 13.3333px;"><br>
</span></div>
<div><span style="font-size: 13.3333px;">Thank you both for your ideas.</span></div>
<div><span style="font-size: 13.3333px;"><br>
</span></div>
<div><span style="font-size: 13.3333px;">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.</span></div>
<div><span style="font-size: 13.3333px;"><br>
</span></div>
<div><span style="font-size: 13.3333px;">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.</span></div>
<div><span style="font-size: 13.3333px;"><br>
</span></div>
<div><span style="font-size: 13.3333px;">Thanks again.</span></div>
<div><span style="font-size: 13.3333px;"><br>
</span></div>
<div><span style="font-size: 13.3333px;">John Swindle</span></div>
<div><br>
</div>
<br>
<br>
<div style="font-family:arial,helvetica;font-size:10pt;color:black">-----Original Message-----<br>
From: David Anderson via DPRGlist <dprglist@lists.dprg.org><br>
To: dprglist@lists.dprg.org<br>
Sent: Thu, Jun 4, 2020 11:08 pm<br>
Subject: Re: [Dprglist] Stability of CPU oscillator<br>
<br>
<div dir="ltr">Following on from Murray's comment. The standard in seismology these <br clear="none">days where very accurate time is required is to use GPS disciplined hi <br clear="none">resolution clocks. So the one PPS signal from the GPS is used to <br clear="none">correct the drift of (an otherwise extremely accurate) hardware clock.<br clear="none"><br clear="none">John, I don't know if this is helpful, but DPRG friend Mark Sims <br clear="none">developed one a few years ago that has become common in a lot of <br clear="none">research and national laboratories. Wonder if he might have some <br clear="none">advice to offer. Mark are you out there?<br clear="none"><br clear="none">One of the profs at SMU used to do an exercise for his students where <br clear="none">they synchronized two very hi-precision clocks, and then sent one up to <br clear="none">the third floor. Sure enough, because of relativistic effects, the one <br clear="none">on the third floor runs faster; it's higher in the gravity well. They <br clear="none">had to calculate how much faster. He told me at the time that the <br clear="none">coming clock technology would reduce that to about a meter. So a clock <br clear="none">on the table would run measurably faster than one on the floor.<br clear="none"><br clear="none">cheers,<br clear="none"><br clear="none">dpa<br clear="none"><br clear="none"><br clear="none"><br clear="none">On 06/04/2020 10:30 PM, Murray Altheim via DPRGlist wrote:<br clear="none">> Hi John,<br clear="none">><br clear="none">> In a former life I had to cause to deal with something akin to this and<br clear="none">> noted that given consumer PCs have had no reason to have stable clocks,<br clear="none">> they generally don't. This kind of specification isn't published because<br clear="none">> it doesn't matter to most people (apart from kernel developers) and it's<br clear="none">> not competitive to do so.<br clear="none">><br clear="none">> You may have run upon this before, but to quote:<br clear="none">><br clear="none">> "The time stamp counter (TSC) provided by x86 processors is a<br clear="none">> high-resolution counter that can be read with a single instruction<br clear="none">> (RDTSC), which makes it a tempting target for applications that<br clear="none">> need fine-grained timestamps. Unfortunately, it is also rather<br clear="none">> unreliable, so the kernel jumps through hoops to decide whether<br clear="none">> to use it and to try to detect when it goes awry. An effort to<br clear="none">> export the kernel's knowledge about the reliability of the TSC<br clear="none">> has met strong resistance for a number of reasons, but the biggest<br clear="none">> is that the kernel developers don't think that applications should<br clear="none">> be accessing the counter directly."<br clear="none">><br clear="none">> The trouble with the TSC (2010)<br clear="none">> <a shape="rect" href="https://lwn.net/Articles/388188/" target="_blank">https://lwn.net/Articles/388188/</a><br clear="none">><br clear="none">> also:<br clear="none">><br clear="none">> Internal Clock Drift Estimation in Computer Clusters (2008)<br clear="none">> <a shape="rect" href="https://www.hindawi.com/journals/jcnc/2008/583162/" target="_blank">https://www.hindawi.com/journals/jcnc/2008/583162/</a><br clear="none">><br clear="none">> I don't know if things have improved since then, my guess would be<br clear="none">> probably not. A few years ago I bought a top of the line Dell 13"<br clear="none">> XPS laptop and found I could hear the coil whine -- it turns out<br clear="none">> mine was a 7th generation laptop and the whine had been there since<br clear="none">> the beginning. Dell just never bothered to fix it since few of their<br clear="none">> customers could hear the noise and even fewer apparently complained.<br clear="none">> Commercial PC manufacturers don't fix things unless they need to.<br clear="none">><br clear="none">> The closest thing I can think of as a really stable clock source for<br clear="none">> about US$30 would be to use the PPS signal off of a GPS sensor, though<br clear="none">> this isn't strictly a high speed clock these typically have an accuracy<br clear="none">> in the 10ns range. I would assume since the application is GPS the<br clear="none">> stability must be very good, somewhere in the same range, dunno, that's<br clear="none">> probably more your department. It's possible that some of the GPS units<br clear="none">> have other pin outputs that might be helpful. I know this isn't what<br clear="none">> you're looking for (since it's not a typical commercial product like a<br clear="none">> PC) but GPS clocks would seem to be the cheapest and most reliable I<br clear="none">> can think of.<br clear="none">><br clear="none">> Cheers,<br clear="none">><br clear="none">> Murray<br clear="none">><br clear="none">> On 5/06/20 2:55 pm, John Swindle via DPRGlist wrote:<br clear="none">>> Folks:<br clear="none">>><br clear="none">>> What is the typical stability of the oscillator in a consumer x86 <br clear="none">>> platform?<br clear="none">>><br clear="none">>> I don't find that specified for systems, or I don't know where to <br clear="none">>> look for the spec. The part numbers on the crystal often don't<br clear="none">>> seem to be sufficient to find the stability in the XTAL datasheet.<br clear="none">>><br clear="none">>> I don't have access to test equipment to measure it.<br clear="none">>><br clear="none">>> I appreciate any help, but just to be clear: I'm asking about the<br clear="none">>> stability, not the accuracy, so it would be ppm of drift and/or <br clear="none">>> jitter over time, not ppm of accuracy.<br clear="none">>><br clear="none">>> I intend to use the invariant TSC in x86 processors, but if the <br clear="none">>> oscillator<br clear="none">>> is not stable, then the invariant TSC numbers will not be as useful <br clear="none">>> to me.<br clear="none">><br clear="none">> ........................................................................... <br clear="none">><br clear="none">> Murray Altheim <murray18 at altheim dot com> = <br clear="none">> = ===<br clear="none">> <a shape="rect" href="http://www.altheim.com/murray/" target="_blank">http://www.altheim.com/murray/ </a>=== ===<br clear="none">> = = ===<br clear="none">> In the evening<br clear="none">> The rice leaves in the garden<br clear="none">> Rustle in the autumn wind<br clear="none">> That blows through my reed hut.<br clear="none">> -- Minamoto no Tsunenobu<br clear="none">><br clear="none">> _______________________________________________<br clear="none">> DPRGlist mailing list<br clear="none">> <a shape="rect" ymailto="mailto:DPRGlist@lists.dprg.org" href="mailto:DPRGlist@lists.dprg.org">DPRGlist@lists.dprg.org</a><br clear="none">> <a shape="rect" href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a>
<div class="yqt7887205157" id="yqtfd17083"><br clear="none"><br clear="none">_______________________________________________<br clear="none">DPRGlist mailing list<br clear="none"><a shape="rect" ymailto="mailto:DPRGlist@lists.dprg.org" href="mailto:DPRGlist@lists.dprg.org">DPRGlist@lists.dprg.org</a><br clear="none"><a shape="rect" href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br clear="none"></div>
</div>
</div>
</div>