9 Nov
2005
9 Nov
'05
1:27 p.m.
Subject: Re: MSCP SCSI controller speed
From: 9000 VAX <vax9000 at gmail.com>
Date: Wed, 09 Nov 2005 00:23:01 -0500
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
You are right. Those two are not the bottleneck. I measured the actual
execution time when run "dd if=syssrc.tar of=/dev/null" (photo
attached). NetBSD 1.5.2 moves 16kB a time. The measured time is:
4.75ms MSCP-pre-DMA overhead
0.4ms SCSI overhead
7ms DMA of 16kB
4.2ms MSCP-post-DMA overhead
31ms idle time
What kills the speed is the 31ms idle time. I blame NetBSD for that.
You need a real time or single user os to get better results. Plain old
dos might do far better or maybe a custom kernal tuned for this use.
nor wished to
program PCs. That and someone gave me a CMD SCSI adaptor. ;)
You are lucky. Nobody gives me CMD card. But from now on I probably
will not need one any more. 
9 Nov
9 Nov
5:22 p.m.
>>>> "Allison" == Allison
<ajp166 at bellatlantic.net> writes:
> Subject: Re: MSCP SCSI controller speed From: 9000
VAX
> <vax9000 at gmail.com> Date: Wed, 09 Nov 2005 00:23:01 -0500 To:
> "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
>
> You are right. Those two are not the bottleneck. I measured the
> actual execution time when run "dd if=syssrc.tar of=/dev/null"
> (photo attached). NetBSD 1.5.2 moves 16kB a time. The measured
> time is:
>
> 4.75ms MSCP-pre-DMA overhead 0.4ms SCSI overhead 7ms DMA of 16kB
> 4.2ms MSCP-post-DMA overhead 31ms idle time
>
> What kills the speed is the 31ms idle time. I blame NetBSD for
> that.
Allison> You need a real time or single user os to get better
Allison> results. Plain old dos might do far better or maybe a
Allison> custom kernal tuned for this use.
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.
Certainly if you do single I/Os and wait for the answer each time,
things will be slow, but the OS isn't really at fault then.
paul
8:17 p.m.
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
10 Nov
10 Nov
3:57 a.m.
On 11/9/05, Brad Parker <brad at heeltoe.com> wrote:
Paul Koning wrote:
16384000 bytes transferred
in 21 secs (780190 bytes/sec)
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
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
4:06 a.m.
On 11/9/05, 9000 VAX <vax9000 at gmail.com> wrote:
OK, maybe you are right. The write operation should be faster. The OS
latency there is smaller. It was my controller that slowed down the
write operation. I need to take a look to find out why.
vax, 9000
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.
4:16 a.m.
On 11/9/05, 9000 VAX <vax9000 at gmail.com> wrote:
On 11/9/05, 9000 VAX <vax9000 at gmail.com>
wrote:
OK, maybe you are right. The write operation should be faster. The OS
latency there is smaller. It was my controller that slowed down the
write operation. I need to take a look to find out why.
The read operation used block mode DMA and the write operation used
burst mode DMA (slower). It seems there is more debugging work to do.
vax, 9000
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.
vax, 9000
5:54 p.m.
9000 VAX wrote:
On 11/9/05, 9000 VAX <vax9000 at gmail.com>
wrote:
The read operation used block mode DMA and the write operation used
burst mode DMA (slower). It seems there is more debugging work to do.
I didn't want to get into caching, but what the heck. It's quite
possible that once you "read" the file it will be in the block cache.
So you may get skewed results - cached blocks won't come from the
device. The first read should be ok, however.
The simplest thing is to read/write the "raw" device (not the block device)
which will be uncached. This, of course, runs the risk of trashing any
file system if there is one (when writing). Please be careful.
-brad
On 11/9/05, 9000 VAX <vax9000 at gmail.com>
wrote:
> >
> > 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.
OK, maybe you are right. The write operation should be faster. The OS
latency there is smaller. It was my controller that slowed down the
write operation. I need to take a look to find out why.
8:05 a.m.
On 11/9/05, Brad Parker <brad at heeltoe.com> wrote:
...
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.
Now both r/w are working with block mode DMA. The read speed is now
780190 bytes/sec,
the write speed 963764 bytes/sec. It conforms your analysis. The board
now beats Viking QDT, but is still slower than other boards. Maybe it
will be a little bit faster with RT11. There can be small improvements
when I clean up the code too. But I don't expect it to be faster than
CMD CQD220. What I can say is it is quite usable.
Thank you guys for helping me about the speed issue. The next step is
to port the C under DOS code to 80188XL.
best wishes,
vax, 9000
...
7099
days inactive
7100
days old
7 comments
4 participants
participants (4)
-
ajp166＠bellatlantic.net -
brad＠heeltoe.com -
pkoning＠equallogic.com -
vax9000＠gmail.com