> 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
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
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
> 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
> 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
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
* 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
* 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
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
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
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
* 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
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 comments are wrong,
this is absolutely right. The
* George Spelvin li...@horizon.com 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
* Adrian Hunter adrian.hun...@intel.com 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
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 body
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 side
Ingo Molnar wrote:
* George Spelvin li...@horizon.com 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
* George Spelvin li...@horizon.com 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
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 comments are wrong,
this is absolutely right. The quick code
Ingo Molnar mingo.kernel@gmail.com wrote:
* George Spelvin li...@horizon.com 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
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
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
On Wed, Jun 10, 2015 at 11:38 AM, George Spelvin li...@horizon.com 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
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
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 unsubscribe
Arjan van de Ven arjanvande...@gmail.com 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
28 matches
Mail list logo
