Date: Tue, 21 Apr 1998 22:23:03 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Peter Wemm <peter@netplex.com.au> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Message-ID: <199804220426.WAA29887@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 22 Apr 1998 12:06:48 %2B0800." <199804220406.MAA01011@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>Ahh... Yes, this indeed does make a lot of difference. :-) It's running >now "just fine" so far (touch wood) on both a BT545S and 445S (with 16MB >crossover blocked). Yeah! >--- bt_isa.c.save Tue Apr 21 00:59:42 1998 >+++ bt_isa.c Tue Apr 21 15:15:23 1998 >@@ -304,6 +304,8 @@ > > if (addr >= bt->bios_addr > && addr < (bt->bios_addr + BIOS_MAP_SIZE)) >+ return (1); >+ if (addr == 0) > return (1); > return (0); > } I have something similar committed in the CAM Perforce repository. >It hardly seems worth testing for firmware rev 3.35 or >earlier.. (although it would be relatively simple to store an extra flag >in the bt_softc at probe time and simply test it here rather than a >string compare for each filter call.) Filter functions are cheap, so if we really feel it necessary to not bounce those few extra pages, we might as well have a special filter. Of course, when compared to bouncing all pages over 16MB, the difference is so insignificant that I didn't bother when I added this change to Perforce. >da0: 10.0MB/s transfers (10.0MHz, offset 8) >da0: 516MB (1057758 512 byte sectors: 64H 32S/T 516C) >(da1:bt0:0:1:0): tagged openings now 25 >(da1:bt0:0:1:0): tagged openings now 24 >(da1:bt0:0:1:0): tagged openings now 23 >(da1:bt0:0:1:0): tagged openings now 22 >(da1:bt0:0:1:0): tagged openings now 21 >(da1:bt0:0:1:0): tagged openings now 20 >(da1:bt0:0:1:0): tagged openings now 19 >(da1:bt0:0:1:0): tagged openings now 18 >(da1:bt0:0:1:0): tagged openings now 17 >(da1:bt0:0:1:0): tagged openings now 16 >(da1:bt0:0:1:0): tagged openings now 15 This is something I didn't expect to see. The documentation I have seemed to indicated that the queue full condition was handled internally to the cards firmware so we'd never see them to know to lower the queue depth. I wonder if this is the case with newer firmware too. I certainly hope so since it will prevent us from wasting resources on devices that won't benefit. >The system seems to feel more responsive relative to the AHA1542CF that it >used to have. :-) It's only an ISA/VLB 486DX2-66 w/ 32M of ram and needed >all the help it could get. Tagged queuing makes a huge difference. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804220426.WAA29887>