Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!europa.asd.contel.com!noc.sura.net!mars!orion!stodola From: stodola@orion.fccc.edu (Robert K. Stodola) Newsgroups: comp.unix.wizards Subject: Re: Load Avarage graph pattern Message-ID: <1991Jun12.130441.20640@fccc.edu> Date: 12 Jun 91 13:04:41 GMT References: <14081@dog.ee.lbl.gov> Sender: news@fccc.edu (USENET News System) Organization: Fox Chase Cancer Center, Philadelphia PA Lines: 22 Nntp-Posting-Host: relay.fccc.edu In article <14081@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >In article meissner@osf.org >(Michael Meissner) writes: >>Another thing could be the activity to run the various xclock >>programs, and such. I would imagine that on timesharing systems with >>lots of xterms, this could be significant. [Much very interesting text deleted here. Thanks Chris!] >The solution is simple but requires relatively precise clocks. ... One of my associates and I did a study of this a number of years ago (actually it was with a PDP-11/70 running IAS). We found that there was substantial clock synchronized usage on the system. The solution we found didn't require very precise clocks at all. Simply one whose rate was relatively prime to the system clock. We got very good results using a clock at 5x.y Hz (don't remember the exact speed, but was a strange one in the 50's) on a system driven off a 60Hz clock. This was adequate to desynchronize the sampling rate from the system rhythms. Because it was a slow clock, it didn't add much load to the system, but did gave an adequate statistical picture of individual usage and load.