View source

From ComputingPlugs

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

== CPU performance with nbench-byte-2.2.3 == [http://www.tux.org/~mayer/linux/bmark.html nbench] is an old school benchmark program made by BYTE. It is used to test the CPU's memory access, integer and floating point speed. It is useful to benchmark the Sheeva Plug with nbench because the nbench webiste has a large collections of results from computers long ago (Intel 486DX/33!). === Results from Sheeva Plug === <pre> BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 309.72 : 7.94 : 2.61 STRING SORT : 36.102 : 16.13 : 2.50 BITFIELD : 9.8289e+07 : 16.86 : 3.52 FP EMULATION : 71.075 : 34.10 : 7.87 FOURIER : 356.63 : 0.41 : 0.23 ASSIGNMENT : 4.207 : 16.01 : 4.15 IDEA : 1146.3 : 17.53 : 5.21 HUFFMAN : 452.41 : 12.55 : 4.01 NEURAL NET : 0.49636 : 0.80 : 0.34 LU DECOMPOSITION : 16.116 : 0.83 : 0.60 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 15.922 FLOATING-POINT INDEX: 0.646 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : L2 Cache : OS : Linux 2.6.30-rc1-00002-g1758996 C compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) libc : libc-2.9.so MEMORY INDEX : 3.317 INTEGER INDEX : 4.549 FLOATING-POINT INDEX: 0.358 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. </pre> === Results from Intel Core2Duo T7700 @ 2.4GHz === <pre> BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 1011.4 : 25.94 : 8.52 STRING SORT : 137.65 : 61.51 : 9.52 BITFIELD : 4.3915e+08 : 75.33 : 15.73 FP EMULATION : 148.24 : 71.13 : 16.41 FOURIER : 27971 : 31.81 : 17.87 ASSIGNMENT : 36.277 : 138.04 : 35.80 IDEA : 6498.8 : 99.40 : 29.51 HUFFMAN : 2150 : 59.62 : 19.04 NEURAL NET : 42.133 : 67.68 : 28.47 LU DECOMPOSITION : 1579.8 : 81.84 : 59.10 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 68.383 FLOATING-POINT INDEX: 56.061 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz 2401MHz L2 Cache : 4096 KB OS : Linux 2.6.27-11-generic C compiler : gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) libc : libc-2.8.90.so MEMORY INDEX : 17.504 INTEGER INDEX : 16.742 FLOATING-POINT INDEX: 31.094 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 </pre> === Results from Intel M @ 1.2Ghz === <pre> BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 507.68 : 13.02 : 4.28 STRING SORT : 52.377 : 23.40 : 3.62 BITFIELD : 1.8894e+08 : 32.41 : 6.77 FP EMULATION : 60.591 : 29.07 : 6.71 FOURIER : 12344 : 14.04 : 7.89 ASSIGNMENT : 10.466 : 39.83 : 10.33 IDEA : 2659.7 : 40.68 : 12.08 HUFFMAN : 826.13 : 22.91 : 7.32 NEURAL NET : 16.23 : 26.07 : 10.97 LU DECOMPOSITION : 611.04 : 31.66 : 22.86 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 27.072 FLOATING-POINT INDEX: 22.628 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : GenuineIntel Intel(R) Pentium(R) M processor 1200MHz 1200MHz L2 Cache : 1024 KB OS : Linux 2.6.28-11-generic C compiler : gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) libc : libc-2.8.90.so MEMORY INDEX : 6.327 INTEGER INDEX : 7.095 FLOATING-POINT INDEX: 12.550 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. </pre> The most important numbers from the results are the '''MEMORY INDEX''', '''INTERGER INDEX''' and '''FLOATING-POINT INDEX''' because they're listed in [http://www.tux.org/~mayer/linux/results2.html nbench's website]. {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !CPU!!MEM!!INT!!FP |- |Sheeva Plug||3.317||4.549||0.358 |- |Intel Core2Due T770 @ 2.4Ghz||17.504||16.742||31.094 |- |Intel M @ 1.20Ghz||6.327||7.095||12.550 |- |Intel PIII @ 866Mhz (from nbench's website)||3.994||4.984||8.479 |- |AMD Athlon @ 1Ghz (from nbench's website)||3.463||4.623||8.232 |} The Sheeva Plug doesn't have a hardware floating point unit so the FP number is very low. It is also slower than an Intel M running at the same clock speed. From nbench's website, the Sheeva Plug falls somewhere around a P3 800Mhz range. If you want to run the benchmark yourself and don't feel like compiling the source, you can get the nbench binary for the Sheeva Plug [http://www.computingplugs.com/files/nbench.bz2 here]. == USB storage throughput== I connected my SanDisk 8G USB thumb drive to the Sheeva Plug and ran a quick and dirty throughput test. For the write test, I used ''dd'' and wrote 1024000000 bytes to a file on the thumb drive from ''/dev/zero''. For the read test, I used ''dd'' and read the same file then send it to ''/dev/null''. The thumb drive is formatted with ext3. Here are the results: <pre> read command: sync; time sh -c "dd if=./test of=/dev/null; sync" write command: sync; time sh -c "dd if=/dev/zero of=./test bs=1000k count=1000; sync" </pre> {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |read |37.848 sec |37.999 sec |36.655 sec |37.500 sec |27.3 MBytes/sec |- |write |365.479 sec |380.134 sec |362.515 sec |369.376 sec |2.8 MBytes/sec |} As expected, the read speed is very respectable while the write speed is abysmal. I believe this is the fault of the SanDisk and not the SheevaPlug because the Sandisk was the cheapest 8G model I could find and was not build for speed. The next test, with an external HDD, should prove the theory. Using the same commands, I tested the throughput of a Western Digital My Passport Essential 320 GB (WDME3200TN) external harddrive. The harddrive has been formatted with ext3. The results are as follows: {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |read |34.337 sec |37.624 sec |36.481 sec |36.147 sec |28.3 MBytes/sec |- |write |40.719 sec |36.968 sec |34.951 sec |37.546 sec |27.3 MBytes/sec |} So using an external hard drive instead of a thumb drive show a huge improvement in the write speed. This means that the CPU and USB can definitely handle desktop like throughput rates with an external hard drive. === Update USB throughput on v2.6.30-rc3 kernel with mmc patch === I reran the USB throughput test on the mainline 2.6.30 kernel with the external hard drive. Here are the results: {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |read |35.277 sec |32.526 sec |34.429 sec |34.077 sec |30.04 MBytes/sec |- |write |36.275 sec |38.080 sec |35.878 sec |36.744 sec |27.87 MBytes/sec |} The new kernel seems to have higher read throughput and about the same write throughput. The increase, however, is not very significant. == SDHC storage throughput == I used a class 6, 16G SDHC memory card for this test. I used the same test as the USB throughput test and the SHC memory card has been formatted with ext3. There is a bug in Orion and mainline kernel's mmc code that cause the kernel to report: <pre>mmc0: error -110 whilst initialising SD card</pre> if you plug in a SDHC memory card. There is [[Fixing_SDHC_access_in_the_Orion/Mainline_kernel|a patch]] to fix this bug. To get around this problem, I used the original kernel that came with the Sheeva Plug. This is actually a better test since most people will probably ''not'' replace their kernel. {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |read |120.843 sec |121.001 sec |121.029 sec |120.959 sec |8.47 MBytes/sec |- |write |594.655 sec |622.411 sec |590.688 sec |602.584 sec |1.69 MBytes/sec |} The throughput was so bad that I had to make sure it wasn't the SDHC memory card, so I used the same memory card and tried the same test on another computer: {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !avg !throughput |- |read |56.353 sec |18.2 MBytes/sec |- |write |157.571 sec |6.49 MBytes/sec |} The results are more inline with was I expect from a class 6 SDHC memory card. So I have to conclude that the Sheeva Plug's SDHC performance is really that awful. I suppose the only good thing is that the Sheeva Plug supports SDHC at all. === Update SDHC throughput on v2.6.30-rc3 kernel with mmc patch === I updated the Sheeva Plug with the mainline 2.6.30-rc3 kernel and I patched it so that SDHC will work. I reran the test to see if the new kernel makes a differences. {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |read |53.743 sec |53.777 sec |53.684 sec |53.734 sec |19.03 MBytes/sec |- |write |155.949 sec |168.737 sec |149.886 sec |158.190 sec |6.47 MBytes/sec |} Either the new kernel or the new driver made a huge difference in speed. The SDHC throughput on the Sheeva Plug is now completely in line with the throughput on a fast computer. This changed made a world of difference for the Sheeva Plug. == Network Performance == I tested the network performance by moving a 1,095,128,170 bytes file to/from the Sheeva Plug. The storage used on the Sheeva Plug is an external USB harddrive formatted with ext3. Both the Sheeva Plug and the test computer are connected with Gigabit Ethernet switch. The same setup with two fast computers produced a throughput of ~25Mbytes per second. === Moving data over scp === {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |From Sheeva Plug to computer |165.293 sec |175.164 sec |164.671 sec |168.376 sec |6.50 MBytes/sec |- |From computer to Sheeva Plug |171.585 sec |179.384 sec |171.374 sec |174.114 sec |6.29 MBytes/sec |} The Sheeva Plug is running at 100% CPU load (''sshd'') during the scp operation. That could be the limiting factoring in the transfer speed. === Moving data over NFS (resource shared by Sheeva Plug) === {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |From Sheeva Plug to computer |91.988 sec |96.761 sec |87.336 sec |92.028 sec |11.9 MBytes/sec |- |From computer to Sheeva Plug |84.097 sec |77.087 sec |79.699 sec |80.294 sec |13.6 MBytes/sec |} The Sheeva Plug is running at ~95% CPU load (''nfsd'') during the cp operation. === Moving data over Samba (resource shared by Sheeva Plug) === {| border="1" cellpadding="5" cellspacing="0" |- style="background-color:#daea23;" !op !1st !2nd !3rd !avg !throughput |- |From Sheeva Plug to computer | 168.449 sec | 169.971 sec | 165.528 sec | 167.982 sec | 6.52 MBytes/sec |- |From computer to Sheeva Plug |74.851 sec |76.094 sec |74.070 sec |75.005 sec |14.6 MBytes/sec |} The Sheeva Plug is running at ~85% CPU load (''smbd'') while moving data from computer to Sheeva Plug and ~60% CPU load while moving data from Sheeva Plug to computer. I don't know why the load is asymmetric, but that would explain the difference in throughput. == MySQL benchmark == MySQL comes with a benchmark suite to test the speed of the database. You can read more about the benchmark suite [http://dev.mysql.com/doc/refman/5.0/en/mysql-benchmarks.html here]. MySQL performance is important for running [[Sheeva_Plug_as_a_MythTV_master_backend|MythTV backend]]. Here are the results of the benchmark on the SheevaPlug. <pre> $ perl run-all-tests --user=root --password=password Benchmark DBD suite: 2.15 Date of test: 2009-05-16 22:23:43 Running tests on: Linux 2.6.30-rc3-dirty armv5tel Arguments: Comments: Limits from: Server version: MySQL 5.0.75 0ubuntu10/ Optimization: None Hardware: alter-table: Total time: 50 wallclock secs ( 0.25 usr 0.04 sys + 0.00 cusr 0.00 csys = 0.29 CPU) ATIS: Total time: 58 wallclock secs (49.70 usr 0.86 sys + 0.00 cusr 0.00 csys = 50.56 CPU) big-tables: Total time: 36 wallclock secs (13.84 usr 1.31 sys + 0.00 cusr 0.00 csys = 15.15 CPU) connect: Total time: 467 wallclock secs (164.06 usr 38.03 sys + 0.00 cusr 0.00 csys = 202.09 CPU) create: Total time: 229 wallclock secs (17.84 usr 3.77 sys + 0.00 cusr 0.00 csys = 21.61 CPU) insert: Total time: 5200 wallclock secs (2384.54 usr 128.10 sys + 0.00 cusr 0.00 csys = 2512.64 CPU) select: Total time: 604 wallclock secs (231.98 usr 6.56 sys + 0.00 cusr 0.00 csys = 238.54 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 33 wallclock secs (12.78 usr 1.55 sys + 0.00 cusr 0.00 csys = 14.33 CPU) All 9 test executed successfully Totals per operation: Operation seconds usr sys cpu tests alter_table_add 21.00 0.06 0.00 0.06 100 alter_table_drop 19.00 0.03 0.01 0.04 91 connect 33.00 22.87 2.50 25.37 10000 connect+select_1_row 42.00 24.04 2.91 26.95 10000 connect+select_simple 38.00 25.00 3.80 28.80 10000 count 37.00 0.09 0.01 0.10 100 count_distinct 1.00 0.85 0.04 0.89 1000 count_distinct_2 1.00 0.82 0.05 0.87 1000 count_distinct_big 54.00 47.47 0.07 47.54 120 count_distinct_group 6.00 5.48 0.04 5.52 1000 count_distinct_group_on_key 2.00 1.23 0.00 1.23 1000 count_distinct_group_on_key_parts 5.00 5.52 0.03 5.55 1000 count_distinct_key_prefix 1.00 0.78 0.04 0.82 1000 count_group_on_key_parts 6.00 5.35 0.06 5.41 1000 count_on_key 100.00 37.96 2.31 40.27 50100 create+drop 70.00 5.41 0.83 6.24 10000 create_MANY_tables 64.00 3.42 0.45 3.87 10000 create_index 5.00 0.00 0.00 0.00 8 create_key+drop 76.00 6.65 1.42 8.07 10000 create_table 1.00 0.00 0.00 0.00 31 delete_all_many_keys 115.00 0.00 0.00 0.00 1 delete_big 1.00 0.00 0.00 0.00 1 delete_big_many_keys 115.00 0.00 0.00 0.00 128 delete_key 8.00 1.31 0.48 1.79 10000 delete_range 32.00 0.01 0.00 0.01 12 drop_index 5.00 0.01 0.00 0.01 8 drop_table 0.00 0.01 0.00 0.01 28 drop_table_when_MANY_tables 7.00 1.14 0.53 1.67 10000 insert 228.00 41.51 16.39 57.90 350768 insert_duplicates 61.00 8.27 2.33 10.60 100000 insert_key 201.00 21.69 5.20 26.89 100000 insert_many_fields 20.00 0.90 0.13 1.03 2000 insert_select_1_key 15.00 0.00 0.00 0.00 1 insert_select_2_keys 18.00 0.00 0.00 0.00 1 min_max 14.00 0.05 0.00 0.05 60 min_max_on_key 90.00 71.90 2.74 74.64 85000 multiple_value_insert 10.00 1.22 0.01 1.23 100000 once_prepared_select 125.00 34.75 5.64 40.39 100000 order_by_big 176.00 149.01 0.37 149.38 10 order_by_big_key 173.00 152.52 0.61 153.13 10 order_by_big_key2 173.00 149.66 0.35 150.01 10 order_by_big_key_desc 185.00 151.63 0.54 152.17 10 order_by_big_key_diff 169.00 148.17 0.31 148.48 10 order_by_big_key_prefix 177.00 149.49 0.39 149.88 10 order_by_key2_diff 19.00 13.09 0.02 13.11 500 order_by_key_prefix 10.00 6.67 0.04 6.71 500 order_by_range 10.00 6.82 0.06 6.88 500 outer_join 16.00 0.01 0.00 0.01 10 outer_join_found 14.00 0.01 0.00 0.01 10 outer_join_not_found 12.00 0.00 0.00 0.00 500 outer_join_on_key 12.00 0.00 0.00 0.00 10 prepared_select 178.00 56.18 6.46 62.64 100000 select_1_row 65.00 12.98 3.97 16.95 100000 select_1_row_cache 29.00 11.83 3.35 15.18 100000 select_2_rows 76.00 13.89 5.12 19.01 100000 select_big 166.00 149.16 0.42 149.58 80 select_big_str 36.00 15.78 4.00 19.78 10000 select_cache 9.00 6.46 0.68 7.14 10000 select_cache2 336.00 8.24 0.56 8.80 10000 select_column+column 78.00 13.79 4.14 17.93 100000 select_diff_key 2.00 0.49 0.02 0.51 500 select_distinct 10.00 9.57 0.05 9.62 800 select_group 15.00 5.79 0.19 5.98 2911 select_group_when_MANY_tables 12.00 1.20 0.54 1.74 10000 select_join 3.00 2.88 0.03 2.91 100 select_key 338.00 208.59 10.96 219.55 200000 select_key2 358.00 157.41 13.99 171.40 200000 select_key2_return_key 346.00 142.58 8.65 151.23 200000 select_key2_return_prim 356.00 114.08 10.92 125.00 200000 select_key_prefix 361.00 168.28 11.88 180.16 200000 select_key_prefix_join 29.00 26.87 0.07 26.94 100 select_key_return_key 328.00 173.38 10.48 183.86 200000 select_many_fields 15.00 12.94 1.17 14.11 2000 select_range 61.00 51.85 0.19 52.04 410 select_range_key2 22.00 18.28 1.02 19.30 25010 select_range_prefix 22.00 18.64 0.88 19.52 25010 select_simple 34.00 11.78 4.82 16.60 100000 select_simple_cache 35.00 12.10 3.42 15.52 100000 select_simple_join 3.00 3.32 0.03 3.35 500 update_big 94.00 0.00 0.00 0.00 10 update_of_key 49.00 6.65 2.61 9.26 50000 update_of_key_big 64.00 0.04 0.03 0.07 501 update_of_primary_key_many_keys 50.00 0.04 0.02 0.06 256 update_with_key 242.00 41.26 12.69 53.95 300000 update_with_key_prefix 98.00 25.45 5.70 31.15 100000 wisc_benchmark 10.00 9.02 0.11 9.13 114 TOTALS 6723.00 2813.68 179.88 2993.56 3425950 </pre> == Real time statistics == I have [[SheevaPlug_Real_time_Statistics|real time statistics]] for the SheevaPlug that's collected every minute. The charts are redrawn every 10 minutes. == Power usage == I used a kill-a-watt to measure the power usage at the AC line level. Here is a table of the Sheeva Plug's power usage on different configurations. I also added power usage of the 2 Intel CPUs as a comparison. {| border=1 cellpadding="2" cellspacing="0" |- style="background-color:#daea23;" !CPU !Operation !Watts |- style="background-color:#ccffcc;" |frame="lhs"|Sheeva Plug | | |- style="background-color:#ccffcc;" | |Idle w/ nothing connected except serial |4 |- style="background-color:#ccffcc;" | |Idle w/ Ethernet & serial connected |5 |- style="background-color:#ccffcc;" | |CPU @ 100% w/ Ethernet & serial connected |high 5 |- style="background-color:#ccffcc;" | |idle w/ serial, and SDHC connected but not being accessed |4 |- style="background-color:#ccffcc;" | |~60% load w/ serial, and SDHC being access (CPU loading due to SDHC access) |high 4 |- style="background-color:#ccffcc;" | |idle w/ serial and USB thumb connected but not being accessed |5 |- style="background-color:#ccffcc;" | |~30% load w/ serial and USB thumb being access (CPU loading due to USB access) |high 5 |- style="background-color:#ccffcc;" | |idle w/ USB wireless dongle attached |6 |- style="background-color:#ccffcc;" | |idle w/ serial and USB HDD connected but not being accessed |low 6 |- style="background-color:#ccffcc;" | |~30% load w/ serial and USB HDD being access (CPU loading due to USB access) |low 9 |- style="background-color:#ccffcc;" | |CPU @ 100% load, w/ Ethernet, serial, SDHC being access, USB HDD being access |low 11 |- style="background-color:#ffcccc;" |Intel Core2Due T7700 @ 2.4Ghz | | |- style="background-color:#ffcccc;" | |idle |83 |- style="background-color:#ffcccc;" | |CPU @ 100% load |115 |- style="background-color:#ccccff;" |Intel M @1.2Ghz | | |- style="background-color:#ccccff;" | |idle, CPU @ 600Mhz w/ screen ON |15 |- style="background-color:#ccccff;" | ||idle, CPU @ 600Mhz w/ screen OFF||11 |- style="background-color:#ccccff;" | ||CPU @ 100%, 1.2Ghz w/ screen ON||24 |} The Intel M measurement was done on my laptop with the battery removed. <wp:comments> wp_post_title=SheevaPlug Performance wp_url=http://computingplugs.com/wp </wp:comments>

Return to SheevaPlug Performance.