Path: utzoo!mnetor!motto!ecijmm!ecicrl!clewis
From: clewis@ecicrl.UUCP
Newsgroups: news.software.b
Subject: Re: B news problems
Message-ID: <691@ecicrl.UUCP>
Date: 6 Oct 89 05:01:09 GMT
References: <366@jwt.UUCP> <14728@bfmny0.UU.NET>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Organization: Elegant Communications Inc., Ferret Division, Toronto, Canada
Lines: 24

In article <14728@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
>I have seen somewhat lengthy processing times, seemingly dependent
>on the *length* of the articles being fed to rnews.  For instance
>the recent "Elk" 14-part source in comp.sources.misc
>took an agonizingly long time to spool
>each article.  (It wasn't the uncompress either -- that only takes
>a couple of seconds for 30k->60k.)  I assume we're checking for
>something now, but I'm not sure.

I'm seeing some rather frightening CPU times on the rnews that's
unpacking individual articles.  Like >1.20 CPU *minutes* on *one* 38K
map article.  A 3b1 isn't exactly a screamer, but >1.20 CPU minutes
for a single article is more than a little extreme.  Small articles
go thru relatively quickly.

(I upgraded from 2.11.14 to 2.11.18 too.  Seems to work reasonably
well other than this problem.  I'm System V, so I'm using the 10
sub-history files under history.d, but that shouldn't be the cause
of the problem, for I was running that before....)
-- 
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Phone: (416)-294-9253