Re: Some Unix benchmarks for those who are interesed
On Mar 8, 2007, at 9:24 PM, Eric Anderson wrote: [ ... ] Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. A quick sample from http://www.nycbug.org/?NAV=dmesgd;f_bsd=FreeBSD suggests: CPU: VIA C3 Samuel 2 (601.37-MHz 686-class CPU) Origin = CentaurHauls Id = 0x673 Stepping = 3 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = GenuineIntel Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX CPU: Pentium II/Pentium II Xeon/Celeron (397.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR CPU: VIA C3 Nehemiah+RNG (1000.35-MHz 686-class CPU) Origin = CentaurHauls Id = 0x693 Stepping = 3 Features=0x380b33dFPU,DE,PSE,TSC,MSR,CX8,APIC,MTRR,PGE,CMOV,MMX,FXSR,SS E CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1403.27-MHz 686- class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On 03/09/07 12:55, Chuck Swiger wrote: On Mar 8, 2007, at 9:24 PM, Eric Anderson wrote: [ ... ] Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. I'm pretty familiar with C3 and C7 chips. I wouldn't compare performance of a CPU based on CPU features. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On Mar 9, 2007, at 11:34 AM, Eric Anderson wrote: I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. I'm pretty familiar with C3 and C7 chips. I wouldn't compare performance of a CPU based on CPU features. Of course not-- but then, I said capabilities, not performance. If you'd like to compare performance, choose a task or benchmark which matters to you, and go from there. The comparisons I have done suggests a 200MHz PPro will do a make buildworld faster than a 600MHz C3 Samuel, for example. YMMV, and I'd rather not debate this matter further if you feel strongly about it... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Fluffles wrote: Ivan Voras wrote: Fluffles wrote: If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 I'd agree in theory, but bonnie++ gives WORSE results than raw device: On what hardware is this? Using any form of geom software RAID? Xeon 5110, 1.6 GHz, see benchmark results on stable mailing list (It's a pretty fast dual-core CPU, core2-based). It's using geom_mirror and the results are with split read algorithm. The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since Maybe on Linux, definitely not on FreeBSD. I've never seen per-char bonnie++ results on FreeBSD that give more than 1 MB/s. And before anyone starts debugging my setup, I'm not the only one with such results :) I recall there were reports before which show geom_mirror doesn't achieve better performance with split reads. signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Fluffles wrote: gstripe (4 disks on nVidia controller [Embedded], 128KB stripesize, Test System 1) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- DD benchmark(1GB) Results in MB/s avg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4k READ47.146.946.846.9 WRITE 40.940.941.040.9 16k READ92.792.892.692.7 WRITE 76.376.176.276.2 64k READ120.8 120.6 120.6 120.6 WRITE 96.196.296.196.1 128kREAD123.0 122.8 122.8 122.8 WRITE 96.396.496.296.3 1m READ122.7 122.9 122.6 122.7 WRITE 89.489.489.489.4 So, writing to a striped set is 37% faster than reading... geom_raid5 with 8 SATA disks (128KB stripe, graid5-tng, Test System 2) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- DD benchmark(1GB) Results in MB/s avg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4k READ58.158.759.058.6 WRITE 155.5 155.8 154.3 155.2 16k READ130.0 125.6 129.5 128.3 WRITE 308.5 306.3 306.9 307.2 64k READ183.8 183.9 188.9 185.5 WRITE 416.9 416.7 415.8 416.4 128kREAD197.3 194.4 197.6 196.4 WRITE 421.0 426.2 399.7 415.6 1m READ193.0 196.8 198.1 195.9 WRITE 327.6 330.3 331.0 329.6 Similar here: 69% faster, even though writing to RAID5 involves block ECC (XOR probably) calculations and writing to at least two disks, and reading doesn't. Interesting. Any ideas why? (anybody?) signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Eric Anderson wrote: On 03/07/07 23:13, Fluffles wrote: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Before making speculative claims about slow CPU's and putting the VIA C3 in with that pile, please at least refer to what makes you believe that it is an issue. Comparing the VIA C3 to 'some old pentium' isn't exactly fair or accurate, and inferring it isn't a modern system isn't true either. I'm sorry if i offended you. But it is well-known that C3 Nehemiah has a much lower IPC than processors from AMD and Intel. For general purpose comparisons, i would guess a 400MHz Athlon 64 to outperform the 1GHz C3 Nehemiah; just guessing here! Not to talk about Core2Duo who has even higher IPC. Though Nehemiah does have some fancy MPEG/AES hardware acceleration stuff built-in, which makes it a suitable platform for a Media Center or anything like that. Personally i think a budget AMD processor to be a better option; they have the same power consumption under standby mode (thanks to Cool'N'Quiet) but can deliver much higher performance when needed (such as HighDef 1080p video?). The bonnie Per Char-benchmark is often bottlenecked by the CPU since it requires either a lot of cpu power or a lot of memory activity; both which puts demands on the cpu. If i see only 0.5MB in the Per Char-benchmark, i would suspect a slow CPU. Slow is a relative term though; C3 can be powerful enough for the task you bought it, so i don't want to discredit it. - Veronica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Fluffles wrote: The bonnie Per Char-benchmark is often bottlenecked by the CPU since it requires either a lot of cpu power or a lot of memory activity; both which puts demands on the cpu. If i see only 0.5MB in the Per Char-benchmark, i would suspect a slow CPU. Slow is a relative term though; C3 can be powerful enough for the task you bought it, so i don't want to discredit it. I'm really puzzled by your high per-char results in bonnie++. Can you run it on a single disk? I've run it many times, both on hardware and software RAIDs and have never seen results 1 MB/s on FreeBSD (Linux is a different matter...) signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Ivan Voras wrote: Fluffles wrote: The bonnie Per Char-benchmark is often bottlenecked by the CPU since it requires either a lot of cpu power or a lot of memory activity; both which puts demands on the cpu. If i see only 0.5MB in the Per Char-benchmark, i would suspect a slow CPU. Slow is a relative term though; C3 can be powerful enough for the task you bought it, so i don't want to discredit it. I'm really puzzled by your high per-char results in bonnie++. Can you run it on a single disk? I've run it many times, both on hardware and software RAIDs and have never seen results 1 MB/s on FreeBSD (Linux is a different matter...) Sure: single drive (ad6, Maxtor MaxLine III 250GB SATA/150) ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB 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? From all 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. - Veronica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Fluffles wrote: single drive (ad6, Maxtor MaxLine III 250GB SATA/150) ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB 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--- MachineMB 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
Re: Some Unix benchmarks for those who are interesed
On 03/08/07 09:58, Fluffles wrote: Eric Anderson wrote: On 03/07/07 23:13, Fluffles wrote: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Before making speculative claims about slow CPU's and putting the VIA C3 in with that pile, please at least refer to what makes you believe that it is an issue. Comparing the VIA C3 to 'some old pentium' isn't exactly fair or accurate, and inferring it isn't a modern system isn't true either. I'm sorry if i offended you. But it is well-known that C3 Nehemiah has a much lower IPC than processors from AMD and Intel. For general purpose comparisons, i would guess a 400MHz Athlon 64 to outperform the 1GHz C3 Nehemiah; just guessing here! Not to talk about Core2Duo who has even higher IPC. No offense, I just prefer the fud to be kept off lists - it's essentially trolling I suppose. No doubt the C3 and C7 processors are slower than the top of the line Intel and AMD's - that's like comparing a Prius with a Porsche. If you can find a 400MHz Athlon 64, I'd enjoy seeing the benchmarks. :) However, just simple benchmarks for IPC don't tell much about a processor. Though Nehemiah does have some fancy MPEG/AES hardware acceleration stuff built-in, which makes it a suitable platform for a Media Center or anything like that. Personally i think a budget AMD processor to be a better option; they have the same power consumption under standby mode (thanks to Cool'N'Quiet) but can deliver much higher performance when needed (such as HighDef 1080p video?). Well, not actually the same power consumption at all. Again, do a little googling here, and you might find some actual numbers (not just reported numbers). The bonnie Per Char-benchmark is often bottlenecked by the CPU since it requires either a lot of cpu power or a lot of memory activity; both which puts demands on the cpu. If i see only 0.5MB in the Per Char-benchmark, i would suspect a slow CPU. Slow is a relative term though; C3 can be powerful enough for the task you bought it, so i don't want to discredit it. Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On Tue, 06 Mar 2007 23:19:12 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Artem Kuchin wrote: See here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033494.html Yes, that what i've got in the list and this how it was in the putty terminal originally. Nothing is missing. I don't know why open left parentesis are there. The block under the header: INDEX VALUES TESTBASELINE is important - it summarises the results and your post is missing the summaries :) Yep. It should look something like this output, from my dual-core Opteron running Linux 2.6.19-ck2: BYTE UNIX Benchmarks (Version 4.1-wht.1) System -- Linux daydream 2.6.19-ck2 #5 SMP PREEMPT Sat Jan 20 12:23:54 EST 2007 i686 athlon-4 i386 GNU/Linux /dev/mapper/vg-u2 10321208 6610764 3710444 65% /u2 Start Benchmark Run: Wed Mar 7 01:34:36 EST 2007 01:34:36 up 53 min, 3 users, load average: 0.24, 0.18, 0.14 End Benchmark Run: Wed Mar 7 01:45:33 EST 2007 01:45:33 up 1:04, 3 users, load average: 12.80, 5.64, 2.63 INDEX VALUES TESTBASELINE RESULT INDEX Dhrystone 2 using register variables376783.7 15270277.2 405.3 Double-Precision Whetstone 83.1 2674.2 321.8 Execl Throughput 188.3 5084.7 270.0 File Copy 1024 bufsize 2000 maxblocks 2672.096128.0 359.8 File Copy 256 bufsize 500 maxblocks 1077.027395.0 254.4 File Read 4096 bufsize 8000 maxblocks15382.0 690188.0 448.7 Pipe Throughput 111814.6 827153.0 74.0 Pipe-based Context Switching 15448.6 352671.5 228.3 Process Creation 569.316337.0 287.0 Shell Scripts (8 concurrent)44.8 849.9 189.7 System Call Overhead114433.5 2451595.0 214.2 = FINAL SCORE 254.1 -- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Charles Shannon Hendrix wrote: BYTE UNIX Benchmarks (Version 4.1-wht.1) Off-topic: Who or what is the origin of the wht version? One of the nice things about unixbench is that it hadn't changed from 1997, but now most Linux variants use the -wht version that has completely different baselines and results from the normal version? signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
On Wed, 07 Mar 2007 17:11:24 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: BYTE UNIX Benchmarks (Version 4.1-wht.1) Off-topic: Who or what is the origin of the wht version? One of the nice things about unixbench is that it hadn't changed from 1997, but now most Linux variants use the -wht version that has completely different baselines and results from the normal version? It's a version created for the website: webhostingtalk.com. It was created to have a stable and standard benchmark. -- shannon / There is a limit to how stupid people really are, just as there's ---' a limit to the amount of hydrogen in the Universe. There's a lot, but there's a limit. -- Dave C. Barber on a.f.c. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Charles Shannon Hendrix wrote: On Wed, 07 Mar 2007 17:11:24 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: BYTE UNIX Benchmarks (Version 4.1-wht.1) Off-topic: Who or what is the origin of the wht version? One of the nice things about unixbench is that it hadn't changed from 1997, but now most Linux variants use the -wht version that has completely different baselines and results from the normal version? It's a version created for the website: webhostingtalk.com. It was created to have a stable and standard benchmark. Beautiful - they fiddled with the baselines but still managed not to see the obvious problem in execl() call in the execl benchmark for 64-bit platforms. signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Yep. It should look something like this output, from my dual-core Opteron running Linux 2.6.19-ck2: BYTE UNIX Benchmarks (Version 4.1-wht.1) System -- Linux daydream 2.6.19-ck2 #5 SMP PREEMPT Sat Jan 20 12:23:54 EST 2007 i686 athlon-4 i386 GNU/Linux /dev/mapper/vg-u2 10321208 6610764 3710444 65% /u2 Start Benchmark Run: Wed Mar 7 01:34:36 EST 2007 01:34:36 up 53 min, 3 users, load average: 0.24, 0.18, 0.14 End Benchmark Run: Wed Mar 7 01:45:33 EST 2007 01:45:33 up 1:04, 3 users, load average: 12.80, 5.64, 2.63 = FINAL SCORE 254.1 Here is mine retested and patched to work on AMD64 (Pentium D 3.4Ghz) BYTE UNIX Benchmarks (Version 4.1.0) System -- aaa.itlegion.ru Start Benchmark Run: Wed Mar 7 14:03:27 MSK 2007 1 interactive users. 2:03PM up 6 mins, 1 user, load averages: 0.00, 0.09, 0.06 -r-xr-xr-x 1 root wheel 131328 Mar 5 23:55 /bin/sh /bin/sh: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped /dev/ar0s1e 289385582 2746558 263488178 1%/usr Dhrystone 2 using register variables 10486183.3 lps (10.1 secs, 10 samples) Double-Precision Whetstone 1289.1 MWIPS (10.7 secs, 10 samples) System Call Overhead 494962.3 lps (10.1 secs, 10 samples) Pipe Throughput 603048.3 lps (10.1 secs, 10 samples) Pipe-based Context Switching 34302.9 lps (12.8 secs, 10 samples) Process Creation 3011.8 lps (38.6 secs, 3 samples) Execl Throughput 1229.4 lps (30.0 secs, 3 samples) File Read 1024 bufsize 2000 maxblocks467804.0 KBps (30.0 secs, 3 samples) File Write 1024 bufsize 2000 maxblocks 109705.0 KBps (30.0 secs, 3 samples) File Copy 1024 bufsize 2000 maxblocks109313.0 KBps (30.0 secs, 3 samples) File Read 256 bufsize 500 maxblocks 126505.0 KBps (30.0 secs, 3 samples) File Write 256 bufsize 500 maxblocks 86216.0 KBps (30.0 secs, 3 samples) File Copy 256 bufsize 500 maxblocks 50229.0 KBps (30.0 secs, 3 samples) File Read 4096 bufsize 8000 maxblocks1399150.0 KBps (30.0 secs, 3 samples) File Write 4096 bufsize 8000 maxblocks67555.0 KBps (30.0 secs, 3 samples) File Copy 4096 bufsize 8000 maxblocks 64288.0 KBps (30.0 secs, 3 samples) Shell Scripts (1 concurrent) 3222.7 lpm (62.7 secs, 3 samples) Shell Scripts (8 concurrent)579.8 lpm (60.2 secs, 3 samples) Shell Scripts (16 concurrent) 293.5 lpm (60.1 secs, 3 samples) Arithmetic Test (type = short) 891421.9 lps (10.1 secs, 3 samples) Arithmetic Test (type = int) 951512.1 lps (10.1 secs, 3 samples) Arithmetic Test (type = long)298204.3 lps (10.2 secs, 3 samples) Arithmetic Test (type = float) 1033235.9 lps (10.1 secs, 3 samples) Arithmetic Test (type = double) 516114.2 lps (10.1 secs, 3 samples) Arithoh 17357328.1 lps (10.2 secs, 3 samples) C Compiler Throughput 1801.4 lpm (61.4 secs, 3 samples) Dc: sqrt(2) to 99 decimal places 73671.7 lpm (37.9 secs, 3 samples) Recursion Test--Tower of Hanoi 142907.4 lps (20.3 secs, 3 samples) INDEX VALUES TESTBASELINE RESULT INDEX Dhrystone 2 using register variables116700.0 10486183.3 898.6 Double-Precision Whetstone 55.0 1289.1 234.4 Execl Throughput43.0 1229.4 285.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 109313.0 276.0 File Copy 256 bufsize 500 maxblocks 1655.050229.0 303.5 File Copy 4096 bufsize 8000 maxblocks 5800.064288.0 110.8 Pipe Throughput 12440.0 603048.3 484.8 Pipe-based Context Switching 4000.034302.9 85.8 Process Creation 126.0 3011.8 239.0 Shell Scripts (8 concurrent) 6.0 579.8 966.3 System Call Overhead 15000.0 494962.3 330.0 = FINAL SCORE 300.0 As you see, baselines a TOTALLY diffrent, this sucks. I trying to install Debian today w no luck. CD=ROM just will not boot. I'll try to install CentOS x32-AMD64 on friday and try to compile the source code of unixbench from freebsd port to get the same baselines. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: TESTBASELINE RESULT INDEX Dhrystone 2 using register variables116700.0 10486183.3 898.6 Double-Precision Whetstone 55.0 1289.1 234.4 Execl Throughput43.0 1229.4 285.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 109313.0 276.0 File Copy 256 bufsize 500 maxblocks 1655.050229.0 303.5 File Copy 4096 bufsize 8000 maxblocks 5800.064288.0 110.8 Pipe Throughput 12440.0 603048.3 484.8 Pipe-based Context Switching 4000.034302.9 85.8 Process Creation 126.0 3011.8 239.0 Shell Scripts (8 concurrent) 6.0 579.8 966.3 System Call Overhead 15000.0 494962.3 330.0 = FINAL SCORE 300.0 As you see, baselines a TOTALLY diffrent, this sucks. Yeah. Well, as long as we're posting results, here's from Xeon 5110 (the slowest Xeon from the Woodcrest family, 1.6 GHz, dual core): INDEX VALUES TESTBASELINE RESULT INDEX Dhrystone 2 using register variables116700.0 9983979.3 855.5 Double-Precision Whetstone 55.0 1456.5 264.8 Execl Throughput43.0 1423.1 331.0 File Copy 1024 bufsize 2000 maxblocks 3960.0 159513.0 402.8 File Copy 256 bufsize 500 maxblocks 1655.052679.0 318.3 File Copy 4096 bufsize 8000 maxblocks 5800.076063.0 131.1 Pipe Throughput 12440.0 627988.0 504.8 Pipe-based Context Switching 4000.071798.2 179.5 Process Creation 126.0 5569.4 442.0 Shell Scripts (8 concurrent) 6.0 503.0 838.3 System Call Overhead 15000.0 487202.2 324.8 = FINAL SCORE 361.4 signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Hmm. what kind of HDD, RAID or whatever are you using? My raid pretty much sucks. It is build it on the intel motherboard LSI Megaraid. But i still get 81Mb/sec when doing dd if=/dev/ar0 of=/dev/null bs=1M How much do you get on this? -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On Wed, 07 Mar 2007 17:30:12 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: On Wed, 07 Mar 2007 17:11:24 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: BYTE UNIX Benchmarks (Version 4.1-wht.1) Off-topic: Who or what is the origin of the wht version? One of the nice things about unixbench is that it hadn't changed from 1997, but now most Linux variants use the -wht version that has completely different baselines and results from the normal version? It's a version created for the website: webhostingtalk.com. It was created to have a stable and standard benchmark. Beautiful - they fiddled with the baselines but still managed not to see the obvious problem in execl() call in the execl benchmark for 64-bit platform. Or maybe they just don't care? It seems to me they use the software a lot and it serves their purposes. It's just a standardized version and run script that they use to evaluate web servers. -- shannon -- Star Wars Moral Number 17: Teddy | ...but a planet of wookies would still bears are dangerous in herds.| have been a lot better. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: Hmm. what kind of HDD, RAID or whatever are you using? My raid pretty much sucks. It is build it on the intel motherboard LSI Megaraid. But i still get 81Mb/sec when doing dd if=/dev/ar0 of=/dev/null bs=1M How much do you get on this? geom_mirror on 2 desktop SATA drives, but the results of dd are pretty low: # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.817686 secs (58850290 bytes/sec) As you can see, results with a single drive are better: # dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.219518 secs (64649023 bytes/sec) The mirror algorithm is split: # gmirror list Geom name: data State: COMPLETE Components: 2 Balance: split Slice: 16384 Flags: NONE GenID: 0 SyncID: 1 ID: 1455065622 Providers: 1. Name: mirror/data Mediasize: 24999488 (233G) Sectorsize: 512 Mode: r7w7e8 Consumers: 1. Name: ad4 Mediasize: 2500 (233G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 2273811345 2. Name: ad6 Mediasize: 2500 (233G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 926967552 Setting the algorithm back to load gives the performance similar to that of a single drive: # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.551914 secs (63350740 bytes/sec) It's really unusual that geom_mirror cannot benefit from splitting requests. signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: Hmm. what kind of HDD, RAID or whatever are you using? My raid pretty much sucks. It is build it on the intel motherboard LSI Megaraid. But i still get 81Mb/sec when doing dd if=/dev/ar0 of=/dev/null bs=1M How much do you get on this? geom_mirror on 2 desktop SATA drives, but the results of dd are pretty low: # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.817686 secs (58850290 bytes/sec) As you can see, results with a single drive are better: # dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.219518 secs (64649023 bytes/sec) Now i am lost. i get 81MB/sec on dd but still you get File Copy 1024 bufsize 2000 maxblocks 3960.0 159513.0 402.8 and i get File Copy 1024 bufsize 2000 maxblocks 3960.0 109313.0 276.0 The drives i use are Seagate 7200.10 (320Gb, SATA II, 16MB cache with perpendicular heads) How is it possible that you get 2x file copy perfomance ? What's the matter?! -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
- Original Message - From: Charles Shannon Hendrix [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Wednesday, March 07, 2007 9:49 PM Subject: Re: Some Unix benchmarks for those who are interesed On Wed, 07 Mar 2007 17:30:12 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: On Wed, 07 Mar 2007 17:11:24 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Charles Shannon Hendrix wrote: BYTE UNIX Benchmarks (Version 4.1-wht.1) Off-topic: Who or what is the origin of the wht version? One of the nice things about unixbench is that it hadn't changed from 1997, but now most Linux variants use the -wht version that has completely different baselines and results from the normal version? It's a version created for the website: webhostingtalk.com. It was created to have a stable and standard benchmark. Beautiful - they fiddled with the baselines but still managed not to see the obvious problem in execl() call in the execl benchmark for 64-bit platform. Or maybe they just don't care? It seems to me they use the software a lot and it serves their purposes. It's just a standardized version and run script that they use to evaluate web servers. Hmm. if the whole world uses wht version of unixbench maybe someone should update freebsd ports version to this wht version, because otherwise we cannot compare anything else than freebsd. Not good. -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On Wed, 07 Mar 2007 22:32:36 +0300 Artem Kuchin [EMAIL PROTECTED] wrote: Hmm. if the whole world uses wht version of unixbench maybe someone should update freebsd ports version to this wht version, because otherwise we cannot compare anything else than freebsd. Not good. Does it really matter? Benchmarks are like statistics; if you don't find one that fits your purpose, you just tweak / change an existing one until you get the results you want. Just my 0.02 euros. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
- Original Message - From: Torfinn Ingolfsen [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Wednesday, March 07, 2007 10:57 PM Subject: Re: Some Unix benchmarks for those who are interesed On Wed, 07 Mar 2007 22:32:36 +0300 Artem Kuchin [EMAIL PROTECTED] wrote: Hmm. if the whole world uses wht version of unixbench maybe someone should update freebsd ports version to this wht version, because otherwise we cannot compare anything else than freebsd. Not good. Does it really matter? Benchmarks are like statistics; if you don't find one that fits your purpose, you just tweak / change an existing one until you get the results you want. Not agreed. Benchmarks is a mean of comparing thing for figure out what is best for you or where is area with problems. If baselines are different then you cannot compare and then you cannot choose or determine problematic area and cannon improve what you already have. just my 0.02 russian federation roubles :) -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: Now i am lost. i get 81MB/sec on dd but still you get File Copy 1024 bufsize 2000 maxblocks 3960.0 159513.0 402.8 and i get File Copy 1024 bufsize 2000 maxblocks 3960.0 109313.0 276.0 The drives i use are Seagate 7200.10 (320Gb, SATA II, 16MB cache with perpendicular heads) How is it possible that you get 2x file copy perfomance ? What's the matter?! I don't know - what are your seek times? # diskinfo -t /dev/mirror/data /dev/mirror/data 512 # sectorsize 24999488# mediasize in bytes (233G) 488281249 # mediasize in sectors Seek times: Full stroke: 250 iter in 1.591444 sec =6.366 msec Half stroke: 250 iter in 1.468315 sec =5.873 msec Quarter stroke: 500 iter in 2.828050 sec =5.656 msec Short forward:400 iter in 2.958083 sec =7.395 msec Short backward: 400 iter in 2.465687 sec =6.164 msec Seq outer: 2048 iter in 0.337428 sec =0.165 msec Seq inner: 2048 iter in 0.384791 sec =0.188 msec Transfer rates: outside: 102400 kbytes in 1.737217 sec =58945 kbytes/sec middle:102400 kbytes in 1.811793 sec =56519 kbytes/sec inside:102400 kbytes in 2.938688 sec =34845 kbytes/sec drives: ad4: 238418MB WDC WD2500JS-75NCB3 10.02E04 at ata2-master SATA150 ad6: 238418MB WDC WD2500JS-75NCB3 10.02E04 at ata3-master SATA150 signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Fluffles wrote: If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 I'd agree in theory, but bonnie++ gives WORSE results than raw device: Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ..xx 1G 305 99 59135 15 21350 7 501 99 57480 11 478.5 13 Latency 27325us 63238us 535ms 45347us 68125us 2393ms And pumping vfs.read_max to an obscene value doesn't really help: # sysctl vfs.read_max=256 vfs.read_max: 16 - 256 Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ..xx 1G 305 99 57718 15 18758 6 500 99 60900 13 467.8 13 Latency 27325us 89977us 99594us 36706us 71907us 90021us I've experimented with increasing MAXPHYS (to 256K) before and it also doesn't help. signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: Artem Kuchin wrote: Hmm. what kind of HDD, RAID or whatever are you using? My raid pretty much sucks. It is build it on the intel motherboard LSI Megaraid. But i still get 81Mb/sec when doing dd if=/dev/ar0 of=/dev/null bs=1M How much do you get on this? geom_mirror on 2 desktop SATA drives, but the results of dd are pretty low: # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.817686 secs (58850290 bytes/sec) As you can see, results with a single drive are better: # dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.219518 secs (64649023 bytes/sec) How is it possible that you get 2x file copy perfomance ? What's the matter?! If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 You can test read STR best with bonnie (see /usr/ports/benchmarks/bonnie); or just with DD on a mounted volume. You should mount with -o noatime to avoid useless writes during reading, or use soft updates to prevent meta data from taking it's toll on I/O performance. - Veronica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
- Original Message - From: Fluffles [EMAIL PROTECTED] To: Artem Kuchin [EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 11:35 PM Subject: Re: Some Unix benchmarks for those who are interesed Artem Kuchin wrote: Artem Kuchin wrote: Hmm. what kind of HDD, RAID or whatever are you using? My raid pretty much sucks. It is build it on the intel motherboard LSI Megaraid. But i still get 81Mb/sec when doing dd if=/dev/ar0 of=/dev/null bs=1M How much do you get on this? geom_mirror on 2 desktop SATA drives, but the results of dd are pretty low: # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.817686 secs (58850290 bytes/sec) As you can see, results with a single drive are better: # dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.219518 secs (64649023 bytes/sec) How is it possible that you get 2x file copy perfomance ? What's the matter?! If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 You can test read STR best with bonnie (see /usr/ports/benchmarks/bonnie); or just with DD on a mounted volume. You should mount with -o noatime to avoid useless writes during reading, or use soft updates to prevent meta data from taking it's toll on I/O performance. Totall disagree. On the following reasons: 1) Read ahead is simply useless when stream-reading (sequential) 1GB of data 2) atime is NOT updated when using dd on any device, atime is related to file/inode operations which are not performed by dd 3) soft update are also useless (no bad, no good) for long sequential read basically, long sequatial reads/write ignore anything but real drive speed (plate on the spindle) if they are performed long enough. I think that 2 times differences is reallty related to seek times. But on the other hand i am sure my HDD have very good seek times. I'll have a chance to check it all on friday. -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: - Original Message - From: Fluffles [EMAIL PROTECTED] If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 You can test read STR best with bonnie (see /usr/ports/benchmarks/bonnie); or just with DD on a mounted volume. You should mount with -o noatime to avoid useless writes during reading, or use soft updates to prevent meta data from taking it's toll on I/O performance. Totall disagree. On the following reasons: 1) Read ahead is simply useless when stream-reading (sequential) 1GB of data I happen to have run a great number of benchmarks with various geom layers (such as: gstripe, gmirror, graid3, graid5) and as far as i recall the read speeds i got with DD (1GB transfer) were always lower than a bonnie benchmark on a mounted (thus UFS/VFS) volume. Since im no dev i cannot explain this with absolute certainty, but i would guess this is due to the lack of read-ahead and an I/O queue of only 1 when using DD. This did not occur on a plain disk though, without any geom layers attached to it. Some benchmark output: gstripe (4 disks on nVidia controller [Embedded], 128KB stripesize, Test System 1) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- DD benchmark(1GB) Results in MB/s avg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4k READ47.146.946.846.9 WRITE 40.940.941.040.9 16k READ92.792.892.692.7 WRITE 76.376.176.276.2 64k READ120.8 120.6 120.6 120.6 WRITE 96.196.296.196.1 128kREAD123.0 122.8 122.8 122.8 WRITE 96.396.496.296.3 1m READ122.7 122.9 122.6 122.7 WRITE 89.489.489.489.4 ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4096 104288 90.4 237690 74.4 71008 22.0 87837 91.9 250858 44.6 114.8 0.7 analysis: geom_stripe performs worse in a raw-disk situation; but when UFS optimizations come along the performance is more than doubled. geom_raid5 with 8 SATA disks (128KB stripe, graid5-tng, Test System 2) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- DD benchmark(1GB) Results in MB/s avg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4k READ58.158.759.058.6 WRITE 155.5 155.8 154.3 155.2 16k READ130.0 125.6 129.5 128.3 WRITE 308.5 306.3 306.9 307.2 64k READ183.8 183.9 188.9 185.5 WRITE 416.9 416.7 415.8 416.4 128kREAD197.3 194.4 197.6 196.4 WRITE 421.0 426.2 399.7 415.6 1m READ193.0 196.8 198.1 195.9 WRITE 327.6 330.3 331.0 329.6 ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4096 137897 96.7 310917 76.7 65233 16.0 101410 95.8 407013 45.5 475.5 3.0 Analysis: as you can see, read performance by DD is ~200MB/s while bonnie gives us some ~400MB/s. The writes are again. This is due to the fact that geom_raid5 uses write I/O request combining in order to avoid the 'raid5 write hole' and is thus able to get *write* speeds of 400MB/s, which is quite remarkable for software RAID5. Adding the higher I/O queue of UFS (7) and the fact that UFS does not write sequentially on the medium (maximum number of blocks per cylinder), this gives the combining-algoritm more work, which leads to some decreased write performance from 400MB/s to ~300MB/s; still very good. CPU was bottleneck. 2) atime is NOT updated when using dd on any device, atime is related to file/inode operations which are not performed by dd Well i did gave one DD command on a mounted volume, then it is related to a file/inode, like this: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 Then you are working on UFS/VFS level, not? 3) soft update are also useless (no bad, no good) for long sequential read I agree, but due to the fact the volume is mounted
Re: Some Unix benchmarks for those who are interesed
Ivan Voras wrote: Fluffles wrote: If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 I'd agree in theory, but bonnie++ gives WORSE results than raw device: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Also, checkout my benchmark results i posted in response to Andrei Kolu in particular the geom_raid5 benchmark; there the UFS/VFS layer causes 25% lower write performance; due to cpu bottlenecks (and some UFS inefficiency with regard to max blocks per cylinder). So for all i know it may be just your CPU which is limiting sequential performance somewhat. Regards, - Veronica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
On 03/07/07 23:13, Fluffles wrote: Ivan Voras wrote: Fluffles wrote: If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 I'd agree in theory, but bonnie++ gives WORSE results than raw device: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Before making speculative claims about slow CPU's and putting the VIA C3 in with that pile, please at least refer to what makes you believe that it is an issue. Comparing the VIA C3 to 'some old pentium' isn't exactly fair or accurate, and inferring it isn't a modern system isn't true either. Forgive me though, I'm biased. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: I used unixbenchmark for measure overall perfomance of three machines of different generations and with different OS versions. See for your self and compare results with machine cost. Hope this will be usefull for someone. Several things: a) It looks like your message was weirdly truncated - whole rectangles of text are missing from the results on the right-hand-side. Maybe you copied it through Excel? b) I submitted a patch for unixbench than enables execl benchmark on amd64, it should be in the ports tree by now. c) It would be interesting for the general discussion if you could install a recent server-like version of Linux (e.g. CentOS, SuSE, Debian) on one of the machines you did your benchmarks on to compare results :) signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: I used unixbenchmark for measure overall perfomance of three machines of different generations and with different OS versions. See for your self and compare results with machine cost. Hope this will be usefull for someone. Several things: a) It looks like your message was weirdly truncated - whole rectangles of text are missing from the results on the right-hand-side. Maybe you copied it through Excel? Ummm... hmmm.. i checked the message in the list, nothimng is missing. Just like it was in the putty terminal from where i copied it. b) I submitted a patch for unixbench than enables execl benchmark on amd64, it should be in the ports tree by now. oh! that's good. will retest. c) It would be interesting for the general discussion if you could install a recent server-like version of Linux (e.g. CentOS, SuSE, Debian) on one of the machines you did your benchmarks on to compare results :) I am not good at linux, but this is an interesting idea. I'll try it. Which one is easier to install? -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: a) It looks like your message was weirdly truncated - whole rectangles of text are missing from the results on the right-hand-side. Maybe you copied it through Excel? Ummm... hmmm.. i checked the message in the list, nothimng is missing. Just like it was in the putty terminal from where i copied it. See here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033494.html c) It would be interesting for the general discussion if you could install a recent server-like version of Linux (e.g. CentOS, SuSE, Debian) on one of the machines you did your benchmarks on to compare results :) I am not good at linux, but this is an interesting idea. I'll try it. Which one is easier to install? Both CentOS (aka repacked RedHat Enterprise Server) and SuSE (actually, openSuSE which is free) are easy to install. But I think you'll have to compile unixbench for them. signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
See here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033494.html Yes, that what i've got in the list and this how it was in the putty terminal originally. Nothing is missing. I don't know why open left parentesis are there. -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some Unix benchmarks for those who are interesed
Artem Kuchin wrote: See here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033494.html Yes, that what i've got in the list and this how it was in the putty terminal originally. Nothing is missing. I don't know why open left parentesis are there. The block under the header: INDEX VALUES TESTBASELINE is important - it summarises the results and your post is missing the summaries :) signature.asc Description: OpenPGP digital signature
