Re: ULE and current.

On Fri, 12 Dec 2003, Bruce Evans wrote:

> On Fri, 12 Dec 2003, Andy Farkas wrote:
>
> > Bruce Evans wrote:
> > > [about systat and top]
> > > Neither; they have different bugs :-).  top actually seems to be
> > > bug-free here, except it intentionally displays percentages that add
> > > up to a multiple of 100%.  This seems to be best.  You just have to
> > > get used to the percentages in the CPU stat line being scaled and the
> > > others not being scaled.
> >
> > So the almost-bug in top(1) is that some CPU percentages are scaled and
> > some are not scaled?
>
> Yes.  It's probably more of a documentation bug.
>
> > ps. You mentioned "jitter". Thats why I 'sleep 120' in the above tests.
> > It tends to take about that long for top(1) to settle down. Why is that
> > so?
>
> As all top watchers know, %WCPU and especially %CPU take a while to
> ramp up with SCHED_4BSD.  That's just how the algorithm works.  I don't
> really understand SCHED_ULE, but think it has more jitter in the
> percentages because it fakes them based on what it is doing based on
> much less history than SCHED_4BSD (so they are closer to the transient
> %[W]CPU than the long-term averages).

In ULE I keep a window of ticks defined by ke_ftick and ke_ltick.  ftick
is the first tick that we were running and ltick is the last.  This window
is softly bound to 10 seconds.  There is also the ke_ticks field, which is
used to record the number of ticks that have occured during this time.

When the window exceeds 10 seconds + 1, the window is reduced to 10
seconds, and 10% of the ticks are decayed away.  When the value is read,
it is scaled back to 10 seconds, in case it has grown past 10, but before
11.  This also takes care of the situation where ltick is very far in the
past, and scales the recorded ticks back accordingly.

Do you think 10 seconds is too little history?

Cheers,
Jeff


>
> Bruce
>