Date: Wed, 18 Jul 2001 23:10:02 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Load average synchronisation and phantom loads Message-ID: <200107182310.aa89902@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 18 Jul 2001 22:13:21 %2B1000." <Pine.BSF.4.21.0107182018440.95253-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0107182018440.95253-100000@besplex.bde.org>, Bruce Ev
ans writes:
>On Tue, 17 Jul 2001, Ian Dowse wrote:
>> effect in the load calculation, but even for the shorter 5-minute
>> timescale, this will average out to typically no more than a few
>> percent (i.e the "5 minutes" will instead normally be approx 4.8
>> to 5.2 minutes). Apart from a marginally more wobbley xload display,
>> this should not make any real difference.
>
>It should average out to precisely the same as before if you haven't
>changed the mean (mean = average :-). The real difference may be
>small, but I think it is an unnecessary regression.
I meant the "5-minute average" that is computed; it will certainly
not be precicely the same as before, though it will be similar.
>from 0 very fast. Even with a large variation, the drift might not be
>fast enough.
Actually, it's not too bad with a +-1 second variation, which is
why I chose a value that large. If you plot 60 samples (60 is the
number of 5-second intervals in the 5-minute load average timescale)
you get a relatively good dispersion of points throughout the
5-second interval. Try pasting the following into gnuplot a few
times:
plot [] [-2.5:2.5] \
"<perl -e 'for (1..60){$a+=4+rand()*2; $o=$a-5*int(($a+2.5)/5); \
print \"$o\n\"}'" t "1 second", \
"<perl -e 'for (1..60){$a+=4.99+rand()*.02; $o=$a-5*int(($a+2.5)/5); \
print \"$o\n\"}'" t "0.01 second"
It shows that while a +-1 second variation results in samples that
are usually scattered well across the 5-second interval, a +-1 tick
variation never changes the sampling point much during that time.
If you have a worst-case type load pattern such as that caused by
perl -e 'for(;;){while((time-1)%5>1){}select(undef,undef,undef,2.5)}'
(5-second period, 50% duty cycle) then the interference pattern
resulting from a +-1 tick variation has a period that is typically
days long! Of course the interference pattern caused by the above
script has an infinitely long period with the old load average
calculation; it always causes an additional load of 1.0 even though
the %CPU usage is approx 50%.
>> The alternative that I considered was to sample the processes once
>> during every 5-second interval, but to place the sampling point
>> randomly over the interval. That probably results in a better
>
>I rather like this. With immediate update, It's almost equivalent to
>your current method with a random variation of between -5 and 5 seconds
>instead of between -1 and 1 seconds. Your current method doesn't
>really reduce the jitter -- it just concentrates it into a smaller
>interval.
When I tried this approach (with immediate update), I didn't like
the jumpyness of the load average. Instead of the relatively smooth
decay that I'm used to, the way it sometimes changed twice in short
succession and sometimes did not change for nearly 10 seconds was
quite noticable. I'd be quite happy to go with the delayed version
of this, though it does mean having two timer routines, and storing
the `nrun' somewhere between samples and updates.
>hopefully rare. Use a (small) random variation to reduce phase effects
>for such processes. I think there are none in the kernel. I would try
>using the following magic numbers:
>
> sample interval = 5.02 seconds (approx) (not 5.01, so that the random
> variation never gives a multiple
> of 1.00)
> random variation = 0+-0.01 seconds (approx)
> cexp[] = adjusted for 5.02 instead of 5.00
See above. I really want to try and avoid _any_ significant
synchronisation effects, not just those that are caused by the
kernel or by applications that happen to have a run pattern with
a period of N * 1.0 seconds.
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200107182310.aa89902>