lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /proc or ps tools bug? 2.6.3, time is off
Albert Cahalan wrote:
> On Wed, 2004-02-25 at 11:28, George Anzinger wrote:
>
>>Albert Cahalan wrote:
>>
>>>On Wed, 2004-02-25 at 00:10, David Ford wrote:
>
>
>>>Actually, it seems that there is a -significant- time difference in this
>>>
>>>>phantom clock now, I suspended my notebook to bring it home from the
>>>>station, and now this time difference is greater than 9 minutes. I
>>>>suspect it's roughly 46 seconds plus the amount of time that my notebook
>>>>was suspended. Yes, I'm running ntpd.
>>>>
>>>>root 16894 0.0 0.0 1544 484 pts/3 S Feb24 0:00 grep grep ps
>>>>Wed Feb 25 00:09:09 EST 2004
>>>
>>>OK, this is pointing right at the problem.
>>>
>>>Linux does not record process start times at all.
>>>Instead, it records the number of clock ticks
>>>from boot until the process starts.
>>>
>>>Either the boot time or current time is real.
>>>The other may be computed from the uptime, which
>>>may be measured in clock ticks.
>>
>>In 2.6.* boot time is captured at boot. This is then adjusted when ever the
>>clock is set. Up time is the difference between the saved boot time and the
>>current wall clock time.
>>
>>
>>>The clock doesn't tick when your laptop sleeps.
>>
>>I would guess that the clock adjustment made when the sleep ends is not
>>adjusting the boot time as it should. That code should set the clock by calling
>>do_settimeofday() which will do the right thing.
>
>
> I don't think so. The problem might be fixable by advancing
> jiffies, crediting the extra ticks to idle time.
> Consider the current situation as I know it, in jiffies:
>
> 00000 boot
> 10000 process 42 starts
> 20000 go to sleep
> 20000 wake (same jiffies, different time)
> 30000 process 51 starts
> 40000 ps examines the state of the system
>
> Process 42 was started 10 seconds after boot. (10000 jiffies)
> Process 51 appears to be started 30 seconds after boot. (30000 jiffies + ???)
>
> Now we want to compute:
>
> 1. real-world date and time for process start
> 2. length of process lifetime (real-world or not?)
>
> What works for process 42 won't work for process 51,
> because they are on different sides of a hidden gap.
>
> Another way to fix the problem is to move the boot time.
> It's kind of sick, but so are the alternatives.
>
>
>>As to small drifts of ~170 PPM, they are caused by code (ps I would guess) that
>>assumes that jiffies is exactly 1/HZ whereas it is NOT in the 2.6.* kernel. The
>>size of the jiffie that the kernel uses is returned by:
>>
>>struct timespec tv;
>>:
>>:
>>clock_res(CLOCK_REALTIME, &tv);
>>
>>This will be in nanoseconds (and must be as that is what the wall clock is in).
>
>
> This is NOT sane. Remeber that procps doesn't get to see HZ.
> Only USER_HZ is available, as the AT_CLKTCK ELF note.

May be, I did not do this, but only cleaned up the internal notion of jiffy so
timers would work more correctly. If you go back to HZ=100, every thing works
better in this regard.

On the other hand, what practical difference does it make? Almost no user code
even looks at USER_HZ. Its just things like ps and friends as far as I can
tell... Possibly we should just fix the utilities to use the above call to get
the jiffie size... I don't know the full history, but was USER_HZ invented by
the 2.5 changes?
>
> I think the way to fix this is to skip or add a tick
> every now and then, so that the long-term HZ is exact.

This is REAL problem for any code that wants to use more exact time/ timers than
the 1/HZ. See, for example, the high res patch (signature). You can not just
throw in an extra tick every so often.
>
> Another way is to simply choose between pure old-style
> tick-based timekeeping and pure new-style cycle-based
> (TSC or ACPI) timekeeping. Systems with uncooperative
> hardware have to use the old-style time keeping. This
> should simply the code greatly.

Hm, the reason 1/HZ is not used is that the x86 hardware (PIT, to be exact) can
not give a good 1/1000 value...
>
>
>
>

--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

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

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.101 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site