> Date: Mon, 12 Aug 1996 10:52:52 +0100 (BST)
> From: Ale Terlevich <A.I.Terlevich@DURHAM.AC.UK>
> 
> On Mon, 12 Aug 1996, Phil Radden wrote:
>> With only a reasonable amount of fiddling I managed to get RiscBSD working
>> on Cumana SCSI II and PD drive (1.1+X16, not 1.2beta) - except unixfs which
>> resolutely refuses to write to anywhere without crashing the machine...
>> But the main thing about it is that it is SLOW.  Very.  Even in 8Mb you are
>> better off with no swap than swap on the PD, which is fair enough given the
>> PD write-speed...
>> But, IIRC, reading speed is comparable to HD, although seek/write is much
>> slower.  Despite this, during startup etc. the system often freezes for
>> extensive disk activity when it should only be reading/minimal seeking (due
>> to optimisation).  Is this a lost cause, or can I improve anything?
>> Obviously I'm saving for a SCSI HD... :)
> 
>   I think you'll find that the porblem isn't with the drive, but with the 
> kernel driver for the Cumana SCSI II card.
> 
>   IIRC it's still in a very embrionic stage of development and doesn't 
> work on interrupts but polls the card instead. This makes if very slow 
> (I get no more that a few hundred K per sec transfer rate on my SCSI HD)
> and a complete CPU hog. X is certainly unnusable when my SCSI disk is being
> used as the mouse becomes too jerky!
> 
>   I would like to say that I think the kernel team have their priorities 
> right though.  I think it's more important to get the software running 
> properly with large amounts of hardware supported efficiently than to log 
> every single change that happens to the WWW site.  After all everyone who 
> installs RiscBSD is advised to subscribe to this mailing list, and all 
> answers can be found here.... :)

I do not want all changes logged.

All I want is a list of who is doing what, and what is the rough
progress on each device driver:
Cumana scsi driver, done by: so-and-so person

Then one of these (or similar)
- Waiting to start
- Started
- Work in progress
- Working, but not optimized 
- Optimized

- Released as alpha in ...
- Released as beta in ...
- Released in ...

Something like that would be nice.

I also think that the kernel team should concentrate on coding,
but getting the following information updated should take too
long.

Kjetil B.