Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!stanford.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.wizards Subject: accurate runtime accounting (was Load Avarage graph pattern) Message-ID: <14398@dog.ee.lbl.gov> Date: 18 Jun 91 08:03:51 GMT References: <14081@dog.ee.lbl.gov> <1991Jun12.130441.20640@fccc.edu> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 30 X-Local-Date: Tue, 18 Jun 91 01:03:51 PDT In article <14081@dog.ee.lbl.gov> I noted that Unix CPU accounting is generally fairly poor, and wrote: >>The solution is simple but requires relatively precise clocks. ... In article <1991Jun12.130441.20640@fccc.edu> stodola@orion.fccc.edu (Robert K. Stodola) writes: >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. This works well in a number of situations, but I believe it will miss short-lived processes on modern (fast) machines. Unix boxes generally run their scheduling clock in the range 50..500 Hz. Some of these have CPUs that run 40 million instructions per second; some things take only a few thousand instructions, and it seems intuitively obvious% that they might `slip through the cracks'. [%This is research-ese for `We did not try it out but we wrote a paper on it anyway.' :-) ] In other words, I think `PDP-11/70' may be an important constraint above. A relatively prime profiling clock is likely to work well on many VAXen as well (the 11/780 is typically slower than an 11/70, and most microVAXen are only a few times faster). I would like to see some measurements done on MIPS RC6280s, HP 700s, and so forth; I expect things may have changed. (Of course, we could always speed up the profiling clock, still keeping it relatively prime.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov