8 Nov
2005
8 Nov
'05
8:52 a.m.
From a post I made to the PDP-11 newsgroups in the
previous
millenium:
The benchmarks were done under RT11FB 5.7 doing 1, 2, 4, 8, 16,
32, and 64 block-at-a-time READW's and WRITW's to 16384-block
data files. A KDJ11B (PDP-11/73) CPU with 2 Megabytes of Clearpoint
non-PMI memory was used for the bencharmks. With the SCSI
controllers a Barracuda 7200 RPM ST15230N drive was used; with
the RQDX3 a RD52 drive was used.
Here are the peak data rates measured for read and write 64
blocks-at-a-time:
Read Write
---------- ----------
Andromeda SCDC 2.298 MB/s 1.131 MB/s
CMD CQD440 2.397 MB/s 1.525 MB/s
CMD CQD220 1.418 MB/s 0.882 MB/s
CMD CQD220A 2.088 MB/s 1.409 MB/s
DEC RQZX1 1.379 MB/s 1.097 MB/s
Viking QDT 0.846 MB/s 0.704 MB/s
DEC RQDX3 0.164 MB/s 0.161 MB/s
8 Nov
8 Nov
10:14 a.m.
On 11/8/05, Tim Shoppa <tshoppa at wmata.com> wrote:
Thank you. After analyzing the Qbus activity diagram I conclude that
my controller won't be fast. There are several reasons.
1. The overhead of 53C90A chip is significant. I may try 53C94/96 later.
2. The ISA DMA is slow for the getpkt(), putpkt(), getdesc() and
putdesc() functions. 80188XL won't be faster.
3. The 80386-16 is slow in executing the MSCP code written in C.
80188XL won't be faster.
To improve 1, I need a faster SCSI chip, or need to integrate it into
the CPLD. To improve 2, I need a small cache to speed up the DMA, or
need a faster microprocessor. To improve 3, I need a faster
microprocessor, and I may need to rewrite the code in assembly
language.
So the conclusion is, with the corrent design, the controller won't be
fast. I am reluctant to rewrite it in assembly language because I
don't want to divert too much away from the SIMH code. I may improve
the code to speed it up a little bit, maybe to 400kB/s. I am happy
that it can beat RQDX3.
vax, 9000
From a post I
made to the PDP-11 newsgroups in the previous
millenium:
...
Here are the peak data rates measured for read and write 64
blocks-at-a-time:
Read Write
---------- ----------
Andromeda SCDC 2.298 MB/s 1.131 MB/s
CMD CQD440 2.397 MB/s 1.525 MB/s
CMD CQD220 1.418 MB/s 0.882 MB/s
CMD CQD220A 2.088 MB/s 1.409 MB/s
DEC RQZX1 1.379 MB/s 1.097 MB/s
Viking QDT 0.846 MB/s 0.704 MB/s
DEC RQDX3 0.164 MB/s 0.161 MB/s
12 Nov
12 Nov
9:01 p.m.
New subject: MSCP SCSI controller speed on UNIBUS
9000 VAX wrote:
On 11/8/05, Tim Shoppa <tshoppa at wmata.com>
wrote:
>>From a post I made to the PDP-11 newsgroups in the previous millenium: ...
>Here are the peak data rates measured for read and write 64 blocks-at-a-time:
>
> Read Write
> ---------- ----------
>Andromeda SCDC 2.298 MB/s 1.131 MB/s
>CMD CQD440 2.397 MB/s 1.525 MB/s
>CMD CQD220 1.418 MB/s 0.882 MB/s
>CMD CQD220A 2.088 MB/s 1.409 MB/s
>DEC RQZX1 1.379 MB/s 1.097 MB/s
>Viking QDT 0.846 MB/s 0.704 MB/s
>DEC RQDX3 0.164 MB/s 0.161 MB/s
>
>
And for yucks on a UNIBUS 11/44 running 2.11BSD dd bs=16384 count=1000:
>EMULEX UC-18 0.585 MB/s not tested
target is ST32550N
> 0.245 MB/s not tested targer is RRD43 CDROM
>
>
13 Nov
13 Nov
10:14 a.m.
New subject: MSCP SCSI controller speed on UNIBUS
On 11/12/05, Don North <ak6dn at mindspring.com> wrote:
And for yucks on a UNIBUS 11/44 running 2.11BSD dd
bs=16384 count=1000:
>>EMULEX UC-18 0.585 MB/s not tested target is ST32550N
>> 0.245 MB/s not tested targer is RRD43 CDROM
Thank you. I came up a way to speed up the controller. It is
overlapped execution, just like what CVAX chips do. When the
controller is busy with current SCSI request, it at the same time
ending the previous request and preparing the next request. The speed
may be doubled. I will do this only when I have time.
cheers,
vax, 9000
14 Nov
14 Nov
9:59 a.m.
New subject: MSCP SCSI controller speed on UNIBUS
>>>> "9000" == 9000 VAX
<vax9000 at gmail.com> writes:
9000> On 11/12/05, Don North <ak6dn at mindspring.com> wrote:
> And for yucks on a UNIBUS 11/44 running 2.11BSD dd
bs=16384
> count=1000:
>
> >>EMULEX UC-18 0.585 MB/s not tested target is ST32550N >> 0.245
> MB/s not tested targer is RRD43 CDROM
9000> Thank you. I came up a way to speed up the controller. It is
9000> overlapped execution, just like what CVAX chips do.
What does CVAX have to do with it? Overlapped execution has been a
standard way to get high speed I/O for a very long time. Almost all
computers support it (weirdos like the IBM 1620 excepted).
paul
6826
days inactive
6832
days old
4 comments
4 participants
participants (4)
-
ak6dn＠mindspring.com -
pkoning＠equallogic.com -
tshoppa＠wmata.com -
vax9000＠gmail.com