Subject: Re: State of Powertec support ?
To: Simon Proven <sproven@art.acorn.co.uk>
From: Mark Brinicombe <amb@physig4.ph.kcl.ac.uk>
List: port-arm32
Date: 10/29/1996 19:56:40
>sproven@art.acorn.co.uk

>Why is this necessary?  RISC OS manages transfer rates of ~4M/sec on some
>cards, without DMA.  Even the internal IDE interface can be persuaded to
>break 2M/sec.
Want to give me your RiscOS code ?

The internal IDE at 2MB/sec would be very very nice ;-)

>Are you doing lots of extra work on every sector?
Probably.
Since a lot of the drivers are based on generic source they are not optimised
for particular architectures which does reduce performance.
Take a look at blockio.S This is currently the code used to read and write
sectors from the IDE interface. Improvements in these functions here will
improve IDE transfer times. Once this is fully optimised we can look at other
parts of the wd driver to spot the speed limiters.

What cards gets 4MB without DMA ? The problem that we experience is that having
to poll for every byte is not going to get you 4MB/sec. You will only get that
if you can do block reads / writes to the card (Am I right ?)

Another point with the SCSI 2 cards. The polling driver uses the SCSI
controller for accessing the data. This means that the data is read bytewise
via a 12 byte FIFO in the fas216 controller. Thus polling for a ready flag,
reading a byte, writing it to memory and then repeating is not going to give
outstanding xfer rates.
Now if we could read the data 16 or 32 byte and could do burst reads then we
give significantly improve driver performance.

The main reason for going for generic drivers is that they are quicker to
implemented, are well tested from development on other NetBSD archs and also
we can pull in bug fixes etc from the other ports. The penalty is performance.
The idea is to use the generic code to get driver going and then look at
writing
replacement drivers in the future.
Note also that the RiscBSD drivers are often far more complex than the RiscOS
counterpart due to the nature and requirements of a unix OS.

Cheers,
				Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716