Date: Mon, 12 Apr 1999 10:05:10 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: gallatin@cs.duke.edu (Andrew Gallatin) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: odd performance 'bug' & other questions Message-ID: <199904121605.KAA05320@panzer.plutotech.com> In-Reply-To: <14097.62839.525472.52389@grasshopper.cs.duke.edu> from Andrew Gallatin at "Apr 12, 1999 9:46: 4 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote... > > Kenneth D. Merry writes: > > > > There are a couple of things going on here that may affect the performance > > numbers you're seeing: > > > > - There was a performance problem in getnewbuf() that was supposedly fixed > > on April 6th. I haven't tested -current since then, so I don't know for > > sure whether the problem is really fixed. > > I know about this, so I am using dd rather than Bonnie / iozone in > order to factor this out. It sure would be nice if Matt's fix > surfaced though ;-) Well, Alan Cox checked in a performance fix for getnewbuf() on April 6th, but like I said, I don't know if the problem has really been fixed since I haven't tested -current since then. > > - The Medalist Pro drives are known to be rather crappy. That's why we've > > got the number of tags set to 2 in the quirk entry for those drives. > > Crap, crap, crap. We just bought 84 of these; I wish I could have > talked my boss into the barracudas.. Yeah, buying crappy disks will often give you headaches. :) I don't think they're too bad for sequential throughput -- 13.5MB/sec isn't bad. But the whole reason you're getting that much performance is because we cranked the number of tags down to 2. It might be worthwhile in the future to buy one or two of the disks you're planning to get a lot of, and then do extensive benchmarks on them. Or at least look in the quirk table or ask around about 'em. :) [ ... ] > > And it has 660 defects in the permanant list, none in the grown defect > > list. It is a 9G drive, and still gives pretty good performance. > > (14-16MB/sec) So your numbers are a bit high for a 9G drive, but I'm not > > sure whether that would be considered excessive. Of course the drives I've > > got above are higher-end Seagate and IBM disks, not low-end models. And > > you'd expect the number of defects to be somewhat proportional to the > > capacity of the drive. Your numbers are closer to the 18G IBM disk above. > > OK.. so they're a bit bad, but not necessarily unusual. I haven't paid much > attention to defect lists since a 1GB disk was considered large, so I guess I was > just a bit surprised to see the size. Yeah, I don't think your trouble is the defect list. You'd be seeing bad performance from single disks if that were the case. I suspect a VM-type problem, although I'm not certain about that. It would be interesting to see if you get the same performance problems under -stable. (FWIW, the CAM code is the same in -stable and -current.) > > > Also, the ncr controller fails to give me a defects list, I assume > > > this is a bug in the driver? (I'm running -current, dated this Thurs). > > > camcontrol complains: error reading defect list: Input/output error, > > > and I see this on console: > > > > > > (pass3:ncr0:0:0:0): extraneous data discarded. > > > (pass3:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc39a3600. > > > > It could be a driver bug, not sure. What arguments were you using with > > camcontrol? > > camcontrol defects -n da -u 3 -f phys -P > > When the unit is one of the drives attached to the on-board adaptec > controller, it works as expected. However, if the unit is a drive > attached to the ncr crontoller, the command fails as mentioned above. > The drives are identical, so that's why I'm assuming there's an ncr bug. Okay, sounds like that may be the case. If I get some time I'll stick an NCR board in my test box and see whether I can read a defect list. Ken -- Kenneth Merry ken@plutotech.com 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?199904121605.KAA05320>