Drive Stress Test - burnindrive264g12
The program uses 64 KB block sizes, with 164 variations of data patterns or a minimum file size of 10.25 MB. Larger files can be produced via a run time multiplication parameter, in this case 16 for for 164 MB files. Four of these written then read sequentially for 12 minutes, but with the choice of files randomised. Finally, each block/data pattern is reread continuously for a second, at full bus speed from disk drives that cache the data. On reading, file number and data values are compared and errors reported.
Note that measured speeds are generally slower than from DriveSpeed benchmark, covered earlier, as data transfers are based on using smaller 64 KB blocks.
The following provides summary Pi 5 results including MB/second performance calculations. The tests exercised the main SD drive, LAN, WiFi and USB 3. Devices on the latter were for a hard drive with Ext2, Ext3, Ext4 and FAT32 partitions and three flash drives. The LAN and WiFi tests were also run on a Pi 400 to confirm the similar performance. No errors were detected.
A gigabit LAN connection was used and WiFi reported as 5 GHz, with the former around 5 times faster on writing and up to 10 times reading. There were performance variations on the various solid state drives that could affect certain applications. One of the disk drive tests, using the Ext3 partition, had inexplicable slow speeds and, when repeated, somewhat slower than the other partitions on writing. Note the much faster transfer speeds with repeated reading of 64 KB blocks, indicating cached data and bus speed.
BurnInDrive Stress Test With Performance Monitoring
Following are details of a run handling four 2624 MB files, along with associated results from vmstat performance monitor and my CPU Voltage, MHz and Temperature recorder. The tests were run using the Ext3 partition.
First below are the program results with faster writing speeds than above, reading speeds a little slower and repeat reading similar. These might be due to handling larger files.
Second are the sample vmstat results (size numbers are KB) with nothing strange on 8 GB memory utilisation. There were variations in bo writing and bi reading speeds but essentially confirm program measurements. Percentage user + system CPU utilisation was low (note that such a 25% reflects 100% of one core and 100% indicates four core fully utilised).
Finally are samples of the environment measurements that were effectively constant. Results are provided for the start, middle and end of the tests. With ondemand CPU frequency scaling being used, a constant 1500 MHz was indicated for most of the time.
This test was run later on a Pi 4 where writing was 9% slower, reading 6%, repeat reading 18% with similar for CPU utilisation. See results below.
Disk Drive Errors and Crashes - Power Supply Problems
I have two 1TB USB 3 disk drives. The first crash occurred in attempting to run the new benchmark on both disk drives when connected to the USB hub via one USB port. It would have been obvious, if I had looked up the specification. That indicated a maximum of 900 mA, where up to 660 mA on one drive had been observed. It seems that a 5 Amps power supply would not help in running this sort of activity, but should be using a powered USB hub.
The second crash was running two disk drive benchmarks with one on the hub, plus my 4 thread integer CPU stress test. This time the crash appeared to be due to the power demand being greater than the 3 Amps supply. 3.06 Amps was indicated shortly before the crash.
Before the next crash I successfully ran two copies of my burnindrive264g12 stress test on separate USB ports. Then, with one of these and one integer stress test, the last measurements before the screen went blank were a data transfer failure reported by my program and a power input recording of 2.72 Amps. Following is a report from the last failing test session, indicating the seriousness of the situation, reading the wrong file and corrupted data.
Later tests were run using a 4 amps power supply. At the time of testing, the official 5 amps power supply was not available.
Other System Crashes
The first tests carried out were run with the Pi 5 operating via a 2 amps power supply, without any real problems running the short duration benchmarks. However, there were reductions in performance on running a series of tests, due to temperature increases. I had a cheap cooling fan module used for Pi 4 tests that I fitted on top of the Pi 5, to connect for use when needed, such as for the following procedures.
High Performance Linpack - I attempted to build this benchmark, to continue using as a stress test. This takes an excessive amount of time to build, appearing to repetitively execute the code for tuning purposes for a particular computer. In view of the timescale, I ensured that the cooling fan was working.
The first attempt was left to run overnight, only to find, in the morning, that the system had crashed. A second attempt crashed after 7 hours. Later with a 3 amps power supply, it took 12 hours to build (but other required software was found to be incompatible).
Stress Test Crash - I had successfully run numerous of my floating point and integer stress tests using a data size parameter aiming to achieve maximum performance using L1 caches on all four CPU cores. Other runs with L2 cache sized data size occasionally crashed. Later these tests ran successfully using the 3 amps power supply, with similar temperature and CPU throttling levels.
Even later, with more demanding system stress tests, the 3 amps supply was found to be inadequate.
The program uses 64 KB block sizes, with 164 variations of data patterns or a minimum file size of 10.25 MB. Larger files can be produced via a run time multiplication parameter, in this case 16 for for 164 MB files. Four of these written then read sequentially for 12 minutes, but with the choice of files randomised. Finally, each block/data pattern is reread continuously for a second, at full bus speed from disk drives that cache the data. On reading, file number and data values are compared and errors reported.
Note that measured speeds are generally slower than from DriveSpeed benchmark, covered earlier, as data transfers are based on using smaller 64 KB blocks.
The following provides summary Pi 5 results including MB/second performance calculations. The tests exercised the main SD drive, LAN, WiFi and USB 3. Devices on the latter were for a hard drive with Ext2, Ext3, Ext4 and FAT32 partitions and three flash drives. The LAN and WiFi tests were also run on a Pi 400 to confirm the similar performance. No errors were detected.
A gigabit LAN connection was used and WiFi reported as 5 GHz, with the former around 5 times faster on writing and up to 10 times reading. There were performance variations on the various solid state drives that could affect certain applications. One of the disk drive tests, using the Ext3 partition, had inexplicable slow speeds and, when repeated, somewhat slower than the other partitions on writing. Note the much faster transfer speeds with repeated reading of 64 KB blocks, indicating cached data and bus speed.
Code:
Write Read Blocks RepeatedSource Seconds MB/sec Passes Minutes MB/sec Number Minutes MB/secCommsLAN Pi 5 to PC 19.3 34.0 156 12.06 35.4 99360 2.79 37.1LAN Pi 400 to PC 20.2 32.6 132 12.37 29.2 80900 2.79 30.2WiFi Pi 5 to PC 99.6 6.6 20 14.41 3.8 12540 3.61 3.6WiFi Pi 400 to PC 101.7 6.5 20 12.78 4.3 14720 3.66 4.2SD OS Card 41.7 15.7 260 12.03 59.1 174960 2.76 66.0USB 3 Flash DriveFlash 1 20.7 31.7 328 12.01 74.6 179200 2.76 67.6Flash 2 8.0 82.0 352 12.06 79.8 219400 2.75 83.1Flash 3 145.2 4.5 136 12.12 30.7 89860 2.77 33.8USB HDFAT32 Partition 8.4 78.1 268 12.15 60.3 408280 2.75 154.7Ext 2 Partition 8.9 73.7 272 12.03 61.8 432060 2.74 164.3Ext 3 Partition 1320 0.5 100 12.14 22.5 427360 2.74 162.5Ext 3 Repeat 11.8 55.6 256 12.09 57.9 431820 2.74 164.2Ext 4 Partition 9.0 72.9 284 12.10 64.2 432200 2.74 164.3 Following are details of a run handling four 2624 MB files, along with associated results from vmstat performance monitor and my CPU Voltage, MHz and Temperature recorder. The tests were run using the Ext3 partition.
First below are the program results with faster writing speeds than above, reading speeds a little slower and repeat reading similar. These might be due to handling larger files.
Second are the sample vmstat results (size numbers are KB) with nothing strange on 8 GB memory utilisation. There were variations in bo writing and bi reading speeds but essentially confirm program measurements. Percentage user + system CPU utilisation was low (note that such a 25% reflects 100% of one core and 100% indicates four core fully utilised).
Finally are samples of the environment measurements that were effectively constant. Results are provided for the start, middle and end of the tests. With ondemand CPU frequency scaling being used, a constant 1500 MHz was indicated for most of the time.
This test was run later on a Pi 4 where writing was 9% slower, reading 6%, repeat reading 18% with similar for CPU utilisation. See results below.
Code:
Write Read Blocks RepeatedSource Seconds MB/sec Passes Minutes MB/sec Number Minutes MB/secExt 3 Partition 129.2 81.2 16 13.99 50.0 419020 2.74 159.3Pi 4 Ext3 142.2 73.8 16 14.81 47.2 345680 2.75 130.9 VMSTATprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa stWRITE 1 1 0 6901476 137524 682832 0 0 0 77806 8123 11887 1 6 74 20 0 2 0 0 6901476 137524 682832 0 0 8 90292 9889 13562 1 7 74 18 0READ 1 1 0 6901476 137524 682832 0 0 32538 46 3377 5344 0 1 75 24 0 1 1 0 6901476 137524 682832 0 0 60064 16 7630 10652 3 2 72 24 0REPEAT 1 1 0 6868408 149372 699428 0 0 162170 3 19231 25503 0 4 72 24 0 1 1 0 6868408 149372 699428 0 0 162144 3 17290 25480 0 4 72 23 0ENVIRONMENT Seconds 0.0 ARM MHz=1500, core volt=0.9067V, CPU temp=37.3°C, pmic temp=38.4°C 453.6 ARM MHz=1500, core volt=0.9067V, CPU temp=38.9°C, pmic temp=38.4°C 897.4 ARM MHz=1500, core volt=0.9067V, CPU temp=38.9°C, pmic temp=38.6°C I have two 1TB USB 3 disk drives. The first crash occurred in attempting to run the new benchmark on both disk drives when connected to the USB hub via one USB port. It would have been obvious, if I had looked up the specification. That indicated a maximum of 900 mA, where up to 660 mA on one drive had been observed. It seems that a 5 Amps power supply would not help in running this sort of activity, but should be using a powered USB hub.
The second crash was running two disk drive benchmarks with one on the hub, plus my 4 thread integer CPU stress test. This time the crash appeared to be due to the power demand being greater than the 3 Amps supply. 3.06 Amps was indicated shortly before the crash.
Before the next crash I successfully ran two copies of my burnindrive264g12 stress test on separate USB ports. Then, with one of these and one integer stress test, the last measurements before the screen went blank were a data transfer failure reported by my program and a power input recording of 2.72 Amps. Following is a report from the last failing test session, indicating the seriousness of the situation, reading the wrong file and corrupted data.
Later tests were run using a 4 amps power supply. At the time of testing, the official 5 amps power supply was not available.
Code:
Selected File Path: /media/raspberrypi/EXT3/ Total MB 348052, Free MB 348052, Used MB 0 Storage Stress Test ARM 64 Bit v2.0 gcc 8, Fri Oct 6 21:28:44 2023 File size 2624.00 MB x 4 files, minimum reading time 12.0 minutes File 1 2624.00 MB written in 30.97 seconds File 2 2624.00 MB written in 28.80 seconds File 3 2624.00 MB written in 29.70 seconds File 4 2624.00 MB written in 32.35 seconds Total 121.83 seconds, Elapsed 121.83 seconds Start Reading Fri Oct 6 21:30:46 2023 Error reading file 1 Wrong File Read szzztestz-820 instead of szzztestz1 Error reading file 2 Wrong File Read szzztestz-820 instead of szzztestz2 Error reading file 3 Pass 1 file szzztestz1 word 1, data error was FFFFFCCC expected FFFFCCCC Pass 1 file szzztestz1 word 2, data error was FFFFFCCC expected FFFFCCCC ERRORS found during reading tests, see above End of test Fri Oct 6 21:34:09 2023 The first tests carried out were run with the Pi 5 operating via a 2 amps power supply, without any real problems running the short duration benchmarks. However, there were reductions in performance on running a series of tests, due to temperature increases. I had a cheap cooling fan module used for Pi 4 tests that I fitted on top of the Pi 5, to connect for use when needed, such as for the following procedures.
High Performance Linpack - I attempted to build this benchmark, to continue using as a stress test. This takes an excessive amount of time to build, appearing to repetitively execute the code for tuning purposes for a particular computer. In view of the timescale, I ensured that the cooling fan was working.
The first attempt was left to run overnight, only to find, in the morning, that the system had crashed. A second attempt crashed after 7 hours. Later with a 3 amps power supply, it took 12 hours to build (but other required software was found to be incompatible).
Stress Test Crash - I had successfully run numerous of my floating point and integer stress tests using a data size parameter aiming to achieve maximum performance using L1 caches on all four CPU cores. Other runs with L2 cache sized data size occasionally crashed. Later these tests ran successfully using the 3 amps power supply, with similar temperature and CPU throttling levels.
Even later, with more demanding system stress tests, the 3 amps supply was found to be inadequate.
Statistics: Posted by RoyLongbottom — Tue Jan 16, 2024 9:21 pm