> ok so we're good, but I suspect we want to put this in a comment
> somewhere to prevent someone a year from now thinking they can do 100
> usec safely ;-)
I'll actually enshrine it in the code, as a factor in the uncertainty
computation.
--
To unsubscribe from this list: send the line "unsubscri
On Wed, Jun 10, 2015 at 11:38 AM, George Spelvin wrote:
> 25 ns is 100 ppm of 0.25 ms, so it should be okay if I go use a measurement
> interval of 1 ms or more.
>
ok so we're good, but I suspect we want to put this in a comment
somewhere to prevent someone a year from now thinking they can do 1
George Spelvin wrote:
> spread spectrum clock modulation rates are typically about 30 kHz
Actually I found a source:
http://download.intel.com/design/Pentium4/guides/24920601.pdf
CK00 Clock Synthesizer/Driver Design Guidelines
Page 45 says
"8. The modulation frequency of SSC is required to be in
Arjan van de Ven wrote:
> btw one thing to think about; if you calibrate VERY quickly, you need
> to consider spread spectrum clocking.
Excellent point! But spread spectrum clock modulation rates are typically
about 30 kHz, so 1 ms will average over 30 cycles, which should be enough.
The faster
> Especially any 'measure the minimum time' approach measuring more than
> a single PIT tick would be senstive to false positives.
Just to be clear, I'm not measuring the minimum of any timer ticks;
it's the timer *access* that's being measured. It's literally the
duration of a single inb() or ou
> If my plan survives contact with reality, it should work better 100%
> of the time and obsolete the old code.
>
> You said it should fail back to the old code, but there's not a lot of
> difference between failures I can detect and failures I can work around.
>
> I know it's a fatal error to unde
Ingo Molnar wrote:
>* George Spelvin wrote:
> Btw., we should make the patch fixing Adrian's system patch 0, as it
> looks simple and obvious enough, agreed?
Agreed. The one that just fails the quick calibration if it has
no chance of succeeding.
>> Sonds good, but when do we get to the decruf
* George Spelvin wrote:
> > Could you please structure it the following way:
> >
> > - first a patch that fixes bogus comments about the current code. It has
> > bitrotten and if we change it significantly we better have a well
> > documented starting point that is easier to compare against
* Adrian Hunter wrote:
> On 10/06/15 10:08, George Spelvin wrote:
>
> > The 8254 timer latches the msbyte when the lsbyte is read and returns the
> > latched value on the next read
>
> Are you sure about? The docs I've read don't seem to say that.
Btw., even if docs claim that, the code shoul
Ingo Molnar wrote:
>* George Spelvin wrote:
> As a side note: so VMs often want to skip the whole calibration business,
> because they are running on a well-calibrated host.
> 1,000 msecs is also an eternity: consider for example the KVM + tools/kvm
> based "Clear Containers" feature from Arjan:
Adrian Hunter wrote:
> On 10/06/15 10:08, George Spelvin wrote:
>> The 8254 timer latches the msbyte when the lsbyte is read
>> and returns the latched value on the next read
> Are you sure about? The docs I've read don't seem to say that.
You're right; I musy have been thinking about the write s
On 10/06/15 10:08, George Spelvin wrote:
> The 8254 timer latches the msbyte when the lsbyte is read
> and returns the latched value on the next read
Are you sure about? The docs I've read don't seem to say that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
* George Spelvin wrote:
> Adrian Hunter wrote:
>
> > A bigger issue for my case is that "slow" calibration is not that slow,
> > taking
> > only 10ms anyway which is much better than the 50ms max for so-called
> > "quick"
> > calibration.
>
> I read the code, and after figuring out which co
13 matches
Mail list logo
