12 Mar
2005
12 Mar
'05
6:24 a.m.
On Mar 11 2005, 23:39, Witchy wrote:
having
> No. It's only the RQDX1 that has the "must be last on the bus"
> problem, and only then if what's below it uses DMA and interrupts.
> RQDX2 and RQDX3 have no such limitation. You won't find an RQDX1
in a
MicroVAX II
because it is not compatible with the MicroVAX II
processor.
I know of the incompatibility but I'm surprised at the RQDX3 not the limitation - every single microPDP and qbus uVAX I
used,
installed or
watched Failed Circus maintain had to have the disk
controller last
on the
bus; the only exception to this was if you had the
RQDXE extender for
external drives. Even the machines I've got here now are built like
that.
The RQDX2 and RQDX3 definitely don't have the limitation. It's in the
manuals, and also in Micronotes. I've seen lots of PDP-11s where the
RQDX is not the last device, and my MicroVAX-II came with its RQDX3
further up, as well. If you have an RQC25 (then you have my
commiserations) it usually goes below the RQDX, as does a KDA50 or a
DRV11, according to Micronote 041. And of course if you have two
RQDX2/3 controllers, one after the other, both work. That's not true
of an RQDX1 (you can only have one).
In general, the main reason for the order of things on the QBus has to
do with interrupt priority and latency. For example, a DL serial
interface can't deal with being too far down the bus, so it usually
goes right after the memory; similar rules apply to a DEQNA. However,
a DHV11 or a DHQ11 is a bit better, so it can go further down. Tape
controllers are often less tolerant than disks, especially if they're
supposed to be operated in streaming mode, so they usually go higher
up.
As I mentioned, even DEC's notes show a config with an RQDX3 further
up. However, one of the FS memos says "This device may have to be
placed as the last device in the CPU box because of cabling
requirements." Also, there is a performance issue with the RQDX2 in
systems using lots of block-mode DMA, because while the RQDX2 is doing
a block transfer, it holds the bus for longer than is desirable and
blocks BDMR while doing so (it does pass it the rest of the time, and
an RQDX3 doesn't block BDMR at all). So it should be below things that
have problems with latency, like Ethernet or DECnet controllers.
However, an RQC25 is even worse in that respect, and it does block
transfers in pairs!
What's recommended by Field Circus, what's "supported" by DEC, and what
works, are three different things!
--
Pete Peter Turnbull
Network Manager
University of York