Date: Mon, 15 Feb 1999 10:32:33 +0100 From: ANDREAS.KLEMM.AK@bayer-ag.de To: " - (052)mjacob(a)feral.com" <mjacob@feral.com> Cc: " - (052)scsi(a)FreeBSD.ORG" <scsi@FreeBSD.ORG> Subject: Antwort: Re: It%s not the write cache on 3.0-STABLE and not Message-ID: <0006800008749198000002L082*@MHS>
next in thread | raw e-mail | index | archive | help
Hi ! Well, but why especially with this kind of hardware / harddisk ??? I doesn*%t have any problems with my machine at home and get with 5200 U/min narrow SCSI harddisks (IBM DORS 32160) more write throughput, than with this ultra scsi device. And what is astonishing: in 2.2.7 you can solve the problem by disabling tagged queuing ! When I disabled tagged queuing in 3.0-STABLE, it still had this write performance / slowness on console problem. Well, I*%d loved to investigate this problem further, but the timescale to install the system is over and I had to install 2.2.7 :-/ Is there perhaps somebody other with this Seagate drive for further testing ??? It looks for me like a race condition in our SCSI driver in combination with that special firmware. Have no other idea what could cause this ... Especially because only 2.2.7 without tagged solves the problem.... But not CAM without tagged. BTW, when I reduce the min/max number of tags for that drive under 3.0-STABLE (from 990210) min = 8, max=16, I got SCSI Errors on the console. I think it were aborted SCB*%s or such ... Well then I had to give up and install 2.2.7 .... Andreas /// mjacob@feral.com on 14.02.99 19:25:45 Bitte antworten an mjacob@feral.com @ INTERNET An: andreas@klemm.gtn.com @ INTERNET Kopie: scsi@FreeBSD.ORG @ INTERNET, Andreas Klemm@BAYERNOTES, ken@plutotech.com @ INTERNET Thema: Re: It%s not the write cache on 3.0-STABLE and not tagged co > But if write performance is poor, but actually doesn't eat up > that much CPU performance. Why is the FreeBSD machine so much > "in-responsive". It means I merely can login on a second console, > I have to wait 10-15 seconds for a login. And the execution of > commands lags lags lags. This kind of blockage is often a VM/Buffer Cache type of issue- the same problem applies in Linux. If you don't put some hysteresis into you're bdelwri queue, you end up swamping the system writing out to one spindle. This whole area of system performance, including whether or not using the maximum number of tags you can, needs to be really thought through and *metrics* used to prove or disprove cases. -matt 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?0006800008749198000002L082*>