Re: /proc or ps tools bug? 2.6.3, time is off

[George Anzinger]

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@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/