Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!well!jef
From: jef@well.sf.ca.us (Jef Poskanzer)
Newsgroups: comp.windows.x
Subject: Re: What does xload measure ??  (sunclock)
Message-ID: <20954@well.sf.ca.us>
Date: 4 Oct 90 23:59:55 GMT
References: <24728@uflorida.cis.ufl.EDU>
Reply-To: Jef Poskanzer <jef@well.sf.ca.us>
Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal
Lines: 51

In the referenced message, msm@ufl.edu (Michael S. McLean) wrote:
}In article <372@stephsf.stephsf.com>, wengland@stephsf.stephsf.com (Bill
}England) writes:
}> When sunclock is running xload shows the load going from 1/2 to just 
}> over 2.  Thats a 'load' increase of over 400%.  The cpu usage from ps 
}> shows only 12/sec per hour though.  (stephsf has 9Mb of memory)
}>
}> What does xload measure anyway ???   
}
}Xload displays the sampled average of the length of the run queue
}over the last minute.

Yes.

}                       Hence, unless sunclock is forking other
}processes, it can only drive up the load average by one process.
}Even to do that, it would have to run continuously without ever
}sleeping or blocking for I/O, and would very probably get more
}than 12 sec/hour of cpu time.

Unfortunately, this turns out not to be the case.  The problem is that
the kernel samples the length of the run queue at regular intervals,
and meanwhile xload and sunclock and other similar programs are
sleeping and running at similar regular intervals.  The intervals can
start beating against each other, going in and out of sync, and making
the load average number meaningless.

For example, on a quiescent Mac II my xload used to do this:

                 ___-------------------
                /                      |
               /                        \
              |                          \
______________|                           ---____________

It would be zero for a long time, then all of a sudden would climb to
one, stay there for a minute or so, then go back to zero.  Turns out
that A/UX was sampling the run queue every two seconds, and xload was
running every two seconds, and they were drifting in and out of sync.

Given this, it seems quite possible that adding in a sunclock would
make both the xload and the sunclock go into sync with the kernel,
raising the alleged load to two.

Moral: dump xload in the toilet.  Use xcpu or xmeter or something like
them instead.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {ucbvax, apple, hplabs}!well!jef
                  CONCENTRATED!!! DILUTE!!! DILUTE!!!