On Tue, 17 Jul 2001, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Bruce Ev > ans writes: > > > >I think that is far too much variation. 5 seconds is hard-coded into > >the computation of the load average (constants in cexp[]), so even a > >variation of +-1 ticks breaks the computation slightly. > > I have not changed the mean inter-sample time from 5 seconds (*), > so is this really a problem? There will be a slight time-warping > 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. > If the variation was much smaller than it is in the proposed patch, > you could get a noticable drifting in and out of phase with processes > that have a regular run-pause pattern. Obviously this is a much No, phase matches will be very rare in practice no matter what the random variation is. The average difference between the actual sampling time for the N'th sample and (5 * N) will drift away from 0. I think the average of the square of this difference is proportional to N provided the variation is uniformly distributed. The main problem with a small variation is that the average difference won't drift away from 0 very fast. Even with a large variation, the drift might not be fast enough. > 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 > synchronisation-avoidance behaviour. However, to incorporate the > sample into the load average requires either waiting until the end > of the interval, or updating the load average at the time of > sampling. The former introduces a new delay into the load average > computation, and the latter results in a lot of very noticable > jitter on the inter-sample interval. 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. > (*) Actually, I have changed the mean by 0.5 ticks, but that is a > bug that I will fix. The "4 + random() % (hz * 2)" should be "4 + > random() % (hz * 2 + 1)" instead. I think we can do better by making the bug a feature and using a sample time difference of slightly more than 5 seconds, e.g. 5.01 seconds. Then processes that wake up every second and run for less than 1 tick would be in phase precisely every 500 or 501 seconds, which is good (we want them to be in phase in a uniform way so that they get counted). Processes that wake up ever 1.002 seconds would then be in phase too much, but 1.002 is much less magic than 1.000, so such processes are 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 Note: sleep(), select() and non-periodic setitimer()'s also add 1 to the timeout. This should help reduce phase effects in userland. > >Not another SYSINIT (all SYSINITs are evil IMO). SI_SUB_PSEUDO is > >bogus here -- there are no pseudo ttys here. sched_setup() is a > >good place to do this initialization. > > John Baldwin suggested moving the load average calculation into > kern_synch.c, so it would certainly make sense to initialise it > from sched_setup() then. This seems like a good idea to me; does > that sound OK? Yes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

- Load average synchronisation and phantom loads Ian Dowse
- RE: Load average synchronisation and phantom loads John Baldwin
- Re: Load average synchronisation and phantom loads Bruce Evans
- Re: Load average synchronisation and phantom loads Ian Dowse
- Re: Load average synchronisation and phantom loads Bruce Evans