Let's see what happens when we enable Volume Write Back Cache.
| Sequential |
J-Micron | Intel (Volume Write Back Cache Enabled) | ||
| Deskstar 160 GB array | Caviar 160 GB array | Deskstar 160 GB array | Caviar 160 GB array | |
| ReadOps | 2989.39 | 3351.38 | 4734.15 | 4886.61 |
| ReadMBs | 93.42 | 104.73 | 147.95 | 152.71 |
| Average Access Time | 0.33 | 0.3 | 0.22 | 0.22 |
| Maximum Access Time | 16.05 | 10.45 | 0 | 0 |
| CPU Utilization | 6.96 | 6.22 | 6.7 | 10.87 |
| WriteOps | 2698.06 | 2698.24 | 3623.16 | 4796.42 |
| WriteMBs | 84.32 | 84.32 | 113.23 | 149.89 |
| Average Access Time | 0.37 | 0.37 | 0.28 | 0.23 |
| Maximum Access Time | 1.7 | 16.24 | 0 | 0 |
| CPU Utilization | 4.24 | 4.31 | 5.58 | 11.95 |
In short, the differences is tremendous. Number of operations per second and average reads basically increase by about 50 percent. The Deskstar array experienced a higher increase than the Caviar (58 percent compared to 45 percent, respectively). The likely culprit holding the Caviar array back seems to be the CPU utilization - definitely higher on the Caviar array compared to the Deskstar's. Basically, we're seeing the same situation with writes. However, the degree of increase is different (34 percent on the Deskstar array and 77 percent on the Caviar's). Since CPU utilization is also higher with writes, obviously CPU utilization is not holding the Caviar back (though it is a little bit too high for our taste).
The results we're seeing here are very different to what we saw earlier with HD Tach. Enabling Volume Write Back Cache seems to also boost writes. They also differ in trend - the Caviar array average writes are much higher than the Deskstar - very different to what we saw with HD Tach. Well, it wouldn't be the first time HD Tach got it wrong.
| Random |
J-Micron | Intel (Volume Write Back Cache Enabled) | ||
| Deskstar 160 GB array | Caviar 160 GB array | Deskstar 160 GB array | Caviar 160 GB array | |
| ReadOps | 69.44 | 69.81 | 70.6 | 70.14 |
| ReadMBs | 2.17 | 2.18 | 2.2 | 2.19 |
| Average Access Time | 14.4 | 14.32 | 14.16 | 14.23 |
| Maximum Access Time | 29.67 | 26.51 | 0 | 0 |
| CPU Utilization | 3.72 | 3.96 | 0.12 | 3.52 |
| WriteOps | 115.91 | 183.17 | 173.19 | 184.45 |
| WriteMBs | 3.62 | 5.72 | 5.41 | 5.76 |
| Average Access Time | 8.57 | 5.46 | 5.85 | 5.42 |
| Maximum Access Time | 862.22 | 32.33 | 0 | 0 |
| CPU Utilization | 14.07 | 16.08 | 0.33 | 3.94 |
We've already seen what Volume Write Back Cache have to offer in sequential read and write patterns, what about random test results? Looks like it have something else to offer as well. Look at the Deskstar's array CPU utilization with reads - way lower than on the J-Micron controller and with Volume Write Back Cache disabled. Improvements with random writes are very significant - an increase in the number of write operations (from 115 op/s to 173 op/s), transfer rate and again - CPU utilization. We went from 14 percent to 0.33 percent! Even the Caviar experience a much lower CPU utilization with random reads.
Performance
To measure real world performance, we choose to measure the time it takes for a game to load a level. We choose three games for this test - F.E.A.R, Quake 4 and Serious Sam II. Because of the way the games work (caching some elements in RAM and virtual memory), we ran test for both first time load and reloads. We restart the computer after each first time load, clearing the RAM and virtual memory from any game data. Reloads or consecutive loads are done consecutively - in F.E.A.R and Quake 4, we load another level before reloading the first chapter. In Serious Sam, we reload the game directly after finishing one test run.We chose both F.E.A.R's and Quake 4's opening cinematic simply because these levels are generally much larger than the average levels for both games. For Serious Sam II, we choose the final Mental Institution level for the same reason. Measurements are taken with FRAPS, from the time the game starts loading the level to the start of the cinematic sequence. Since we're measuring load times, the performance metric is time (in msec) - lower is better.
We also perform another additional test for this round up. We made an ISO image of a Company of Heroes DVD, copying it to the first and second drive in a single drive configurations and to the RAID 0 stripe in RAID configuration. We mounted the ISO, installed the game and record the time taken for the game to install itselt to the hard drive. The tests were perform three times, from which an average is computed and used for comparison. By placing the ISO in the same drive (and in the same RAID 0 stripe) as the system, we're testing the I/O performance of the drive, forcing the drive to always switch between reading the ISO and writing the game data. By placing the ISO on the second drive, we are basically testing file copy performance - one drive reads while the another (the system drive) writes. From this test, we can basically see the 'burden' of using RAID 0.
[Previous Page]
[Go to top]
[Next Page]