Messages in this thread |  | | From | Nathan Black <> | Subject | RE: No SCSI Ultra 160 with Adaptec Controller | Date | Wed, 24 Jan 2001 15:13:26 -0500 |
| |
What problem are you trying to solve, I just joined the group in hopes of finding a solution to a problem of mine.
It sounds like they may be related. I am trying to write to a drive(raw, blank, whatever you want to call it) on kernel 2.4.1-pre10. I get great throughput at first, but then it slows to about 25 MB/sec. This isn't a problem except after writing a large amount of data, the system becomes unusable. I did not say it halts, oops, or anything like that, just extremely slow. ps takes about 10 minutes or more to complete.(4 tasks).
I have a compaq smart array controller 2.
Before I upgraded the kernel( I was at 2.4.0 released). I would get an oops. and a kernel panic/halt. I did see that running in uniprocessor mode with NMIs turned off would let me write without problems, but I was never sure how to fix it.
Any ideas?
-----Original Message----- From: Tom Sightler [mailto:ttsig@tuxyturvy.com] Sent: Wednesday, January 24, 2001 3:08 PM To: mjacob@feral.com; Matt_Domsch@dell.com Cc: linux-kernel@vger.kernel.org Subject: Re: No SCSI Ultra 160 with Adaptec Controller
> Actually, aren't a number of newer drives getting upwards of 30MB/s? >
Well, at 80MB/sec these drives are able to come in at an average of about 34MB/s across the board.
> > Therefore, you only exceed the 80MB/sec bus speed if you > > have more than 4 disks all doing maximum I/O at the same time. Since the > > PowerApp.web 100 has at most 2 disks internally, you really shouldn't see > > any significant performance difference.
I wouldn't dare argue that I'd get some huge performance boost, but I am running software raid1 on multiple spindles (we have some drives attached externally) so it should help some. Also, this unit is doing heavy read/write of small files and the lower latency, and burstable transfers do help some. I temporarily disabled that code and the increase in IO's per second is measurable, though not earth shattering, but I was afraid to leave it that way because fast corrupted data is worth much less that only slightly slower good data.
It was really just an issue of if the code still needed to be there. Workarounds that are put in as temporary have a tendency to never get revisited until someone brings them up, and on top of that they make Linux look sloppy to me (the same drives work correctly at Ultra160 under that other OS, or at least appear to). I know it won't make a huge difference to me, but if some user has a 12 disk RAID array full of Quantum disks it will make a big difference to them.
Later, Tom
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |