MSCP SCSI controller speed

[Brad Parker]

Paul Koning wrote:
>
>All you need is an application, or OS, that can queue up multiple
>transfers.  I thought the buffered I/O in Unix would take care of
>that.

er, ah.  I think that's why they created "async i/o" in unix (I first
saw it in solaris).  I don't think bsd will read-ahead in a file, but I
may be wrong.

Writes will certainly buffer up and overlap but I don't think reads
will.  Each read will block until it completes (ignoring the buffer
cache).  After it completes nothing will happen until another read
occurs.  I think this is modulo the basic i/o size (page size in bsd?)
but still true.

	"dd if=syssrc.tar of=/dev/null"

will read, slowly.  I would be interesting to see how long (in comparison)
these two took:

	dd if=syssrc.tar of=/dev/null bs=16k count=1000
	dd if=/dev/zero of=blah.null bs=16k count=1000

I suspect the write will be faster, and reflect the true speed of the i/o.

if I'm all wet please correct me.  things have changed in the flow from
2.9,2.11,*bsd->sunos->solaris->freebsd->netbsd->linux :-) Modern *nix's
are more proactive and blur the line between vm pages and file buffer
blocks (which is good).

(can you mmap a file in bsd?  if you can then you could simulate read-ahead
by just peeking at a byte 16k ahead of where you are copying from.  but
I don't think you can mmap files in bsd. too bad.  everything should be
in your local address space :-)

-brad