Re: Race in MSCP (ra/rx) driver

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2020-08-27 00:17, Mouse wrote:
> > [...], and I would have expected MSCP to essentially not require any
> > delays between request and completion.
>
> I think MSCP does not require any delays - I don't recall anything in
> the doc that requires any, at least.

And that is especially true also of the init steps, which are carefully 
designed so that it should be dead simple to just go through them, and 
it should work no matter how fast or slow the controller reacts.

> Poor code, on the other hand, can, in that it can fail to interoperate
> with a peer that does not meet its timing expectations.

Definitely true.

> Paul Koning made a very good point, which I hadn't thought of: even if
> the device is realistically slow, an interrupt from something else at
> the right (or wrong, depending on your point of view) time can steal
> enough cycles for the device to win the race I outlined anyway.

Yes. This has always been the case, and is one reason I always feel a 
little wondering when people want to put in delays and stuff in 
simulations. In real life, this is always a possible scenario, and given 
enough time, combinations of event will happen in such a way you can bet 
it happened that pretty much no instructions were done between request 
and interrupt.

I know that Unix likes to run with elevated priorities, which is one way 
of avoiding such things. I *think* that RSTS/E might be similar.
But I know that RSX very explicitly allows interrupts to nest all the 
time. At very few moments in time do RSX lock out interrupts, and most 
of the time, even in the interrupt handling code, other interrupts are 
allowed to come. There is one known case where there is a bug in RSX, 
which comes back and bites you, and that is the DL11 driver, which, if 
fed data too fast, actually ends up reversing the received data into the 
OS because of nested interrupts. So that one I know requires some 
minimum time allowed for RSX to handle the interrupt before you send the 
next one.

I would expect VMS to be the same.

Of course, there might just be some other general aspect that I'm not 
thinking of right now, but thinks like MSCP, as I said, were designed as 
to make it possible to work fine no matter what the speed of the CPU or 
the peripheral.
Think of a Unibus SCSI MSCP controller with a modern disk, on a 
PDP-11/05. I have all expectation it should work just fine, and there I 
wouldn't be surprised if the actual controller request might complete 
before that darn slow CPU managed to figure out a single instruction.

(Are there any slower Unibus machines? I think the slowest VAX would be 
an 11/725, but I don't think that is anywhere near an 11/05.)

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol