Your right, I did use the sequential. Right now the drive is syncing, as I set it up differently (2 partitions). Let me know what test your thinking I should run, and I'll gladly post those numbers.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Pegasus2 - is this too slow?
- Thread starter joker00
- Start date
- Sort by reaction score
Your right, I did use the sequential. Right now the drive is syncing, as I set it up differently (2 partitions). Let me know what test your thinking I should run, and I'll gladly post those numbers.
Here are my P1 R4 (4 x 2TB RAID 5) results using DiskTester's "Sequential Test" with Spotlight=Off and ForceReadAhead=ON:
Iteration Write MB/sec Read MB/sec
1 572 416
2 408 413
3 594 408
4 501 495
5 584 425
Slowest 408 408
Fastest 594 495
So our numbers aren't that far apart. Note in this case I first used the "Fill Volume" command to consume 1.2TB (4.73TB available). It appears there might be a bug in DiskTester that causes a hang if running Sequential Test on an empty volume > 5TB, but I'm not sure.
Let me think about it and I'll post more tomorrow.
In general I recommend using 512KB stripe size for photo/video files. Your average file size is large. I examined the average I/O size of Adobe Lightroom, and it's around 256-512KB. During a FCP X render, reads predominate over writes by 7:1, and average I/O size is about 120 kilobytes. However it takes forever to sync a P4 RAID5 array at 128 kb, so at a minimum I suggest 256 KB and 512 KB is better.
Iteration Write MB/sec Read MB/sec
1 572 416
2 408 413
3 594 408
4 501 495
5 584 425
Slowest 408 408
Fastest 594 495
So our numbers aren't that far apart. Note in this case I first used the "Fill Volume" command to consume 1.2TB (4.73TB available). It appears there might be a bug in DiskTester that causes a hang if running Sequential Test on an empty volume > 5TB, but I'm not sure.
Let me think about it and I'll post more tomorrow.
In general I recommend using 512KB stripe size for photo/video files. Your average file size is large. I examined the average I/O size of Adobe Lightroom, and it's around 256-512KB. During a FCP X render, reads predominate over writes by 7:1, and average I/O size is about 120 kilobytes. However it takes forever to sync a P4 RAID5 array at 128 kb, so at a minimum I suggest 256 KB and 512 KB is better.
When I set mine up I ended up going with a 1mb stripe size. Would you generally recommend going smaller? The 1mb was totally arbitrary. It's seemed to be the default when I went through the express setup in the promise utility.
It really depends on what your I/O pattern is for the most important (or most common) cases. You can crudely approximate this by running those tasks while watching Activity Monitor. In Activity Monitor select "Disk" and divide "Data read/sec" by "Reads in/sec". E.g, 100 megabytes/sec divided by 100 reads/sec = 1 megabyte I/O size. It fluctuates a lot -- you just want a rough number. Ditto for writes, but typically reads predominate so are more important.
You can also do the same for "data read" divided by "reads in", which is the total amount since last reboot. However unless you rebooted right before the test, you don't know how much of that cumulative activity was important.
This is very rough, and the optimal stripe size for one I/O pattern will be sub-optimal for others.
In general I think 1MB is a little high, but that's based on my software tasks. On my P4, the Promise Utility "wizard" defaulted to 128KB stripe size, which was too small, IMO. That was the prior version of Promise Utility. I told them it was too small, and suggested 256KB or 512KB as the default. I haven't re-synced using the latest version; maybe they changed it to 1MB?
Nowadays still image and video files are very large -- a single raw photo from a DSLR can be 60 megabytes. However the key issue what I/O size for your software uses. Also what activities are most time-consuming and I/O-bound. That varies with your workflow. E.g. many activities are already CPU-limited, not I/O-limited. Further improving I/O won't help in those cases.
You have 4x3TB in RAID 5, and read rate can't go any faster than the sum of three drives (4th is parity). If the max sustainable single-drive read rate is, say, 190 MB/sec, then your theoretical max would be around 3x that, or 570 MB/sec. The 190 MB/sec/drive is just a guess based on other single-drive read-oriented benchmarks I've seen on other platforms.
Your fastest reads are already 462/570 or 81% of that. The difference could be overhead in the OS, in the controller, or maybe the I/O pattern is not perfectly optimal for extracting max drive performance.
It's amazingly fast on writes, considering RAID5 typically entails a major write penalty. I have no idea how they got writes to be that fast.
I don't think Thunderbolt2 is a factor here, since Thunderbolt1 is already faster than these RAID chassis. However T2 gives you more flexibility regarding drive expansion and 4k displays.
DiskTester allows more fine-grained control of certain tests if run from the command line. Let me play around with that and see if I can devise a better test scenario...
I"m pretty sure that's all about the write cache. It's really fast if you use write back but the write performance tanks if you set it to write through or disable the cache entirely.
I was experimenting with those options and disabled the cache when I went to do my initial transfer and it took a ridiculously long time to copy the data. When I re-enabled it the speed went through the roof by comparison.