MSCP controllers

Allison ajp166 at
Fri Oct 5 11:24:35 CDT 2007

>Subject: Re: MSCP controllers
>   From: "Jerome H. Fine" <jhfinedp3k at>
>   Date: Fri, 05 Oct 2007 09:51:38 -0400
>     To: General Discussion: On-Topic and Off-Topic Posts <cctalk at>
> >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.

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.

>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) 

>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.


More information about the cctalk mailing list