Just wondering if anyone else here has an R4 Promise Pegasus Thunderbolt RAID to compare speed results. Mine is giving Read rates half as fast as write rates (see attachments)
I'd love to know if this is common, or at least if anyone else has encountered it.
It's setup RAID 5, 4x7200 2 TB drives, no other thunderbolt peripherals and the internal drive is giving around 100MB/s solid read and write. Tested it on a MacBook Air with similar results so it isn't the Mac.
Could it possibly be as simple as the thunderbolt cable?
So just shy of December and I have an update. Promise sent me a replacement Chassis. I swapped the drives, fired it up and at first was very happy to see a read speed of 340MB/s. I thought I was out of the woods!
But then, within a half hour I tested it again. Back to the same old problem. Now I absolutely cannot get it to touch 200MB/s and 160MB/s is average.
What makes this a particular problem is the time it takes to reach 160. It gets there over about 4 seconds pausing first around 20, then 60, then 90, then 120 and tops out at around 160. You can imagine how this impacts the stop-start nature of video editing.
They also sent me a replacement drive unit. The RAID is striped RAID 5 - so I am thinking I could remove drives to see if one of them is causing the bottleneck and if I find one replace it with the new unit.
I'll keep the thread updated.
UPDATE: Just removed one drive and booted. Slightly slower as expected. Shut down and removed second drive replacing first. Now the first shows up as DEAD. Replaced the second drive. Now BOTH DRIVES show up as dead. Raid 5 provides tolerance for one failed drive but not two. I have potentially lost a bunch of data...
UPDATE2: Pegasus phone support was great. They determined the drives were not dead, just registering dead. They forced them back to life using remote login. Never dreamed I'd be so happy to have the problem that started this thread back in my life.
I recommend calling phone support for issues rather than using email support. Their email responses can take days. Hope these updates help someone. I'll keep them coming.
I would be happy to pay the extra to upgrade to an R6 at this point too, but I don't think it's the only solution. These units should definitely be outputting at least 300MB/s. I would recommend you also contact customer support to make sure you get the performance you paid for.
Or perhaps just wait to see how my little adventure pans out first...
I don't have enough spare drives to try replacing them. Promise might agree to send them to me. Thy way it works is they take your credit card details, send you the part and you have to return the faulty part in 30 days.
I can absolutely confirm that there was a performance problem with my R4 unit from the start, although I will never know the cause or how it will be fixed.
In the end I upgraded my unit to an R6 and now my speeds are constantly in the low 500MB/s range - Read and Write - which I am more than happy with.
The promise support was good - especially when I starting calling instead of using email support but the process of discovering and attempting to solve the issue was excruciating. I was sent replacement parts that didn't fix the issue and my computer was accessed remotely for long sessions at a time with no apparent result. In the end the entire process - from the first enquiry - took about 3 months. In the end I had to call the back and forward discussions due to the time and inconvenience it caused me.
The last straw was when a attempted fix corrupted my unit and it had to be formatted right in the middle of a job I was working on costing precious time and the promise team still wanted me to "send through a system report when the drive was reinitialised".
As much as I hate to be one of "those customers" in the end i couldn't take any more delays and uncertainty and insisted on being sent a fresh R6 unit so that even if it was under performing it would at least get me out of the forrest - the read and write speeds are quite a bit faster on the 6 bay units. I paid the retail difference (around $750) and received a refurbished R6.
So far so good.
All I can say is my R4 was definitely under performing. At various times I was told things that just didn't seem right to me, like a 100MB/s difference in read and write was acceptable and that 200MB/s read speed was normal for an R4. In the end they agreed that 300MB/s read or write would be a minimum acceptable speed. In the end it was definitely nothing to do with my system or the chassis and something to do with the drives or software...but what exactly I won't ever know.
I would still recommend the company (they were definitely concerned with the problem) and the product (I love the R4 and R6 when they are doing what they should be doing).
I think my experience was not typical but if you're going to get one of these drives my recommendation is as soon as you get your hands on it run a few speed tests in the first 24-48 hours to make sure you're getting the performance you paid for. Trouble-shooting and resolving it months down the track was not fun.
Hi all, thanks for providing insight into some of the issues that can cause the Pegasus RAID to stumble into extremely poor performance. The speed issue consisted of where my Pegasus (TB1) r6 went from (unsynched) 4-500Mb/sec down to 200Mb/sec all the way to 60 Mb/sec for both read/write. The initial configuration was set to "express" and "video streaming". It seems to me that the stripe/block size caused some of these speed issues in relation to the drive performance. I am unsure if there is or can be a direct relationship between the specifications of drives vs optimal RAID settings. If anyone knows, please share.
I have now backed up everything that was on the r6 and begun some testing in which I have run disk-tests to establish whether there are random or consistent drops across the array. So far, in the 4-drive (out of 6) I am now back to fairly ok speeds of 400-450Mb/sec write and ca 500-550Mb/sec read with different block sizes etc.
Important ot mention is also that I am not using Promise´ compatible drives (according to their list) - but 6TB HGST 7200rpm 128Mb Cache drives (which according to retailer are fully compatible).
I am now picking up 2 more drives to run a 6-drive configuration in Raid5 and will check whether block size does in fact have negative impact - in relation to particular drives.
ohsoweird wrote: ...The speed issue consisted of where my Pegasus (TB1) r6 went from (unsynched) 4-500Mb/sec down to 200Mb/sec all the way to 60 Mb/sec for both read/write. The initial configuration was set to "express" and "video streaming". It seems to me that the stripe/block size caused some of these speed issues in relation to the drive performance. I am unsure if there is or can be a direct relationship between the specifications of drives vs optimal RAID settings. If anyone knows, please share...
I did a lot of performance testing on the TB1 R4 using 4x2GB Toshiba DT01ACA2 drives in RAID-5. I mainly had problems with very slow formatting (ie RAID-5 initialization), which was due to using the (then) default of 128K byte stripe size. See test results:
I did some more limited testing of I/O performance vs stripe size but I don't have those results readily available. In general it was not highly sensitive to that. You normally want the average I/O size of your main workload to be close to the stripe size. For typical video editing applications, the software usually does a fairly large I/O, around 256KB to 1MB, so any stripe size in that zone should be OK.
You can very roughly approximate the I/O size of a given workload by using Activity Monitor, then dividing bytes per sec by IO per sec.
I don't remember what stripe size the Promise utility picks if you use the "video streaming" default but it's probably 512KB or 1MB. Either should be OK for video editing but I have not recently checked the FCPX I/O size under load.
If your I/O rate drops to 60MB/sec that is probably some other issue. Maybe the chassis or a failed drive which kicked the array into rebuild mode, but it should normally indicate that with a front panel light. Also the Promise Utility should accurately indicate what state the array is in.