daveb@rtech.UUCP (02/07/87)
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