Date: Fri, 15 May 1998 12:07:21 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: The Hermit Hacker <scrappy@hub.org> Cc: scsi@FreeBSD.ORG Subject: Re: Atrocious transfer rates... Message-ID: <199805151807.MAA23536@narnia.plutotech.com> In-Reply-To: <Pine.BSF.3.96.980515134003.304A-100000@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi... > > Well, just plugged in the newest CAM snapshot, got everything > compiled and installed, and am getting terrible transfer rates, as far as > I can tell...granted, I just might be missing something in my kernel > config, but I swear my pre-CAM kernel had better performance, with pretty > much no change in settings. > > By slower, I mean that the VIKING II below, that I ran IOZONE on > several times with the older driver, was reporting closer to 11Meg/s... > > ==================================================================== > hub> dmesg | grep da2 > da2 at ahc1 bus 0 target 1 lun 0 > da2: <Quantum XP34300W L912> Fixed Direct Access SCSI2 device > da2: Serial Number PCB=JF60324939 U; HDA=MP62542171 > da2: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing First off, upgrade both of your Atlas I drives L915 firmware. It fixes quite a few problems with tagged queuing. > hub# dmesg | grep da0 > da0 at ahc0 bus 0 target 0 lun 0 > da0: <QUANTUM VIKING II 4.5WSE 3506> Fixed Direct Access SCSI2 device > da0: Serial Number 194805310043 > da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) > (da0:ahc0:0:0:0): tagged openings now 63 > > Writing the 82 Megabyte file, 'iozone.tmp'...13.632812 seconds > Reading the file...15.726562 seconds > > IOZONE performance measurements: > 6307079 bytes/second for writing the file > 5467388 bytes/second for reading the filehub Hmm. It could be one of a few things. Some drives do not perform well for sequential I/O if the tag count is too high. It seems that they are somehow pre-empted when the new command comes in even though most devices have a separate protocol engine and I/O processor. So, you could try going into sys/cam/cam_xpt.c and lowering the default high tag count to something less than 64. This will likely decrease your non-sequential I/O performance, so be careful how you tune the parameter. Your Viking appears to max out at 63 and the system is saturating the drive with that many transactions active. iostat may give you some interesting information in this area too. The old SCSI driver defaulted to either 4 or 8 tags, whereas CAM will use up to 64 depending on what the drive supports. The other possible cause for a degradation in performance is the CPU cost of performing the bufq_disksort in scsi_da.c. You can easily check this by going into sys/cam/scsi/scsi_da.c and replacing the bufq_disksort call with a call to bufq_insert_tail. It may be that we should only perform the disksort if tagged queuing isn't supported or the tagged count is too low, but I do believe that the additional elevator sort does increase performance for non-sequential I/O when lots of buffers are queued. -- 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?199805151807.MAA23536>