[ltp] Massive clock drift on new thinkpad R32

[Tod Harter]

There are 2 seperate clocks, the hardware real-time clock, and the 'syste=
m=20
clock' which is just the linux kernel's own internal timekeeping. When yo=
u=20
boot the kernel gets the time from the hardware clock, from then on until=
 the=20
next boot it simply keeps time itself based on clock-tick interrupts.=20
Generally most systems write the system time back to the hardware clock o=
n=20
shutdown on the theory that if you changed the time you want that change=20
saved...

Generally the hardware clock is pretty accurate. If your system shows a s=
hift=20
in time as shown in BIOS setup screen when the system has been OFF during=
 the=20
preceeding hours then you can be SURE you have a hardware problem. Otherw=
ise=20
its more likely something thats being caused by innacurate kernel=20
timekeeping. If thats the case then there must be some other reason for i=
t,=20
like whatever kernel you're using is done broke! Or a device driver is=20
working improperly (masking interrupts for a long period of time perhaps)=
=2E=20
I'm no expert on linux internals.=20

I would try to figure out what has changed on your system recently and se=
e if=20
you can undo it...

On Thursday 21 November 2002 04:09 am, David Peterson wrote:
> Hi All,
>
> I'm wondering whether anyone on-list can provide me with some advice
> regarding a clock-drift problem I have (only recently, I think?!)
> started experiencing with my new R32 thinkpad. I am running debian linu=
x
> (woody) on the testing branch (if that matters at all).
>
> I seem to be drifting around 80 seconds (1m20s) for each hour that
> passes on the system. I have pasted a couple of ntpdate outputs below
> for those interested:
>
> peterson@buran:~$ ss ntpdate ntp.atnf.csiro.au
> 20 Nov 10:45:24 ntpdate[1134]: adjust time server 130.155.194.32 offset
> 0.279852 sec
> peterson@buran:~$ ss ntpdate ntp.atnf.csiro.au
> 20 Nov 11:29:37 ntpdate[1325]: step time server 130.155.194.32 offset
> 53.068004 sec
>
>
> This doesn't seem normal at all to me. I would expect clock drift in th=
e
> order of tens of a second over this time, not tens of seconds (two
> orders of magnitude greater). Does anyone have a suggestion as to how I
> can solve the problem, or is it time to call IBM for a warranty claim.
> Is this kind of behaviour even covered under warranty!?
>
> Any help appreciated.
>
> Regards
>
> David

--=20
Tod G. Harter
Giant Electronic Brain