lkml.org 
[lkml]   [1998]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SMP 2.1.131: SCSI performance extremely poor vs. IDE
Gerard Roudier wrote:

> > Those particular numbers all look to be from fairly dated hardware.
> > With somewhat modern hardware (5 Seagate Cheetah Ultra2 drives on two
> > Ultra2 channels on one 3950U2b Adaptec controller all in a RAID0 array
> > in a PII 266 box with 128MB RAM) I'm seeing numbers like these:
> >
> > 2.0.36UP:
> > -------Sequential Output-------- ---Sequential Input-- --Random--
> > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> > 512 12020 98.2 65325 89.0 14788 50.0 14585 94.2 65283 86.7 255.1 5.5
> > 512 12018 98.2 64312 87.8 14975 49.8 14707 95.3 65065 85.4 251.4 5.2
> > 512 12041 98.2 66525 91.7 15027 50.2 14801 95.6 63949 86.2 258.8 5.6
>
> Unfortunately I am not able to run such benchmarks since my penis is not
> as long as 5 Cheetah2, but just as one of such beast, but I can comment.

Interesting imagery Gerard....

> 5 Cheetah2 -> something like 18x5 = 90 MB/sec sustaint in the 1rst 512 MB
> of each. If I assume your RAID0 has been optimized and that you are using
> a not patched kernel, block read number shows the following:

The partitions in use in this particular RAID0 array are actually about
3/4 of the way through the disks. I have my RAID5 array (my primary
array) in the first 3/4 of each disk. The kernel is patched with my
latest code and with Ingo Molnar's latest raid code, otherwise it's
stock 2.0.36. The array itself was a 5 disk stripe using 64k chunk
sizes and a 4k ext2fs that was built as "mke2fs -b 4096 -i 16384 -R
stride=80 /dev/md1".

> IO/sec -> 65000*5/76=4300 IOs/sec of 15K chunk in average.
>
> I am not way impressed by these numbers when using 2 LVD SCSI channels.
> You probably stressed the memory, but probably not the SCSI BUS and your 2
> LVD SCSI channels with your benchmark.

I'm quite aware of that. I'm actually acutely aware of the fact that
these disks and SCSI channels can outrun my puny PII 266 system. I'm
not I/O bound here, I'm CPU bound. I would have posted a different
machine's results that I have that are 4 cheetahs on one LVD channel but
I don't have the numbers any more (I quoted them to Alan Cox on irc but
didn't bother to save them, they showed that the block numbers were in
the same range as what I posted with sequential I/O out going at about
66MB/s and in going at about 60MB/s on a 1gig file size in a PII400 with
512MB RAM, however the per/char I/O speeds on that machine sucked rocks,
which is related to the 512MB RAM I believe and which I intend to do
tests to verify this week).

> I am a lot more interested in results using 3 or 4 Cheetah2 on 1 SCSI
> channel for sustaint data rate and in the actual latency of SCSI commands
> for short IOs using these 2, 3 or 4 Cheatah2 at a time on a single SCSI
> channel.

4 disks, 1 channel, roughly the same numbers on block I/O as I mentioned
above.

> > The numbers I have for 2.1.131 so far are all SMP numbers and so can't
> > be compared against the 2.0.36 numbers. I plan on getting some UP
> > numbers for 2.1.131 as well before too long.
>
> If you intend to measure some kernel difference in handling IOs, then
> such results may make sense, but they are not relevant with regards to
> the ability of your SCSI controllers to perform IOs, in my opinion.

Which was exactly my point, to measure the differences in the 2.0 vs.
2.1 kernels in terms of how they handle block output and input to the
page cache and buffer cache.

> Bonnie is a great liar, and we must be very careful when posting
> Bonnie benchmarks. Indeed, your post has been sent to the kernel list,
> so you are not off-topic. This would be different if you posted it to
> the scsi list.
>
> Regards,
> Gerard.

--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.103 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site