Date: Thu, 11 Nov 1999 12:20:27 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: mdragon@vera.net Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SYM 0.9.0-19991024 O.K. Message-ID: <Pine.LNX.3.95.991111110822.359A-100000@localhost> In-Reply-To: <Pine.BSF.4.20.9911110041310.17928-100000@mail.vera.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Nov 1999 mdragon@vera.net wrote: > Last night we tested this controller on a HP-Netserver LH4 (53c895 fast40 > scsi) this machine has 2 Xeons and 4 9Gb-10,000 rpm. disks and we found > no problems and a performace(*) gain of roughly 3-4% over the standard > ncr0 controller. 3 disks are configured as a ccd device with a 8192 > interleave, Kernel 3.3-stable. Thanks for your report. I am very glad of the driver being solid. In my opinion, the conditions for getting performance gain using the sym driver are the following: - Disk capable of very low command overhead. The sym driver has been measured by me 62 micro-seconds while the ncr got more than twice this value in the same situations. - Large numbers of tags. The sym driver uses O(1) on all pathes but the ncr scans lists of CCBs from the C code and from the SCRIPTS as well. But, if the load of your machine does not experience a bottleneck on any resource (including CPU on heavy IO load), then the caching and prefetching does eat latencies for both drivers and no significant performance gain will probably be observed.=20 You must also consider other sym driver features as: - NVRAM support. - Hardware phase mismatch handling for the 896/895A that ensures the system will get at _most_ 1 interrupt per actual IO. > [(*) not even a real benchmark: just running du, dd, > find . -exec grep, and tar cf - | tar xf - ] >=20 > A fact that troubles me is that sym0 was able to set the transfer speed t= o > 80.000 MB/s. and the only change in the kernel configuration file was > adding the sym0 line, I can't figure out why ncr0 always sets transfer > speed to 40 MB/s. It does not seem to exist a really clean way for that, since: - If SCSI_NCR_MAX_SYNC is not defined, the ncr driver will assume default sync period factor to be 12 (20 mega-transfers/second) - If defined, the driver will calculate default sync factor as: #define=09SCSI_NCR_DFLT_SYNC (250000 / SCSI_NCR_MAX_SYNC) which is incorrect for MAX_SYNC >=3D 20000 (SCSI > 2) But the ncr init code (I adapted to ULTRA/ULTRA2 SCSI support two years ago) keeps track of _actual_ min sync factor based on controller capability and a correct value will be proposed to SCSI devices in any situation. So, something like the following in your kernel config file: options SCSI_NCR_MAX_SYNC=3D40000 should do the trick. (25000 should work as well, see above) > I remember that a similar kernel was built on a HP LPr (same 53c895 > controller, same disks) and ncr0 also set the transfers speeds to > fast40-wide. What am I doing wrong? >=20 > My list of questions: > - Is vinum prefered over ccd ? > - Is someone working on the AMI MegaRAID controller ? I am not competent for these ones (notably :) ). > - Is it possible to use this raid somehow ?=20 I would be highly surprised an AMI-raid volume be recognized by either ccd or vinum, so a SIM for AMI-raid may actually be required. > (maybe through bios, at least the bootloader can recognize it) > Would sym0 find the raid ? I have the idea that it should, since it > appears in the SCSI bus as id #0 lun #1 sym and ncr donnot know about what RAID is. They just communicate with SCSI devices using the SCSI chip capabilities. In order to access AMI-raid volumes you need a specific driver that supports AMI-raid interface. For software raid, the RAID feature is handled by upper layers. For hardware raid (AMI-raid for example) the controller (that consists in some software executed by some Intel IO processor for the AMI-raid) handles RAID and presents logical volumes as LUNs to SIM. When using hardware RAID capable of interfacing SYM53C8XX devices that are visible from the PCI BUS, you must ensure that only a single entity will attach directly (ncr/sym) or indirectly (AMI-RAID) each SYM53C8XX device, otherwise this will not work for sure.=20 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.991111110822.359A-100000>