MSCP SCSI controller speed

[9000 VAX]

On 11/9/05, Brad Parker <brad at heeltoe.com> wrote:
>
> 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
16384000 bytes transferred in 21 secs (780190 bytes/sec)
>         dd if=/dev/zero of=blah.null bs=16k count=1000
16384000 bytes transferred in 35 secs (468114 bytes/sec)
>
> I suspect the write will be faster, and reflect the true speed of the i/o.
It is the opposite. strange.
>
> 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
>
>