[lkml]   [2009]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.6.29-rc6

On Tue, 17 Mar 2009, Ingo Molnar wrote:
> That's the idea of my patch: to use not two endpoints but thousands
> of measurement points.

Umm. Except you don't.

> By measuring more we can get a more precise result, and we also do
> not assume anything about how much time passes between two
> measurement points.

That's fine, but your actual code doesn't _do_ that.

> My 'delta' algorithm does not assume anything about how much time
> passes between two measurement points - it calculates the slope and
> keeps a rolling average of that slope.

No, you keep a very bad measure of "some kind of random average of the
last few points", which - if I read things right:

- lacks precision (you really need to use 'double' floating point to do
it well, otherwise the rounding errors will kill you). You seem to be
aiming for a 10-bit fixed point thing, which may or may not work if
done cleverly, but:

- seems to be based on a rather weak averaging function which certainly
will lose data over time.

The thing is, the only _accurate_ average is the one done over long time
distances. It's very true that your slope thing works very well over such
long times, and you'd get accurate measurement if you did it that way, BUT
THAT IS NOT WHAT YOU DO. You have a very tight loop, so you get very bad
slopes, and then you use a weak averaging function to try to make them
better, but it never does.

Also, there seems to be a fundamental bug in your PIT reading routine. My
fast-TSC calibration only looks at the MSB of the PIT read for a very good
reason: if you don't use the explicit LATCH command, you may be getting
the MSB of one counter value, and then the LSB of another. So your PIT
read can easily be off by ~256 PIT cycles. Only by caring only for the MSB
can you do an unlatched read!

That is why pit_expect_msb() looks for the "edge" where the MSB changes,
and never actually looks at the LSB.

This issue may be an additional reason for your problems, although maybe
your noise correction will be able to avoid those cases.


 \ /
  Last update: 2009-03-17 17:37    [W:0.101 / U:7.632 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site