[ltp] Massive clock drift on new thinkpad R32

[David Peterson]

Hi Todd,

Time-keeping when the system is powered off is very accurate. I believes 
from the response posts that this would rule out both the hardware RTC 
and the CMOS battery as potential sources of the problem. Therefore, I'm 
focussing on your comments re inaccurate kernel timekeeping, in keeping 
with the idea that it looks like a software issue (which would explain 
why I have only recently come to notice it, and only on linux - though 
my winXP testing has not been very exhaustive!)

When I think of changes I have made, only a couple of things readily 
come to mind:

- upgraded from 2.4.18 kernel to 2.4.19 kernel using the debian kernel 
images
- installed a sound driver (the i810_audio module, which also loads the 
soundcore module and ac97_codec module)

As you can see from the following post, the system is "losing time" 
(slowing down), and this is taking places in a regular manner:

> peterson@buran:~$ date; ss ntpdate ntp.atnf.csiro.au; date
> Fri Nov 22 18:05:59 EST 2002
> 22 Nov 18:05:59 ntpdate[1364]: adjust time server 130.155.194.32 
> offset 0.030827 sec
> Fri Nov 22 18:05:59 EST 2002
> peterson@buran:~$ date; ss ntpdate ntp.atnf.csiro.au; date
> Fri Nov 22 18:06:01 EST 2002
> 22 Nov 18:06:02 ntpdate[1367]: adjust time server 130.155.194.32 
> offset 0.065080 sec
> Fri Nov 22 18:06:02 EST 2002
> peterson@buran:~$ date; ss ntpdate ntp.atnf.csiro.au; date
> Fri Nov 22 18:06:07 EST 2002
> 22 Nov 18:06:07 ntpdate[1370]: adjust time server 130.155.194.32 
> offset 0.148119 sec
> Fri Nov 22 18:06:07 EST 2002
> peterson@buran:~$ date; ss ntpdate ntp.atnf.csiro.au; date
> Fri Nov 22 18:06:09 EST 2002
> 22 Nov 18:06:09 ntpdate[1373]: adjust time server 130.155.194.32 
> offset 0.179031 sec
> Fri Nov 22 18:06:09 EST 2002
>

Note that I have rebooted back under the 2.4.18 kernel, and I  still 
experienced the problem. Also, I have rmmod'ed the three sound modules I 
mentioned from a running 2.4.19 kernel, and I still experienced the 
problem. (Note of course that the modules had already been loaded during 
boot, so if there is flaky software inside that is causing the problem, 
there is no guarantee that this would be disabled via an rmmod ... my 
next test is to alter modules.conf to explicitly prevent them from 
loading at all, and to test again)

I can't think what other modules I may have installed or changed. 
Thinking about posting on one of the debian mailing lists to see if 
anyone there has seen the problem. If anything further comes to mind, 
please let me know. In any case, thanks for your helpful suggestions so 
far (and thanks to all others on-list who have also offered advice and 
comments).

Regards, Dave



Tod Harter wrote:

>There are 2 seperate clocks, the hardware real-time clock, and the 'system 
>clock' which is just the linux kernel's own internal timekeeping. When you 
>boot the kernel gets the time from the hardware clock, from then on until the 
>next boot it simply keeps time itself based on clock-tick interrupts. 
>Generally most systems write the system time back to the hardware clock on 
>shutdown on the theory that if you changed the time you want that change 
>saved...
>
>Generally the hardware clock is pretty accurate. If your system shows a shift 
>in time as shown in BIOS setup screen when the system has been OFF during the 
>preceeding hours then you can be SURE you have a hardware problem. Otherwise 
>its more likely something thats being caused by innacurate kernel 
>timekeeping. If thats the case then there must be some other reason for it, 
>like whatever kernel you're using is done broke! Or a device driver is 
>working improperly (masking interrupts for a long period of time perhaps). 
>I'm no expert on linux internals. 
>
>I would try to figure out what has changed on your system recently and see if 
>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 linux
>>(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 the
>>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
>>    
>>
>
>  
>