Subject: Re: MI "sbc" vs. MD "ncrscsi" driver for NCR 5380
To: Chuck Silvers <chuq@chuq.com>
From: Scott Reynolds <scottr@clank.org>
List: port-mac68k
Date: 01/22/2006 15:01:50
On Jan 18, 2006, at 10:29 AM, Chuck Silvers wrote:

>> Folklore has it that there are SCSI devices that work with one but  
>> not the
>> other, or vice versa (or none, like a Sun branded Seagate 420 MB  
>> disk I
>> have around).
>
> what does that seagate disk do with the sbc driver with flags 7?

Side note: I lost a lot of sleep trying to make the driver reliable  
with flags 7. It worked better on some disks than others. I wouldn't  
run a production system on it without at least a few days of load  
testing with the disks you intend to use.

> I noticed massive problems with lost clock interrupts for the sbc  
> driver
> with the config having "flags 1", but for the other things I tried
> it seemed at least close to correct.

These results aren't surprising. The problem here is that the timer  
interrupt has a lower priority than everything else(!!). Anything  
that exercises hardware interrupts to even a moderate degree will  
cause the clock to drift. Setting the 0x4 flag, particularly, reduces  
the number of interrupts triggered.

>> Actually, folklore has it that ncrscsi is faster than sbc...
>
> doesn't seem to be true for me.  :-)

Now, this surprises me. My own experience was that sbc with flags 1  
was slower. I knew the system clock wasn't reliable to I resorted to  
the insanely-large-copy-and-stopwatch method.  With my test hardware  
I seem to recall seeing ncrscsi being about 30% faster than sbc.

>>> also, does anyone know why the GENERICSBC config only turns on PDMA
>>> and not disconnects or interrupts?  I tried turning them on an it
>>> worked for me.

(See above re: flags 7.)

>> but there _was_ a reason for keeping both drivers, and the driver  
>> code
>> hasn't seen significant change for many years.
>
> sbc seems to be working very well at this point, at least for me.

I rather suspect that the reason that some drives had trouble with  
sbc was the bug you recently fixed. I was so focused on getting the  
interrupt-driven PDMA to work that I never really focused on the  
issue of ncrscsi vs. sbc. That my own testing found sbc to be slower  
certainly contributed to this.

I'm encouraged by your results. Thanks for sharing them! I'd be  
interested to know if your success continued with the system under  
heavy disk load. I'm not sure if that's practical for you, though.

--scott