🚀 go-pugleaf

>We are looking at upgrading our campus Usenet News server from a hopelessly
>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
>for handling news has been disk access time, so we're looking at options that
>will allow us the highest disk throughput possible to a disk with a capacity
>of at least a gigabyte.  I'm looking for advice on an optimal configuration

	Your message-ID was a Cnewsish one. I'd start by upgrading to
INN. That will solve some of your problems right away.
	If that doesn't do it, I think I'd buy a second SCSI controller
and get the disk striping for ULTRIX software (from assets) and about
4 Rz25s. Those are the little, *fast* 500or-so-meg disks. I'd build
them into a stripe set with 2 on each controller, and then I'd add a
pile of RAM to the machine. Alternative #2 is an IPI controller and
a big, fast IPI disk.

mjr.
-- 
                                                 "guns don't die. people do."

In article <1jp1pfINN3de@sol.tis.com> mjr@tis.com (Marcus J Ranum) writes:
>>We are looking at upgrading our campus Usenet News server from a hopelessly
>>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
>>for handling news has been disk access time, so we're looking at options that
>>will allow us the highest disk throughput possible to a disk with a capacity
>>of at least a gigabyte.  I'm looking for advice on an optimal configuration
>
>	Your message-ID was a Cnewsish one. I'd start by upgrading to
>INN. That will solve some of your problems right away.
>	If that doesn't do it, I think I'd buy a second SCSI controller
>and get the disk striping for ULTRIX software (from assets) and about
>4 Rz25s. Those are the little, *fast* 500or-so-meg disks. I'd build

Of course, adding second SCSI implies that they no longer use the 3100.

I have news serving our campus off a 240 with 72MB's RAM, and news is on a 
RZ25, and I'm running the Cnews perf release, and having no load problems
at all.  Well, actually, I needed more capacity, so now it's running of
an HP 1.3GB drive, but still a single spindle, no probs.

INN will certainly help if you have lots of incoming feeds; I didn't notice
a big improvement with  readers though.  INN is certainly tuned for handling
oodles of incoming news.  
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@cs.montana.edu

In article <THOMSON.93Jan22073952@zarda.macc.wisc.edu>, thomson@zarda.macc.wisc.edu (Don Thomson) writes:
>
>We are looking at upgrading our campus Usenet News server from a hopelessly
>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
>for handling news has been disk access time, so we're looking at options that
>will allow us the highest disk throughput possible to a disk with a capacity
>of at least a gigabyte.  I'm looking for advice on an optimal configuration
>for these needs, including:
>
>Choice of disk:
>
>	RZ26, RZ58, third-party fast disks, RAID storage systems?

If you can find something reasonable to put them in I'd go with the
RZ26.  Whether a RAID-n array would help any on performance depends
on the I/O characteristic of what you're doing now.  My I/O character-
ization experience was with Bnews, but it went something like:

Busy file systems;
    /tmp
    /usr/new/lib/new - History file
    /var/spool/news

The I/O load was pretty evenly distributed between them.

For the partition that had /var/spool/news on it:

Read/Write ratio: 30/70
Data accesses:    50.26%
Inode accesses:   47.59%
Cyl. group data:   1.14%
other noise:          1%

Most of the I/O was 8 KB, but the next biggest chunk was 1 KB.

You may also want to see a bigger buffer cache may help.  You
can check the buffer cache statistics with crash(8):

# crash
> bufstats
   
>
>Options to speed up access:
>
>	Prestoserve disk caching, IPI disk interface?

If you News has the same I/O balance as mine did, Prestoserve will
help a lot.  With nearly half the I/O being synchronous file system
data updates, anything that helps that is bound to be good.  A
mentioned by Marcus, Striping can also help, since you'll get the
load spread across multiple disks.

An IPI subsystem will probably help, but it seems a bit overkill...

>
>Any and all comments on these and suggestions on other options would be most
>appreciated!
>--
> 
>----- Don Thomson ----- MACC, 1210 W. Dayton, Madison, WI  53706 -------------
>    (608) 262-0138      thomson@macc.wisc.edu / thomson@wiscmacc.bitnet
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

alan@nabeth.enet.dec.com (Alan Rollow) writes:
}thomson@zarda.macc.wisc.edu (Don Thomson) writes:
}>We are looking at upgrading our campus Usenet News server from a hopelessly
}>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
}>for handling news has been disk access time, so we're looking at options that
}>will allow us the highest disk throughput possible to a disk with a capacity
}>of at least a gigabyte.  I'm looking for advice on an optimal configuration
}>for these needs, including:
 ...
}Most of the I/O was 8 KB, but the next biggest chunk was 1 KB.

}An IPI subsystem will probably help, but it seems a bit overkill...

Perhaps not.  A fairly recent Usenix Paper, "Why SCSI is better than IPI
for NFS" (or something like that), held that IPI was really only a win
for large sequential I/Os, for the NFS I/O mix (generally 8KB and all
over the disk [sound familiar?]) SCSI was a win.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

In article <C1BFFz.EEr@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>alan@nabeth.enet.dec.com (Alan Rollow) writes:
>}thomson@zarda.macc.wisc.edu (Don Thomson) writes:
>}>We are looking at upgrading our campus Usenet News server from a hopelessly
>}>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
>}>for handling news has been disk access time, so we're looking at options that
>}>will allow us the highest disk throughput possible to a disk with a capacity
>}>of at least a gigabyte.  I'm looking for advice on an optimal configuration
>}>for these needs, including:
> ...
>}Most of the I/O was 8 KB, but the next biggest chunk was 1 KB.
>
>}An IPI subsystem will probably help, but it seems a bit overkill...
>
>Perhaps not.  A fairly recent Usenix Paper, "Why SCSI is better than IPI
>for NFS" (or something like that), held that IPI was really only a win
>for large sequential I/Os, for the NFS I/O mix (generally 8KB and all
>over the disk [sound familiar?]) SCSI was a win.
>
>John

Actually on Ultrix systems this is not true.  IPI will still win.  The
paper uses a couple of arguments which are either outdated, or don't
apply to these systems:

1) SCSI should do better for random I/O since it has a buffer and IPI
   doesn't.

   The newest IPI drives now have buffers just like SCSI drives (Seagate's
   Elite-3 IPI drive has a .5 MB buffer).  Even when using non-buffered
   drives on DECsystems, this argument still fails since the IPI
   **controllers** extensively buffer and cache the data.  The paper
   compared a situation where the IPI drive was connected to the system
   with a much less sophisticated IPI **adapter**.

2) SCSI optimizes multiple drives by placing a lot of intelligence on the
   drive.

   Again newer IPI drives also have this increased intelligence built in.
   Also, the IPI controllers for DECsystems provides a much higher level
   of optimization than the SCSI adapters.  The IPI controllers can do
   overlapped seeks, command queueing, command ordering, rotational latency
   optimization, and command consolidation - all controlled by an on-board
   microprocessor which is running at 10 Million instructions per second.

Now as Alan Rollow points out, this may well be overkill for the original
requirement.  But even for random I/O or NFS; on DECsystems, IPI is much
faster than SCSI.  BTW, all the above remains true for TURBOchannel based
Alpha systems (DEC 3000/500 and DEC 3000/400) running OSF/1.


--
Joe Nordman, V.P. of R&D 				joe@genroco.com 
GENROCO, Inc.           

In article <1993Jan27.205507.13234@grc.genroco.com>, joe@grc.genroco.com (Joe Nordman) writes:
   [ re IPI drives ]
> 
> Now as Alan Rollow points out, this may well be overkill for the original
> requirement.  But even for random I/O or NFS; on DECsystems, IPI is much
> faster than SCSI. ....
> 
  I have no arguments with (but do thank the author for) the info re IPI 
  drives.  But I would opt for slower/cheaper SCSI and throw a lot more memory
  into the machine instead.  At least, OUR DEC 5000's seem to be happier that
  way...


   greg pavlov
   pavlov@fstrf.org