Date: Fri, 15 Oct 1999 11:20:19 +0100 (WEST) From: Joao Pagaime <jpsp@rccn.net> To: "Kenneth D. Merry" <ken@kdm.org> Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 - It works! Message-ID: <Pine.BSF.4.10.9910151111200.15842-100000@atlas.rccn.net> In-Reply-To: <199910142255.QAA46124@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Oct 1999, Kenneth D. Merry wrote: > Joao Pagaime wrote... > > > > I have a very slow Pentium III/450 with 512MB RAM > > because disks tranfers are slow. > > > > Simple tests show a transfer rate of +/- 2MB/sec, > > when a PC with IDE can do easily at least 4 times > > that value. > > > > I think the problem is with the "Common Access Method" > > in the backplane, because although the controllers are > > found with no problem : > > > > ahc0: <Adaptec aic7890/91 Ultra2 SCSI adapter> rev 0x00 int a irq 11 on > > pci2.4.0 > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > ahc1: <Adaptec aic7860 SCSI adapter> rev 0x03 int a irq 11 on pci2.6.0 > > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > > > The backplane is reported as having only 3.3 MB transfer rate : > > > > pass2 at ahc0 bus 0 target 6 lun 0 > > pass2: <DELL 1x6 U2W SCSI BP 5.12> Fixed Processor SCSI-2 device > > pass2: 3.300MB/s transfers > > > > Did anyone experience the same problem ? > > Can someone help me ? > > Any hints ? > > Any configurarion at the CAM level ? - I configured the kernel > > to debug CAM but I can only reboot the machine in a few > > hours... > > Other folks already explained the 3.3MB/sec transfers on your backplane > device, so i won't repeat what they said. > > > PS: the disks are also reporter correctly : > > > > da1 at ahc0 bus 0 target 1 lun 0 > > da1: <WDIGTL WDE9180 ULTRA2 1.20> Fixed Direct Access SCSI-2 device > > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > > > da0 at ahc0 bus 0 target 0 lun 0 > > da0: <WDIGTL WDE9180 ULTRA2 1.20> Fixed Direct Access SCSI-2 device > > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > Western Digital drives generally aren't that great. In fact, we have > disabled tagged queueing for most all Western Digital SCSI drives. > (including the drives you have, above) > > [ ... ] > > > Dell PowerEdge 4300 > > (http://www.dell.com/products/poweredge/pe4300/index.htm) > > > > time dd bs=1000000 count=100 if=/dev/zero of=t > > 100+0 records in > > 100+0 records out > > 100000000 bytes transferred in 53.853144 secs (1856902 bytes/sec) > > Okay, there are several things to try here: > > - first, enable write caching on this drive if it isn't already turned on. > > camcontrol modepage da0 -m 8 -P 3 -e > > Then change the 'WCE' bit from 0 to 1. Do the same thing for da1. That did it! Changing the WCE bit made all the difference in writing operations. Now I can get about 17 MB/sec transfers: time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out 100000000 bytes transferred in 5.878631 secs (17010763 bytes/sec) real 0m5.940s user 0m0.999s sys 0m1.570s Is there any way to make these settings permanent ? > > - if your performance doesn't improve after that, try re-enabling tagged > queueing. Try the attached patch for src/sys/cam/cam_xpt.c. It is > against -current, but I think it'll apply to 3.2. If not, you can > probably see what you need to comment out. The patch seems to apply: patch < cam_xpt.c.wde_tag.101499 Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |==== //depot/FreeBSD-ken/src/sys/cam/cam_xpt.c#2 - /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c ==== |*** /tmp/tmp.46108.0 Thu Oct 14 16:54:28 1999 |--- /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c Thu Oct 14 16:52:13 1999 -------------------------- Patching file cam_xpt.c using Plan A... Hunk #1 succeeded at 380 (offset 20 lines). Hunk #2 succeeded at 392 (offset 20 lines). done And the kernel compiles, so I'll try it during the weekend (It's a production machine) - I'll let you know. > > Hopefully, one of those two things will fix your performance. I'd like to > hear what happens. > > Ken > -- > Kenneth Merry > ken@kdm.org > Thank you all, specially to Kenneth Merry. I already spend a few days digging around, opening the machine, calling up suppliers, etc, etc. And nothing worked, except that last bit change... Tkns, Joao Pagaime 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.BSF.4.10.9910151111200.15842-100000>