On Tue, Jan 17, 2006 at 08:29:56PM +0100, Hauke Fath wrote:
> At 8:48 Uhr -0800 17.1.2006, Chuck Silvers wrote:
> >does anyone know what problems still exist with the sbc driver that
> >would prevent us from switching to that and getting rid of the
> >mac68k-specific ncrscsi driver?
> 
> 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?


> > the MI driver is 50% faster and uses 1/3 less CPU time than the MD driver.
> 
> Is it? Which machine, which disk, which benchmark? You are aware that a
> busy NetBSD/mac68k loses time so badly that any benchmark data is to be
> taken with a spoon of salt?  ;)

it's a Mac IIci.  the disk is:
sd0 at scsibus0 target 0 lun 0: <FUJITSU, M2616S, 1003> disk fixed
sd0: 100 MB, 1544 cyl, 4 head, 33 sec, 512 bytes/sect x 205086 sectors

my benchmark was:
time dd if=/dev/rsd0c of=/dev/null bs=1m count=5

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.

I did some more experiments, where I actually watched a clock myself
to see how long the dd took, and then also used ntpdate to see how far
that thought the clock had lagged during the transfer.

sbc, flags 1
5242880 bytes transferred in 0.537 secs (9763277 bytes/sec)
0.067u 0.907s 0:00.94 102.1%    0+0k 0+0io 1pf+0w
~9 secs observed
17 Jan 22:26:38 ntpdate[367]: step time server 1.1.1.1 offset 8.306116 sec
throughput adjusted for time loss: 592877 bytes/sec


sbc, flags 7
5242880 bytes transferred in 8.429 secs (622004 bytes/sec)
0.050u 2.162s 0:08.89 24.8%     0+0k 0+0io 1pf+0w
~9 secs observed
17 Jan 22:14:56 ntpdate[370]: adjust time server 1.1.1.1 offset 0.210778 sec
throughput adjusted for time loss: 606830 bytes/sec


ncrscsi
5242880 bytes transferred in 11.203 secs (467988 bytes/sec)
0.062u 4.361s 0:11.66 37.9%     0+0k 0+0io 1pf+0w
~13 secs observed
17 Jan 22:39:48 ntpdate[351]: step time server 1.1.1.1 offset 1.452711 sec
throughput adjusted for time loss: 414269 bytes/sec


so the time loss is still pretty bad for the ncrscsi driver,
but not so much that I noticed immediately from this test.
sbc with flags 7 does much better.


> Actually, folklore has it that ncrscsi is faster than sbc...

doesn't seem to be true for me.  :-)


> >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.
> 
> Again, which machine, which disk? To give an example, the IIsi that is
> la.causeuse.org has
> 
> # SBC_PDMA      0x01    /* Use PDMA for polled transfers */
> # SBC_INTR      0x02    /* Allow SCSI IRQ/DRQ interrupts */
> # SBC_RESELECT  0x04    /* Allow disconnect/reselect */
> sbc0    at obio? flags 0x1              # MI SCSI NCR 5380
> 
> for a DEC 1G disk that originally came with a Sun IPX. I tried at the time,
> but nothing else worked. Quantum disks, OTOH, usually play nice with
> ncrscsi.
> 
> It's a pity we didn't collect data when MacBSD users were still frequent;

yea, that's unfortunate, but there still seem to be a few people around.


> 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.

-Chuck


> Allen Briggs (ncrscsi) and Scott reynolds (sbc) may have more to say.
> 
> My 2 Cent,
> 
> 	hauke
> 
> 
> --
> "It's never straight up and down"     (DEVO)
>