Newsgroups: news.admin
Path: utzoo!utstat!geoff
From: geoff@utstat.uucp (Geoff Collyer)
Subject: Re: C inews & rnews speed (was Re: News delivery problems - old news again)
Message-ID: <1989Aug10.185833.6901@utstat.uucp>
Organization: Statistics, U. of Toronto
References: <43675@bbn.COM> <651@vector.Dallas.TX.US> <1989Aug3.180304.6252@eci386.uucp> <653@vector.Dallas.TX.US> <1989Aug7.230146.274@servalan.uucp> <1989Aug9.042147.10335@utstat.uucp> <1989Aug10.051459.613@servalan.uucp>
Date: Thu, 10 Aug 89 18:58:33 GMT

> Anyone out there done any more rigorous tests of C News vs B News performance? 

Have you seen "News Need Not Be Slow", Geoff Collyer and Henry Spencer,
Proc. Winter Usenix Conf. Washington 1987, pp. 181-190?  Running the
same ~300k batch into B 2.10.1 news (B 2.11 is ~5% faster) and into a
pre-alpha C news on the same VAX 750 running 4.2BSD, C news took ~5%
the elapsed and CPU times of B news.

One aspect of those timings that we haven't talked much about is that
the decreased elapsed time reflects a huge decrease in the amount of
disk i/o done by C news as compared to B news.  The single biggest
improvement we noticed in the early days was not that we had lots of
spare cycles (a 750 hasn't got many to start with) nor that incoming
news was being processed quickly, but rather that our machines no
longer suffered the degradation of interactive response which is
characteristic of B news unbatching and processing incoming news.  In
our B news days, we would feel a machine suddenly get very sluggish and
within a few seconds we would recognise the familiar pattern of slow
response from the disks and think "ah, incoming news".
-- 
Geoff Collyer		utzoo!utstat!geoff, geoff@utstat.toronto.edu