UNIX PC 3.5 OK scheduling problem (?).

[daveb at rtech.UUCP]

	time compress < /unix > /dev/null

		3.0	3.5

	real	37.5s	2:22
	user	22.1s	18.7
	sys	21.8	3.3

3.0 is with the 20M, 85ms drive, and 3.5 is with a 72M, 30ms Vertex.  
It appears that compress is getting CPU starved, as it is not getting
anywhere near the attention it requires.  

I'm guessing there was some tweaking to the scheduler to favor
"interactive" jobs. This is killing my compressed backup scheme, because

	find / -print | cpio -oac | compress | fwrite
	
is taking 15-20 minutes per disk instead of the 2 or 3 it took under 3.0.
I am probably going to report this as a bug, but who knows what response
it will receive from the hotline.

Does anyone have any ideas?

-dB


-- 
If it worked, we wouldn't call it high tech.

{amdahl, sun, mtxinu, cbosgd}!rtech!daveb