Fluffles wrote: > single drive (ad6, Maxtor MaxLine III 250GB SATA/150) > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 20480 56395 42.7 55904 12.8 21497 5.9 56846 54.3 58328 8.2 > 81.2 0.3 > > Here the CPU is not the bottleneck but the disk itself. CPU is AMD > Athlon 64 3800+ (dualcore, 2.0GHz, 2x512KB cache, S939, 2x1GB DDR/400). > Maybe you are running a patched bonnie? By the way i'm not using > bonnie++ but the 'original' bonnie. Maybe that changes things a bit?
Yup, that the thing. The difference is that bonnie++ goes to the kernel for every character read or written (in the per-char benchmark) while the old bonnie allows for buffering in libc. At least that's the theory. While on FreeBSD bonnie++ can get around 500 KB/s on per-chr benchmark, on Linux it can get upto 20 MB/s: http://fsbench.netnation.com/new_hardware/2.6.0-test9/scsi/bonnie.html >> Fromall the benchmarks i've seen and all that i've performed myself, > i've never seen that low per char scores like you. I cannot explain it > except maybe a *very* slow CPU or some other obscure software issue. Any post-Pentium 1 CPU should be fast enough to saturate disk IO in DMA mode. The question if kernel latency is a different issue :) Here are my "bonnie" results on the same machine (gmirror "split" balance, 2xSATA 7.5kRPM, more than fast enough Xeon CPU): -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4096 56456 53.2 55344 13.4 19436 6.5 60606 46.3 61417 10.4 203.0 0.8
signature.asc
Description: OpenPGP digital signature
