Xref: utzoo comp.unix.xenix:2929 news.software.b:1530
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!amdahl!ems!pwcs!elric!hawkmoon!root
From: root@hawkmoon.MN.ORG (Admin)
Newsgroups: comp.unix.xenix,news.software.b
Subject: compress -d
Keywords: ridiculus long run times
Message-ID: <244@hawkmoon.MN.ORG>
Date: 7 Aug 88 07:16:42 GMT
Organization: One of the Eternal Champions - Richfield, MN, 554232523, USA
Lines: 18

Has anyone seen this problem?  I'm running Xenix 2.1.3 on a unisys pc/it with
2.5M of memory.  Frequently, when rnews is running, a compress -d is spawned to
uncompress the incoming batched news file (you know like "rnews 88040188933" or
something like that).  But, the compress -d frequently gets >300 minutes of cpu
time.  I have even tried this by hand on a news file and it had over 180
minutes before i killed it.  Is this a problem with bad batches of news (we ran
out of disk space a little while ago) or is this something wrong with compress?

Anything i can do to fix it?  I don't know how long the compresses will run w/o
me killing them.  I have either killed them or the machine has crashed before i
have seen a compress with lots of time finish.  Of course, i'm not keeping
track of every process; this is an observation via. ps -fe every so often.

This apparent anamoly makes receiving news *real* slow!
-- 
Derek Terveer		root@hawkmoon.MN.ORG
			w(612)681-6986
			h(612)688-0667