pcng@cad.unsw.oz (Po Cheung Ng (Andrew)) (06/09/89)
I got 'w' (and 'uptime' as well) running on my Xenix/286 v2.2.3 system.
There are couple of Xenix internels inside the kernel to handle
load average and up time. You don't need a daemon process to monitor them.
I got these two programs (in fact only one program linked with different names)
from a patched version of System V 'w' (I think). I can post if anyone
interested.
_ _. __ _,
--- /_)_(__/) )_(_)_ [ Also known as Andrew ]
/ /|
' |/
----------------
Po Cheung NG ISD: +61 2 697-4056
JMRC, School of Elec. Eng. and Comp. Sci., STD: (02) 697-4056
The University of New South Wales, FAX: +61 2 662-2087
PO Box 1, Kensington, ARPA: pcng%cad.jmrc.eecs.unsw.oz.au@uunet.uu.net
Sydney, NSW 2033, JANET: cad.jmrc.eecs.unsw.oz!pcng@ukc
AUSTRALIA. ACSnet: pcng@cad.jmrc.eecs.unsw.oz
....!enea ---------\
....!hplabs -----\ \
....!mcvax --\ \ \
UUCP: ....!prlb2 --->--->--> !munnari!cad.jmrc.eecs.unsw.oz!pcng
....!uunet --/ / /
....!ubc-vision -/ /
....!ukc ----------/chip@vector.Dallas.TX.US (Chip Rosenthal) (06/15/89)
pcng@cad.unsw.oz (Po Cheung Ng (Andrew)) writes: >There are couple of Xenix internels inside the kernel to handle >load average and up time. 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. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 "I wish you'd put that starvation box down and go to bed" - Albert Collins' Mom
rmtodd@uokmax.UUCP (Richard Michael Todd) (06/16/89)
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
abs@sco.COM (Amy Snader) (06/22/89)
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. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 The three numbers in avenrun are the 1, 5, and 15 minute load averages. The load average figures are updated every 5 seconds. These three shorts are being used as pseudo-floating point numbers, with 8 bits to the left of the decimal point, 8 bits to the right. According to comments in the code, the Berkeley kernel maintains a load average in genuine floating point, but when the algorithm was ported to Xenix it was translated into integer-based psuedo-floating point. Because a Xenix box may or may not contain an fpu chip, Xenix assiduously avoids performing any floating point in the kernel. However, once the numbers are read by a user program it's easy enough to translate into a "normal" floating point format. --Amy
davidsen@crdgw1.crd.ge.com (William E. Davidsen Jr) (07/04/89)
In article <713@sysco> abs@sco.COM (Amy Snader) writes: | The three numbers in avenrun are the 1, 5, and 15 minute load | averages. The load average figures are updated every 5 seconds. | These three shorts are being used | as pseudo-floating point numbers, with 8 bits to the left of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | decimal point, 8 bits to the right. Excuse me? They are called fixed-point numbers, and are in no way related to floating point, pseudo or otherwise. -- - bill davidsen (davidsen@crdgw1.uucp) GE Corp. R&D Center; Box 8, KW-C206; Schenectady NY 12345