Should it be this slow, this early?

I understand that the Drobo has an idiotic mechanism that intentionally throttles performance when you are at 95% capacity. This is fairly stupid, since I want to fill my drive to capacity and then use it as READ-ONLY and while I may be moving some content off and replacing it with other content every great once in awhile, it will not be “added to indefinitely”. Just filled to capacity and then read from (streaming to other devices).

Fairly ridiculous that this isn’t taken into account with Drobo’s “calculator”, since on a regular Drobo packed with 2tb drives, that reduces (needlessly) your storage by another 300gb. Not for any practical purpose other than “well, YOU might not be stupid enough to just keep dumping data on here forever, but OTHER people might”.

Anyway, via Firewire 800, I was getting

  • Up to about 50% full, I got 30MB/s.
  • After the Drobo reached 50% full, I was getting around 20MB/s.
  • At 66% full, I’m getting 10.8MB/s

So, why is the performance degrading so horribly, already?

If I’m only getting 10.8MB/s at 66% full, how miserable is the slow-down at 80% or 90% or 95%?

Can I expect read-access to be this terrible? Does the throttling at 95% only apply to writing or is it reading, too? (And if it’s reading as well, WHY? I’m not ADDING data to it – I’m just READING from it and there’s no point in throttling that, even for the sake of an “idiot light” function).

I know this isn’t true RAID and that RAID can see certain performance degradation itself in certain circumstances, but those circumstances are not with 4x2tb drives at 50% capacity.

At these speeds, the Drobo boarders on becoming useless. I have 1.7tb still free (well, 1.4tb when you account for the 95% “idiot light” factor) and while the first 3.7tb took about 21 hours to copy over, I’m looking at another 40 hours to do 1.4tb. Assuming the speed doesn’t get worse (which it will – it’s now at 10.4MB/s).

The drives should not be overheating and there are no other significant concerns in the deployment environment. Using 2tb WD *EARS drives that Drobo uses and advises via FW800 on OSX via a machine that is not otherwise being touched and initially performed at 30MB/s with this Drobo 21 hours ago.

if you have just added a lot of data to it, it may be slower while it does internally optimisations/housekeeping

always let it “rest” for 24 hours before benchmarking

it wont start to slow down (intentionally) until it is almost full, not at two thirds

its only writing which slows down, reading it will still go as fast as possible

I’ve been moving data to the Drobo nearly non-stop, since putting it into service and the first slowdown (from 30MB->20MB did not occur until near the 50% mark (2-2.5tb of data) and the second slowdown (from 20MB->10MB) until the 66% mark (3tb-3.5tb).

Is there any sort of formula to be applied to the size of data it can accept at a time and/or the amount of time the device requires for optimization, before performance can be restored? Microsoft-style, there is little to no end-user diagnostics available, other than the drive lights and the color codes. Is there anything provided that I’m just not aware of that can be used to identify when the device is performing some sort of maintenance or optimization and when it should be free to use, unhindered, again? Activity indicators or something?

The dumbed-down presentation for everyone is slick and simplistic and nice, but it would be fantastic just to have a little more useful data if one wanted it (and since the IO is occurring entirely inside the device – other than when it is being copied to or read from by the computer – there’s not much I can seem to be able to do to monitor it outside of the limited Dashboard tool it comes with).

Thanks, again.

nothing im afriad

your first slowdown would most likely have been from switching from mirrored redundancy to parity based redundancy

but no, there is no indication , it is both literally and figuratively, a black box

Docchris already addressed your main point, but there’s a feature request on the slowdown at near-capacity thing, please chime in for more demand. :slight_smile:

Do you mean to imply that when the data on the device is less than one drive’s worth, it mirrors it to another drive and once you’ve exceeded one drive’s worth, it switches to parity mode? If so, I was not aware of that. I can see the benefit for additional redundancy early on in a device’s use, but it would seem once you cross that threshold, the work to switch into parity requires significant processor utilization (and IO). If I understand that correctly, it sounds like a very questionable trade off.

Or I just read too much into your comment. :slight_smile:

i think that is how it works, from comments dri employees have made previously (on the old forums) for speed and simplicty, if it has space (i.e.is less than 50% full) it just mirrors it

however, as is the point of this discussion, who really knows what its doing :stuck_out_tongue:

http://en.wikipedia.org/wiki/Drobo is a good place to get specs on the Beyond Raid. Also includes links to the Patent.

I like the device, but find the lack of user-end diagnostic capabilities to be so cumbersome. I come from an industry (and a company) that strikes to empower customers as much as possible. They don’t even have to provide me with tools to manipulate the device, but something to see what is actually going on would be dandy. That the diagnostics are encrypted is even more baffling. I can’t imagine what proprietary data is available in a diagnostic file that would be so concerning. They may as well have the fear that someone will see a few routine names in a stack trace and suddenly extrapolate some uber internal secret.

Then again, the more you keep the user in the dark, the more they have to rely on extended costly support contracts. :)[hr]


[quote=“Cronjob, post:1, topic:1633”]Anyway, via Firewire 800, I was getting

  • Up to about 50% full, I got 30MB/s.
  • After the Drobo reached 50% full, I was getting around 20MB/s.
  • At 66% full, I’m getting 10.8MB/s[/quote]
    Unfortunately, you are not alone in that case.
    Assuming we are using the same AJA Kona System Test, with the same set of parameters, the numbers I reported in that thread for my Drobo-V2 are similar to yours, dropping to around 15MB/s at 62% usage.
    Furthermore, those numbers were highly unstable, from 1 frame to the next and from 1 AKST test to the next; they could get as low as 10-13MB/s on some test runs.
    Timon Royer’s blog also reports similar results on its Drobo-V2.
    What is curiouser is that he does not see a similar behavior with his Drobo-FS, at least up to 40% usage. But this may be because the network is the bottleneck for the Drobo-FS, and thus early internal Drobo-FS slow down is masked by network sluggishness.

If that is confirmed by Data Robotics as anything else than a bug (I am still waiting for the response to my support case), then it becomes a dire problem.
Starting from low performance numbers and having them divided by 2, 3 or more above 50% usage would basically make a reasonably filled Drobo unsuitable for many tasks, including HD video playback.

BTW, the extreme slow down at 95% usage did not seem so bad to me, assuming it was only a warning mechanism related to the thin provisioning (and not the unwanted consequence of the Beyond Raid algorithms); otherwise, since the host OS “believes” the Drobo is much bigger than in reality, it would have no other option than generating an I/O fatal error when exceeding the actual capacity.
But I do agree that the early 85% slowdown is much more questionable, especially when you use your Drobo as read-only after initial upload. That one should be a user overridable parameter in DroboDashboard, assuming again it is not some unavoidable property of Beyond Raid.

Drobo can easily playback HD video, even a full Blu-ray stream never gets above 6MB/sec

i used my drobo v1 as a blu-ray library without issue, and my V2, and now my 'pro

Unless you’re talking about HD video streams in the context of video editing… But Drobo generally is not good for video editing, especially since it slows down when there is a lot of simultaneous access.

Most video editing software packages require the editing to be done on an internal hard drive. I do know FCP (final cut pro) will work on the Elite with no issues.

All comes down to bandwidth in the end.
DV and HDV are trivial (25 Mbps or 3.125 MB/sec per stream).
DVCPRO HD is 100 Mbps (12.5 MB/sec)
Other formats can exceed 200 Mbps (25 MB/sec)
and uncompressed HD is simply evil.

The AJA benchmark will give good estimates, as it’s a video editing benchmark to begin with. :slight_smile:

We use DroboPro at work for light (2-3 streams, mainly cuts only) video editing and it’s fine. But for heavy-duty stuff we move to internal RAID0, then output and archive to DroboPro.