Re: 2.6.1: process start times by procps

[Bill Davidsen <davidsen _at_ xxxxxxx>]

john stultz wrote:
> On Tue, 2004-01-27 at 07:52, Petri Kaukasoina wrote:
> 
>>On Sun, Jan 25, 2004 at 01:08:47PM +0200, I wrote:
>>
>>>On Fri, Jan 23, 2004 at 09:47:14PM +0200, I wrote:
>>>
>>>>For example, I started this bash process really at 21:24 (date showed 21:24
>>>>then):
>>>>
>>>>kaukasoi 22108  0.0  0.2  4452 1532 pts/4    R    21:28   0:00 /bin/bash
>>>
>>>OK, I would like to make my bug report more accurate: the problem seems to
>>>be that the value of btime in /proc/stat is not correct.
>>
>>btime in /proc/stat does not stay constant but decreases at a rate of 15
>>secs/day. (So I thought that that's why there is that four minute error in
>>ps output after uptime of a couple of weeks.) Maybe this has something to do
>>with the fact that the 'timer' line in /proc/interrupts does not seem to
>>increase at an exact rate of 1000 steps per second but about 1000.18 steps
>>per second, instead. (The relative error is the same: 0.18 divided by 1000
>>is equal to 15 seconds divided by 24 hours).
>>
>>I made an experiment shown below. I know nothing about kernel programming,
>>so this is probably not correct, but at least btime seemed to stay constant.
>>(I don't believe this fixes procps, though. If HZ if off by 180 ppm then I
>>guess ps can't possibly get its calculations involving HZ right. But at
>>least the bootup time reported by procinfo stays constant.)
> 
> 
> 
> Uh, what does your /etc/ntp/drift file show?
> 
> The basic equation is: 
> btime ~= gettimeodfay() - uptime
> 
> Thus if your time of day is adjusted by NTP, btime will change as well.
> Uptime is calculated calculated by jiffies/HZ, and HZ is not NTP
> adjusted, so if your system is running 180ppm too fast or slow, btime
> would be expected to change. 

It would seem that there is a problem having the system know which two 
times to believe. Given that I set time from a good source in rc.local, 
it would be nice to have the system know that the correct and unchanging 
btime is NOW-uptime. And to make that assumption it would have to be 
told in some way that the btime should be calculated and treated as 
unchanging. On other systems a standard may never be used, or the 
standard mey be the local cable guide (most have a time).

A good thing to consider if you care, I guess right after setting to a 
trusted clock I might want to save the btime somewhere.

-- 
bill davidsen <davidsen _at_ tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/