5 Oct
2007
5 Oct
'07
9:24 a.m.
Subject: Re: MSCP controllers
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
Date: Fri, 05 Oct 2007 09:51:38 -0400
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at
classiccmp.org>
All of the MSCP devices have some form of CPU RQDXn is PDP-11
(specifically T-11) other us Z80 or 8088/80188. Regardless
the CPu engine sued there is considerable "intelligence"
for example the RQDX3 carries the T-11, 8KW or ram and 16KW
of Eprom as well as hardware support for disk(floppy and hard)
IO and bus level DMA.
So on one level your expectation is, if you want an intelligent
reponse from the HD: you need to have an intelligent conversation.
RT-11 however is rather dull in that it's conversation is limited
to "do this", and the device does the simple thing and says "here"
RT deals at the logical block level and if there is more than one
block is a sequential read or write, very plain. RT does not even
have the concept of nonsequential file allocation (scatter gather).
More souphisticated operating systems do things like "get me this",
"write out that" and flush this buffer for multiple users and
processes. So the task list is both dynamic and multiple in its
activity. TSX is still RT11 under the skin and only does simple
operations as a result.
Johnny Billquist wrote:
(Sortof starting a new thread)
There have been a discussion about the ineffectiveness of MSCP
recently, especially compared to a dumb controller interface.
To make a few comments on this; yes the MSCP controller is much more
intelligent. But noone have yet talked about what this means.
The overhead for playing with the MSCP controller is way much more
than for a simple, and stupid controller. However, there is also a big
speed gain in some situations.
Jerome Fines observations are correct. Under a single-user system such
as RT-11 (especially of the software acts in a naive way) much of the
advantages of MSCP is lost. The fact that it can deal with large disks
(or disks with different sizes) can hardle be called "intelligent".
That's really primitive.
Things that the MSCP protocol do handle, however, and where the HD:
driver will suffer and loose, is when we get into more advanced stuff.
The MSCP controller can have many I/O requests outstanding at the same
time. Once one operation is completed, it can immediately start the
next one. You actually have a zero setup time with MSCP. So if you're
doing several I/O operations in sequence, a good driver, in
combination with a good program, will be able to get more performance
out of the MSCP controller than the HD: driver, which each new
operation can only be programmed once the previous operation is
completed.
The MSCP controller can also complete several I/O requests with just
one interrupt. No need for one interrupt for each I/O operation that
completes.
The MSCP controller can also reorder I/O operations for better
efficiency. If you have three requests, jumping back and forth over
the disk, it makes sense to actually do the two operations on one end,
before doing the operation at the other end. This can be implemented
in software by the HD: controller, but then we now have more software
that must run before each I/O request is issued.
The MSCP controller handles bad block replacement without the
involvement of the software. It always present a disk without bad
blocks. In real life, all disks have bad blocks, so somewhere this
always needs to be handled. Now, if you have a simulated PDP-11, the
disk is actually a file on that OS, so the underlaying OS will handle
bad blocks for you, so it isn't necceasry for the PDP-11 controller to
do this anymore, but MSCP was designed for raw disks, not emulated
systems. Dealing with bad blocks on the HD: driver would cost a lot.
The MSCP controller can do I/O to several disks in parallel. In real
life, controllers like the HD: driver pretends to talk to exists as
well. One problem with these are that if you have several disks, you
can only do I/O to one disk at a time. Some of these controllers could
allow you to do seeks on other disks while I/O was performed on one
disk. However, things started getting complicated with this.
The MSCP controller have pretty advanced error detection and handling.
Including extensive reports to the software on problems.
Now, those things are why it's more intelligent. And more intelligent
means it also takes more software to talk to it. :-)
MSCP is really like serial SCSI (or serial ATA), only done 20 years
earlier.
Jerome Fine replies:
Johnny, I believe that your comments are very clear and
they address many of the aspects which concern the way
in which MSCP handles read / write requests in both small
systems (single user systems like RT-11 and even TSX-PLUS
since the device driver still handles one request at a time)
and large systems (such as RSX-11 and especially VMS).
(NOTE that all of the following comments are with respect
to running programs on a 750 MHz Pentium III with 768 MB
of RAM using W98SE as the operating system, ATA 100 disk
drives of 160 GB and Ersatz-11 as the application program
running a mapped RT-11 monitor, RT11XM. While I have very
good reason to believe that the same relative results will
be obtained on a Pentium 4 under WXP, again using Ersatz-11
running RT-11, I have done almost no testing at this time.
OBVIOUSLY, comparison with real DEC hardware of a PDP-11
and a VAX can only be done on a relative basis since HD:
exists ONLY under Ersatz-11. In addition, since the speed
of disk I/O on the Pentium III (even more so on a Pentium 4)
is so much faster (more than 100 times) than the transfer
rate on a SCSI Qbus or Unibus, the comparison could be very
misleading since CPU time vs I/O transfer time might become
much more significant. For just one example, when the BINCOM
program that runs on a real DEC PDP-11/73 is used to compare
2 RT-11 partitions of 32 MB on 2 different ESDI Hitachi hard
drives (under MSCP emulation with an RQD11-EC controller),
it takes about the same time (about 240 seconds) to copy
an RT-11 partition and to compare those same 2 partitions.
Under Ersatz-11, the copy time is about 2 1/4 seconds and the
BINCOM time is about 6 1/2 seconds using MSCP device drivers.
When the HD: device driver is used under Ersatz-11, the times
are about 1 second for the copy and about 6 seconds for the
BINCOM - I have not bothered to figure out why the reduction
is only 1/2 second instead of 1 1/4 seconds.)
However, I believe that my comments on the efficiency of
using the MSCP device driver under RT-11 vs the efficiency
of using the HD: device driver probably need to be analysed
much more closely. The other aspect of the analysis that
is missing is the efficiency with with Ersatz-11 implements
the MSCP emulation as opposed to the HD: "emulation". It
is unlikely, but possible, that Ersatz-11 has much higher
overhead for MSCP since the interface is so much more
"intelligent" than the HD: interface only needs to transfer
the data to the user buffer based on the IOPAGE register
values.
A bit more information may help.
(a) The HD: device driver can be used BOTH with and without
interrupts being active after the I/O request is issued.
It makes no difference under W98SE since the I/O request
is ALWAYS complete before even one PDP-11 instruction is
executed. This result also applies to the MSCP device
driver which I could modify to see if it might make a
difference in efficiency. However, when I attempt to
compare the copy of a 32 MB RT-11 partition with HD:,
the time difference between using interrupts and not
using interrupts is so negligible that it is almost
impossible to measure the total time difference to copy
the 32 MB RT-11 partition using the available PDP-11
clock which measures in 1/60 of a second. Since there
are 60 ticks in a second, the accuracy is better than
2% over 1 second which seems adequate to determine on
an overall basis if using interrupts vs no interrupts
makes a significant difference. Obviously if there is
no significant time difference at the 2% level (of one
time tick of 1/60 of a second), then avoiding the extra
RT-11 code to handle the interrupt does not play a
major role in the increased efficiency of HD: vs MSCP.
I conclude that would be the same for MSCP as well.
(b) The other aspect is the ability of MSCP to order
and internally queue I/O requests based on the most
efficient order for them to be performed, probably
when there are many requests outstanding and the
required head movement can be minimized by choosing
the order in which to execute the requests - which
thereby increases overall I/O throughput. If I can
make a suggestion, I respectfully ask what the interface
between the device driver and the controller (or host
adapter in the case of SCSI for MSCP - note that ESDI
controllers are also MSCP) has to do with efficient
internal queuing of I/O requests. Perhaps my viewpoint
based on RT-11 is distorted (or TSX-PLUS for that matter
which uses almost the identical code as RT-11 as far as
I am aware), but I ask the question. It seems to me
that a simple (dumb and efficient) interface such as
HD: is only the final step in instructing the "controller"
to perform the disk I/O whereas the actual "intelligent"
aspect is probably going to be in the device driver
of the respective operating system such as RT-11, TSX-PLUS,
RSX-11 or VMS. Obviously the "intelligent" portion can
also be in the actual controller or host adapter, but based
on my VERY limited understanding of MSCP implementation
by both DEC and 3rd party MSCP controller and host adapter
manufactures for both the Qbus and Unibus, all of the
"intelligence" of internal queuing of I/O requests for
the above 4 example operating systems is performed in
the device driver, if anywhere. Please confirm if my assumption is correct with regard
to
where the "intelligence" is located, i.e. in the device
driver or the controller / host adapter. Based on the
answer, it will then be possible to continue this
discussion. It would be helpful to isolate where the
decreased efficiency of using the DEC concept of MSCP
is introduced and what specifically causes the decrease
in efficiency. For example, on my Pentium III, I have
noted that when I copy large files of 1 GB or larger,
it is almost always useful to to no other disk I/O
during the minute it takes for the copy to complete
unless the additional disk I/O for another job is
trivial in comparison and I can usefully overlap my
time looking a a different screen of information.
Whenever possible, I also arrange to have different
disk files which will be copied back and forth on
different physical disk drives if the files are larger
than about 32 MB since the time to copy any file (or
read a smaller file) is so short in any case. While
I realize that on a large VMS system with hundreds of
users there will be constant disk I/O, I still suggest
that the efficiency of the device driver to controller
interface may play a significant role in overall I/O
throughput rates.
The base intelligence must be on the controller to understand
and act on IO requests. Othe the other hand there is also a
requirement that to use the performance you need to have a
high performing driver. RT-11 does not. The VMS DU driver is.
The difference is the driver for RT11 is essentally a single
task stream, do this, check, do that. The VMS driver will
form up a list of tasks required of the storage system and
so here's a list go do it and let me know when it's done and
what the status for each was.
I do believe what you really pointing at is not MSCP but
the difference in emulation, simulation and real hardware
behavour. I suggest this, emulation/simulation fidelity
has multiple dimensions one being behavour of the programs
code and another is operational speed. It's my experience
with E-11 that program behavour is faithful but speed far
exceeds the original device capabbilities to the limit of
the host PC. The RQDX is old and depends on T-11 and that
CPU is only clocked at 7.5mhz making it rather slow compared
to it's hosts. Where as PC emulation (without throttles) may
have a huge performance advantage is a far faster CPU. So it
makes me ask how would your E-11 simulation look if you could
tell it that the MSCP device and connected disks have a more
limited speed. It also brings to mind is the MSCP emulated
or simple stubbed with PC drivers and devices behind it? I
ask that as MSCP is a copyrighted and encumbered (or was)
protocal.
I await your reply and wish you a good weekend.
I do hope there is s more sophisticated reply as well.
I have the advantage of useing the RQDX in both Qbus
uVAX and Qbus PDP-11 systems so I've seen how the
the VAX (VMS) uses it and how RT-11, and RSX11 use it
the performance over less complex disks like RL02.
Allison