TIOBENCH
No size specified, using 1792 MB
Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 1792 4096 1 153.6 98.1% 0.897 0.91% 85.59 51.2% 3.399 1.95%
. 1792 4096 2 104.7 67.8% 1.080 1.00% 79.63 58.4% 3.437 3.29%
. 1792 4096 4 91.57 61.2% 1.292 1.24% 76.45 59.3% 3.471 3.40%
. 1792 4096 8 83.55 57.3% 1.480 1.39% 73.80 59.2% 3.455 3.26%
File './Bonnie.1089', size: 1073741824, volumes: 1
Writing with putc()... done: 9854 kB/s 100.0 %CPU
Rewriting... done: 65537 kB/s 52.2 %CPU
Writing intelligently...done: 109124 kB/s 51.0 %CPU
Reading with getc()... done: 9821 kB/s 99.9 %CPU
Reading intelligently...done: 167240 kB/s 97.6 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1*1024 9854 100.0 109124 51.0 65537 52.2 9821 99.9 167240 97.6 1504.4
6.4
hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 64 MB in 0.47 seconds =136.17 MB/sec
hde: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
hdg: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
hdi: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
hdk: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
/etc/raidtab
raiddev /dev/md0
raid-level 0
nr-raid-disks 4
persistent-superblock 0
chunk-size <snipped>
device /dev/hd<snipped>1
raid-disk 0
device /dev/hd<snipped>1
raid-disk 1
device /dev/hd<snipped>1
raid-disk 2
device /dev/hd<snipped>1
raid-disk 3
If you want your system to have this kind of performance, that raise hell
to get the patches adopted into the main kernel.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
Andre Hedrick wrote:
> If you want your system to have this kind of performance, that raise hell
> to get the patches adopted into the main kernel.
May I ask what patch you are talking about?
--
MfG / Regards
Friedrich Lobenstock
On Mon, 2001-12-31 at 06:05, Andre Hedrick wrote:
<snip>
> If you want your system to have this kind of performance, that raise hell
> to get the patches adopted into the main kernel.
Have you asked Linus and Marcelo why your patches aren't being
accepted? Linus and Hans Reiser eventually sorted out what
was required for getting reiserfs into the kernel, though it
took some negotiation and compromise of the part of the reiserfs
folks. I imagine you can do the same.
It's a no-brainer that we all want fast disk I/O.
Miles
On Mon, 31 Dec 2001 06:05:57 -0800 (PST)
Andre Hedrick <[email protected]> wrote:
> If you want your system to have this kind of performance, that raise hell
> to get the patches adopted into the main kernel.
Andre, please give us some URL for the patch(es), so we all can try it
ourselves, every person with a successful try will probably be one of your
supporters. Is this applyable to 2.4?
Regards,
Stephan
On Monday, 31 December 2001, at 18:11:04 +0100,
Stephan von Krawczynski wrote:
> Andre, please give us some URL for the patch(es), so we all can try it
> ourselves, every person with a successful try will probably be one of your
> supporters. Is this applyable to 2.4?
>
Maybe this is what Andre is talking about:
http://www.linuxdiskcert.org
Applies cleanly to 2.4.17, by the way.
--
Jos? Luis Domingo L?pez
Linux Registered User #189436 Debian Linux Woody (P166 64 MB RAM)
jdomingo AT internautas DOT org => Spam at your own risk
On Mon, Dec 31, 2001 at 06:05:57AM -0800, Andre Hedrick wrote:
> Writing intelligently...done: 109124 kB/s 51.0 %CPU
> Reading intelligently...done: 167240 kB/s 97.6 %CPU
> If you want your system to have this kind of performance, that raise hell
> to get the patches adopted into the main kernel.
Very nice ... but impossible? I don't think so. I'd be quite interested
in hearing what problem 2.4 has that it doesn't reach the same
performance as you have shown, though. Or does it?
--
Vojtech Pavlik
SuSE Labs
Jos? Luis Domingo L?pez wrote:
>On Monday, 31 December 2001, at 18:11:04 +0100,
>Stephan von Krawczynski wrote:
>
>>Andre, please give us some URL for the patch(es), so we all can try it
>>ourselves, every person with a successful try will probably be one of your
>>supporters. Is this applyable to 2.4?
>>
>Maybe this is what Andre is talking about:
>http://www.linuxdiskcert.org
>
What the hell are taskfiles???!!!!
On Mon, 31 Dec 2001 20:08:45 +0100
Jos? Luis Domingo L?pez <[email protected]> wrote:
> On Monday, 31 December 2001, at 18:11:04 +0100,
> Stephan von Krawczynski wrote:
>
> > Andre, please give us some URL for the patch(es), so we all can try it
> > ourselves, every person with a successful try will probably be one of your
> > supporters. Is this applyable to 2.4?
> >
> Maybe this is what Andre is talking about:
> http://www.linuxdiskcert.org
>
> Applies cleanly to 2.4.17, by the way.
I tried on top of 2.4.17 on a pretty standard IDE setup (IBM 20 G, ATA 66, VIA
chipset) and have no measureable performance difference. But I guess it
couldn't have been expected in such an environment. Would be interesting to
hear tests from more complex setups.
Regards,
Stephan
Hi!
> TIOBENCH
>
> No size specified, using 1792 MB
> Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec
>
> File Block Num Seq Read Rand Read Seq Write Rand Write
> Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> ------- ------ ------- --- ----------- ----------- ----------- -----------
> . 1792 4096 1 153.6 98.1% 0.897 0.91% 85.59 51.2% 3.399 1.95%
> . 1792 4096 2 104.7 67.8% 1.080 1.00% 79.63 58.4% 3.437 3.29%
> . 1792 4096 4 91.57 61.2% 1.292 1.24% 76.45 59.3% 3.471 3.40%
> . 1792 4096 8 83.55 57.3% 1.480 1.39% 73.80 59.2% 3.455 3.26%
>
>
> File './Bonnie.1089', size: 1073741824, volumes: 1
> Writing with putc()... done: 9854 kB/s 100.0 %CPU
> Rewriting... done: 65537 kB/s 52.2 %CPU
> Writing intelligently...done: 109124 kB/s 51.0 %CPU
> Reading with getc()... done: 9821 kB/s 99.9 %CPU
> Reading intelligently...done: 167240 kB/s 97.6 %CPU
> Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
> ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 1*1024 9854 100.0 109124 51.0 65537 52.2 9821 99.9 167240 97.6 1504.4
> 6.4
>
> hdparm -t /dev/md0
>
> /dev/md0:
> Timing buffered disk reads: 64 MB in 0.47 seconds =136.17 MB/sec
>
>
> hde: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
> hdg: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
> hdi: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
> hdk: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
>
> /etc/raidtab
>
> raiddev /dev/md0
> raid-level 0
> nr-raid-disks 4
> persistent-superblock 0
> chunk-size <snipped>
>
> device /dev/hd<snipped>1
> raid-disk 0
> device /dev/hd<snipped>1
> raid-disk 1
> device /dev/hd<snipped>1
> raid-disk 2
> device /dev/hd<snipped>1
> raid-disk 3
>
>
> If you want your system to have this kind of performance, that raise hell
> to get the patches adopted into the main kernel.
Raising hell is usually bad idea. What is so cool about that? You used
raid0, that means individual disk has 35MB/sec. That does not seem too
interesting to me.
And... you can have as fast system as you want. That will not help
your patches...
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Miles Lane wrote:
>On Mon, 2001-12-31 at 06:05, Andre Hedrick wrote:
>
><snip>
>
>>If you want your system to have this kind of performance, that raise hell
>>to get the patches adopted into the main kernel.
>>
>
>Have you asked Linus and Marcelo why your patches aren't being
>accepted? Linus and Hans Reiser eventually sorted out what
>was required for getting reiserfs into the kernel, though it
>took some negotiation and compromise of the part of the reiserfs
>folks. I imagine you can do the same.
>
Um, actually I don't remember anything Linus asked for from us, probably
he did, but if I can't remember it then it probably was not significant
(oh wait, he asked for terseness in the licensing statements at the top
of every file. Surely he asked for something else also, but it was
trivial.)
That said, Andre, if you want more testers we can put a link to your
code on our download page, and if you want someone to read your code and
tell you what parts aren't easy to understand (I haven't read your new
code yet), we'll help with that also.
>
>
>It's a no-brainer that we all want fast disk I/O.
>
>
>
That's for sure.