MSCP controllers

Jerome H. Fine jhfinedp3k at
Fri Oct 5 08:51:38 CDT 2007

 >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

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.

I await your reply and wish you a good weekend.

Sincerely yours,

Jerome Fine
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.

More information about the cctalk mailing list