Greetings and Electrifications!

>David Laight proclaimed:

>> >> OK.  This also makes sense.  And, a rational tradeoff -- data
>> >> on the SCSI will still *be* there when you get around to it
>> >> a bit later; the network packet *won't*!
>> >
>> >Absolutely - unfortunately I came to the conclusion that the cpu is
given
>> >priority over the sbus on accesses to main memory.  This will slightly
>> >improve SCSI benchmarks (the cpu will not stall on memory until it is
>>
>> Huh?  Oh, if using the *onboard* SCSI!  Presumably, the advantage
>> disappears if the CPU has to talk to an SBUS SCSI...?
>>
>> >looping waiting for the data), but has a serious, detremental effect on
>> >network traffic when the cpu is trying to use 100% of teh memory
bandwidth.
>> >(I never did find out whether the relevant arbiter worked that way).
>
>But the cpu is looping executing from its cache waiting for an interrupt,
>no bus activity at all.


Yes, but *prior* to that point, the internal SCSI would still be able
to compete for access to main memory whereas an SBUS card would
lose the competition to a memory bound CPU (?)

Ah, wait.  You (?) said the onboard stuff is really *also*
part of the SBUS subsystem -- just wired at a "higher slot
number".  In that case, the CPU *always* wins, right?
(regardless of where the SCSI controller resides)

(it's still early in the morning... I'm a bit "slow"  :>)

--don