EDSI Problem

From: Jerome Fine <jhfine_at_idirect.com>
Date: Sat Jul 21 19:53:10 2001

>Chuck McManis wrote:

> Hi Jerome, have you tried moving your disk controllers closer to the
> CPU? moving them up the bus grant chain will help. Also you can tell the
> RQD11-EC to limit its DMA burst size which allows other boards to get in a
> bus cycle when they need to. I had a problem where adding a SCSI controller
> to a VAX killed disk performance on some ESDI drives but it was entirely
> due to the SCSI controller doing large DMAs that interfered with the time
> available for the ESDI drives to read or write buffers.

Jerome Fine replies:

On my original post, I included:
The current configuration is:
2 MBytes quad PMI Memory
2 MBytes quad PMI Memory
11/83 quad CPU
Sigma RQD11-EC quad controller
DHV11 quad serial card
Sigma dual EDSI controller / DLV11-J
TK50 dual controller / TK70 dual controller

So the controller is RIGHT BESIDE the CPU. Actually, on a different
system, I used normal non-PMI memory in the normal position between
the CPU and the controller. There was just one 4 MByte board in this
case and it seems to have had a beneficial effect.

But what I really do not understand about the above configuration is that
when I add an extra module (always at or near the end of the chain), the
only thing that is delayed are the READ operations. The WRITE
operations always manage to run at the faster throughput. Is it possible
that a READ requires a bigger gap between the records (blocks including
their checksums) to confirm the checksum value and every so often the
1:1 interleave does not allow enough time? If a WRITE operation needs
less checking than a READ operation and the number of bytes per sector
is just on the edge (OK for a PC running at 166 MHz, but not for a PDP-11
running at only 15 MHz), then the problem could be explained in this way.

I used the same drive on a PC (Pentium 166 with an ISA ESDI controller) and
had no problems.

On the other hand, with the XT8760E drive from Maxtor, they allow the
sector size to be set at a value which is about 5 extra bytes larger than
either one of the two choices available with the Hitachi DK515-78 hard drive.

It just occurred to me that perhaps there is a very simple solution. If
necessary, I will switch to the XT8760E drive and use the DK515-78
only as the primary backup. My secondary backup is magneto optical
which I will access via a SCSI host adapter using a Sony SMO S501
drive which is somewhat slower and only 300 MBytes per each side
of the removable cartridge. But since I have a large number of cartridges,
having only half the space (i.e. only 8 * 32 MBytes of RT-11 partitions)
in an RT-11 environment is problem which I suspect most RT-11 uses
would have given their right arms for back in 1985 when a RD53 with
all of 70 MBytes (and essentially non-removable and no TK70 as yet
for backup) was about the largest available. I think that the RD54 at
150 MBytes came a year or so later. Note that 1985 is when V5.03
of RT-11 was released with the first MSCP device driver that was
able to handle physical drives larger than 32 MBytes - 8 of them at
one time for a total of 256 MBytes all at once. Of course the actual
physical drive that MSCP could handle in RT-11 was already 2 GBytes,
but only 256 MBytes of that at one time - and in the first V5.03 that DEC
released, only partition ZERO could be booted.

Sincerely yours,

Jerome Fine
Received on Sat Jul 21 2001 - 19:53:10 BST