Date: Fri, 5 Nov 1999 00:06:31 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Chris Dillon <cdillon@wolves.k12.mo.us> Cc: scsi@FreeBSD.ORG Subject: Re: SYM-0.9.0 ok for 3.3 and -current (was SYM driver available for -stable) Message-ID: <Pine.LNX.3.95.991104234012.646A-100000@localhost> In-Reply-To: <Pine.BSF.4.20.9911032231280.46291-100000@mail.wolves.k12.mo.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 1999, Chris Dillon wrote: > On Mon, 1 Nov 1999, Gerard Roudier wrote: >=20 > > I had updated my local repository last week-end and have had time this= =20 > > week-end for checking that SYM-0.9.0 compiles ok for 3.3 and -current a= s=20 > > expected, and btw works fine for me under these O/S versions. >=20 > Well, I'm beating on your driver as I write with a 'make -j 8 world', > a copy of the entire CVS repository from one drive to another, and a > restore from tape to a scratch part of a drive, all at the same time. Thanks a lots for reporting your success using the sym driver. =20 > sym0: <875> rev 0x03 int a irq 10 on pci0.18.0 > sym0: Tekram NVRAM, ID 7, Fast-20, parity checking > sa0 at sym0 bus 0 target 5 lun 0 > sa0: <SONY SDT-5200 3.30> Removable Sequential Access SCSI-2 device=20 > sa0: 5.000MB/s transfers (5.000MHz, offset 8) > cd0 at sym0 bus 0 target 2 lun 0 > cd0: <NEC CD-ROM DRIVE:463 1.05> Removable CD-ROM SCSI-2 device=20 > cd0: 10.000MB/s transfers (10.000MHz, offset 15) > cd0: Attempt to query device size failed: NOT READY, Medium not > present > da0 at sym0 bus 0 target 0 lun 0 > da0: <IBM DCAS-34330W S65A> Fixed Direct Access SCSI-2 device=20 > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > da1 at sym0 bus 0 target 1 lun 0 > da1: <IBM DCAS-34330W S65A> Fixed Direct Access SCSI-2 device=20 > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) >=20 > Everything is working great. I haven't done any type of benchmarking > yet to see which driver is faster for me, but so far they appear to be > about the same. I know of all the parts where the drivers have significant differences. Most are also known by the FreeBSD SCSI team, given what I read from them, by the way. The ncr has been a great driver and is now quite fine for most situations, but will not sustain the comparison with the sym in extremes situations. In fact, the sym driver is kind of the ncr driver's son. This point appears clearly in the Header part of all sym driver source files. Consider for example the command overhead without disconnections: - sym : less than 62 micro-seconds - ncr : at least 70 micro-seconds more than the sym (difference measured) Then the reselected pattern with a large number of tags: - sym : 0(1) from SCRIPTS (table of jump addresses indexed by tag) - ncr : 0(number of tags) (list scanned from SCRIPTS) Then the DONE processing from the C code: - sym : DONE queue filled by SCRIPTS and read by C code O(1)/active cmds - ncr : scan of the entire lists of CCBs (can be reduced to active ones) For the 896/895A and further chips as the C1010 - sym : handling of data phase mismatch from SCRIPTS - ncr : handling of data phase mismatch from C code Those are the main enhancements, some other are also very interesting, but= =20 may-be this will make my reply way boring. As you know, only 100 micro-seconds are needed to burst 8KB over an Ultra2 wide SCSI BUS and only 50 micro-seconds will be enough for Ultra3. For this reason, only a SIM/HBA pair that allows low command overhead (using also fast SCSI devices) can gain advantage of such fast data throughput over SCSI for real applications. On the other hand kernels and applications must be smart enough for actual IOs transactions not to be too small for Ultra2/3 SCSI BUSes to be well used.=20 > I don't know if this is because of the sym driver or not, but I have > noticed that under all this load there is approximately a .5 > (one-half) second freeze every 5 to 10 seconds, and the SCSI activity > light goes out entirely. This makes system responsiveness seem > "choppy". According to systat -vmstat 1, interrupts for the SCSI > controller drop very low (40-50) during the freeze and then peak at > about 300 interrupts per second after the freeze is over. Interrupts This might well be due to some cause in the kernel, but I will try to=20 understand what does happen. > average 100-125 interrupts per second normally. Since systat is > reporting interrupts per second, the freeze is approximately one-half > second, and the running average is 100-125 interrupts/second, that > would lead me to believe that NO interrupts are occurring for the SCSI > controller during that freeze. Tomorrow I'll put the ncr driver under > the same load and see if I experience the same choppiness. All of my > filesystems are running softupdates, so the large bursts of I/O caused > by softupdates might have something to do with it. >=20 > Well, the 'make -j 8 world' just finished, and everything is happy. >=20 > Great work, Gerard! Thanks for your confidence in this driver. G=E9rard. 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?Pine.LNX.3.95.991104234012.646A-100000>