Re: Linux 2.6.29-rc6

From: Linus Torvalds
Date: Sun Mar 15 2009 - 15:05:42 EST




On Sun, 15 Mar 2009, Jesper Krogh wrote:
> > >
> > > [ 0.000000] Fast TSC delta=34227730, error=6223+6219=12442
> > > [ 0.000000] Fast TSC calibration using PIT
> > > [ 0.000000] Detected 2312.045 MHz processor.
>
> My conclusion was that I would get a time reset after some time since the
> offset just increased as time went by (being reasonably small at the
> beginning).
>
> I had it up for around 30 minutes... Should I have tested longer?

It would be good to test longer. Your previous emails showed:

2.6.26: time.c: Detected 2311.847 MHz processor.
2.6.29: Detected 2310.029 MHz processor.

where that first one was a successful boot, and the second one was a
failing one. So let's assume that 2311.847 is the "correct" frequency.

The difference between the correct one and your failing one is ~790 ppm,
which is above the 500ppm ntpd threshhold. And as we saw earlier, those
differences were pretty consistent, ie in your list of four successive
boots, the old code consistently gave a frequency error that was roughly
.7 permille off (ie exactly that 700 ppm).

HOWEVER! With that patch you just tried, you got

Detected 2312.045 MHz processor.

and the difference between _that_ and the assumed-correct-one is actually
just 85 ppm. Which should be perfectly fine.

[ With the "test against PM timer, you had:

[ 0.000000] ref_freq: 2311825 pit_freq: 2310386
[ 0.000000] ref_freq: 2311803 pit_freq: 2310190
[ 0.000000] ref_freq: 2311824 pit_freq: 2310080
[ 0.000000] ref_freq: 2311831 pit_freq: 2310130

on four boots, so averaging them gives 2311.82 Mhz, and the 2312.045MHz
you got with the improved fast-PIT code is still _way_ below 500ppm from
that - it's ~95 ppm away.

IOW, the new frequency realy looks likely to work. ]

Quite frankly, we don't know how exact the PM-timer is either - we just
know that the detection is "stable" (but so was the old PIT timer
detection: it was stably at 700ppm lower from the PM timer. So there is
nothing that says that 2311.82Mhz is the "correct" frequency, but we
obviously know from your ntpd saga that it is much closer to correct than
the old 2310.029 was.

End result of all this: I'd really like you to try the modified PIT
frequency code for longer. Also, remember that getting one (or a couple)
"time reset" messages from ntpd while it's trying to sync up is not a
problem per se - it can validly take a while to synchronize. The problem
is literally only if it doesn't synchonize over time at all.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/