Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!occrsh!uokmax!rmtodd
From: rmtodd@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.unix.xenix
Subject: Re: load average on Xenix (was lload on Xenix)
Message-ID: <3334@uokmax.UUCP>
Date: 15 Jun 89 21:45:12 GMT
References: <357@usage.csd.unsw.oz> <266@vector.Dallas.TX.US>
Reply-To: rmtodd@uokmax.UUCP (Richard Michael Todd)
Organization: University of Oklahoma, ECN
Lines: 28

In article <266@vector.Dallas.TX.US> chip@vector.Dallas.TX.US (Chip Rosenthal) writes:
>I was playing around with this in 2.3.1, and it appears that you have
>something like:
>
>	short avenrun[3];
>
>in the kernel, and the load average values are these values divided
>by 256.0.  I came upon 256 emperically ... is there any particular
>reason or precedent for this magic cookie?  It isn't documented in
>any <sys/*.h> file that I could find.
 
 The avenrun array for load averages was originally invented at UCB,
and I believe the original BSD implementation had, as you say, an array of
values which you divide by 256 to get the actual load average.  At least,
that's the way it works on Suns (running 4.2BSD-derived code).  On the 
Sun avenrun was an array of 3 longs.  I don't believe this is documented
anywhere outside the BSD kernel sources.  As for why, the avenrun values
are stored as fixed-point values to avoid the overhead involved with
floating-point on some systems, and since the values are going to be
fixed-point, one might as well make the binary point fall on a byte boundary
so as to simplify the fixed-point operations.  Hence the 256.  Note that
all this is undocumented and may work differently on other systems; for
example, on Apple A/UX the coefficient to divide the long values by is
65536, *not* 256.  
  Don't you just love poking around in the undocumented innards of the kernel?
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
                                    aka     ...!sun!texsun!uokmax!rmtodd