Accounting woes for HCX/UX 3.0

[John Mashey]

In article <1358 at mtunb.ATT.COM> jcm at mtunb.UUCP (was-John McMillan) writes:
...
>
>It strikes me the ORIGINAL writers were WELL prepared for the future --
>that they had an appropriate eye out for conserving resources, regardless
>of disk sizes.  With time, the sizes have increased -- my PC has 190 MB --
>but the lack of space never seems to be solved!
...
>The average accounting file is read once or twice in its life: data
>compression is reasonable and appropriate here.  An error -- such as your
>experience suggests exists -- is all the worse as I believe the compression
>feature has been present for 15 years.

The code was written early in 1978; DMR came up with the comp_t format;
I wrote most of the original accounting software.  At the time, most BTL
UNIX machines were PDP-11/70s, usually with a couple RP04s (80MB), or
maybe, RP06s (170MB). Typical main memory sizes were 256KB-1024KB;
the kernel was limited to 64KB of code, 64KB of data, and (sometimes)
64KB of buffer cache.

The design was of course geared to saving disk space, with the following
reasoning:
	a) Typical peak fork/exit rates were 10/second.  Such rates were
	often seen on the big PWB/UNIX systems that provided much of the
	impetus for doing the accounting in the first place.

	b) At 32 bytes/exit, this creates:
	       320	bytes/sec
	    19,200	bytes/min
	 1,152,000	bytes/hour
	27,648,000	bytes/day

	c) Of course, few systems would actually run at that rate all day.
	Nevertheless, even a lesser, realistic rate could eat a 6th-edition
	filesystem, and it was required that this package run compatibly
	on PWB/UNIX 1.2 (which was still 6th-edition).  Recall that each
	file was limited to 1MB, which could be overrun in an hour....
	Of course, 7th-ed files and filesystems were bigger, but they
	didn't increase the size of disks...
	d) It was highly desirable NOT to go to the next higher power-of-2,
	as there really existed systems where doubling the accounting space
	would really make it impractical to use.  Why would one go to 64,
	rather than a smaller number? ANS: for various reasons, it was
	desirable to keep an integral number of acct records per
	512-byte block.

The issue had nothing in particular to do with floating-point conversions,
unless my memory fails me, strictly space compression.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086