DroboPro performance

After twelve days of installing new drives, etc. (see my learning experience thread on Migrating drives to Drobo) I finally have green lights everywhere, and dual disk redundancy turned on.

Lat night, I ran some Xbench tests, but the results were quite disappointing. Instead of the 100 MBPS speeds I had seen while copying files, I was seeing anywhere from 5.81MB/sec (4K blocks) to 24.56MB/sec.

Because there is a possibility that the Drobo is or was still digesting its “lunch”, i waited a day, and ran them again.

Tonight I got uncached write speeds of 73.85 MB/s (4K blocks), and 65.00 MB/sec for uncached write speeds for 256K blocks). But on the very next run, I got 9.22 MB/S (4K) and 4.75MP/SEC (56K blocks). A minute or so later, I repeated the same pattern, with the speed dropping by almost a factor of ten:

Results 37.41
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type DROBO DroboPro
Disk Test 37.41
Sequential 48.84
Uncached Write 123.11 75.58 MB/sec [4K blocks]
Uncached Write 120.77 68.33 MB/sec [256K blocks]
Uncached Read 17.60 5.15 MB/sec [4K blocks]
Uncached Read 115.29 57.94 MB/sec [256K blocks]
Random 30.32
Uncached Write 79.88 8.46 MB/sec [4K blocks]
Uncached Write 15.59 4.99 MB/sec [256K blocks]
Uncached Read 34.04 0.24 MB/sec [4K blocks]
Uncached Read 38.65 7.17 MB/sec [256K blocks]

Results 15.13
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type DROBO DroboPro
Disk Test 15.13
Sequential 11.53
Uncached Write 12.93 7.94 MB/sec [4K blocks]
Uncached Write 6.51 3.68 MB/sec [256K blocks]
Uncached Read 14.31 4.19 MB/sec [4K blocks]
Uncached Read 21.61 10.86 MB/sec [256K blocks]
Random 22.02
Uncached Write 44.23 4.68 MB/sec [4K blocks]
Uncached Write 11.78 3.77 MB/sec [256K blocks]
Uncached Read 27.34 0.19 MB/sec [4K blocks]
Uncached Read 26.57 4.93 MB/sec [256K blocks]

Are others seeing this kind of behavior? Does anyone have any idea what is going on?

Hi SuiteB,

When I had my DroboPro hooked up to my Mac Mini running Leopard Server, I reliably got about 35MB/sec for all reads and writes to and from network client computers, using NFS, SMB, and even rsync. When I did a local copy from the Mini to the Pro, I got 70MB/sec writes and 80MB/sec reads. I assumed the slowdown with network protocols was due to traffic from the clients and from the Pro squeezing through the same network interface.

I never saw slowdowns as bad as you’re describing though. Do you have a half-decent switch?

Corndog, the DroboPro is directly attached to the second gigabit Ethernet port on my Mac Pro, so there is no switch involved at all!

There would seem to be three possibilities:

  1. DroboPro hasn’t settled down after a week of re-laying out
  2. Xbench is unstable
  3. DroboPro is unstable, and/or after a burt of activity it is trying to lay out everything again, when it get hits with another set of reads and writes.

When I was first copying a number of files over, I saw performance around 35 MB/S, but then it grew to around 100 MBPS.

I’ll try doing some reads and writes, to see how they compare with Xbench. Maybe Xbench isn’t running long enough.

Are you running with dual-disk redundancy, and how much data and how many disk drives do you have?

Well, I don’t know if this belongs here, but I too am having issues concerning speed with droboPro, and they are quite significant considering that I need to access data constantly. I get good peak read/write around 60-70MB. However these speeds are not seen often. I get regular hangs, where the DroboPro (connected over Ethernet directly to computer) simply refuses to accept or send any data. I started a thread on this if you guys are having similar problems please post. So far nobody form the Drobo Team has responded, although I remember this issue being on the old forum

I think I am experiencing similar issues. I am attempting to do a Time Machine backup of 3tb of data and it has been running for over 5 days and is only about 80% complete. From what I understand, iSCSI should be about to handle about 250gb an hour, so a 3tb transfer should take about 12 hours. I spoke with support and they are asking me to set the iSCSI connection to a manual IP rather than DHCP. I am going to test that today and see if it helps.

SuiteB - DroboPro doesn’t perform well on small block sizes. Make it 128-256K or larger. Here is a review with more information http://www.d3dphotography.com/blog/index.php/2009/07/16/data-robotics-drobopro-review/

corndog - my DroboPro is also connected to a Macmini. Like you, I get about 30-35MB/sec transfers to networked Macs. I think this is due to bus speeds, etc on the Mini. On one test transferring some large movie (avi) files from the Mini’s internal disk the transfer averaged 68 MB/sec. Another time, I mounted the DroboPro iSCSI on a Macbook and hammered it with simultaneous writes from multiple programs. I saturated my Gigabit connection.

hugowren - in your case Time Machine is the limiting factor. It does a lot of work, I only see it transfer data at around 3-4MB/sec to either a Drobo connected via FW800, or to a DroboPro connected via iSCSI/GigE. One of the features I hear coming in Snow Leopard is boosting TIme Machine’s performance by about 2x.

Mark - is there any news on why many of us are experiencing “dips” & “bursts” in transfer speeds?

Exactly, still no answer on the burst copies we are seeing.

I ran Xbench again tonight. The first two times were to test my hardware RAID 0 card, with four 1 TB WD Black SATA drives. The first time was very fast, at 279.48 MB/S, but just to make sure there wasn’t some artifact in the Xbench itself, I ran it again, with even higher speeds – 291.15 MB/s

Then I ran it a couple of times on the DroboPro, with times that began around 75 MB/S, but on subsequent runs ranged from 6.72 MB/s to a new and unprecedented low of only 1.35 MB/S on uncached writes of 4K blocks.


Not quite believing my own eyes, I copied about 8.82 GB from my RAID 0 disk to the DroboPro. I didn’t wait around to see it finish, as I wanted to eat dinner, but it was estimating about 33 minutes to complete, or less than 4 MB/S. That was corroborated by the Activity Monitor, which showed occasional brief spikes to 75 MB/S, and then nothing, and then another brief spike, and so on.

Needless to say, after having spent well over $2000 for the DroboPro plus hard drives, I want some answers!

Here are the Xbench measurements:

Results 334.79
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type APPLE RAID Card
Disk Test 334.79
Sequential 291.26
Uncached Write 474.20 291.15 MB/sec [4K blocks]
Uncached Write 383.30 216.87 MB/sec [256K blocks]
Uncached Read 139.25 40.75 MB/sec [4K blocks]
Uncached Read 545.13 273.98 MB/sec [256K blocks]
Random 393.63
Uncached Write 409.87 43.39 MB/sec [4K blocks]
Uncached Write 296.96 95.07 MB/sec [256K blocks]
Uncached Read 599.85 4.25 MB/sec [4K blocks]
Uncached Read 372.10 69.05 MB/sec [256K blocks]

Results 10.47
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type DROBO DroboPro
Disk Test 10.47
Sequential 6.65
Uncached Write 2.19 1.35 MB/sec [4K blocks]
Uncached Write 19.66 11.12 MB/sec [256K blocks]
Uncached Read 15.51 4.54 MB/sec [4K blocks]
Uncached Read 33.12 16.65 MB/sec [256K blocks]
Random 24.67
Uncached Write 73.62 7.79 MB/sec [4K blocks]
Uncached Write 11.28 3.61 MB/sec [256K blocks]
Uncached Read 33.53 0.24 MB/sec [4K blocks]
Uncached Read 33.24 6.17 MB/sec [256K blocks]

I’ll be happy to make any additional measures or tweaks that anyone thinks is reasonable or helpful, but the current level of performance is unacceptable.

The copying in burst is notorious after the DroboPro fills up with data. When mine was empty it was very fast, now I’m at 10% and I get the bursts all the time. Sometimes it is fast but most of the time not. No pattern.

Same here. And support claims they can’t reproduce it, which smells like denial to me. Reading is always pretty fast for me, but writing ranges from ZERO MBPS to about 50MBPS, with no rhyme or reason to the variations.

I pity anyone who hoped to use their DroboPro for realtime applications like capture or streaming; there’s no way it would work.

For those who are experiencing these problems, I think the following data would be useful. I’ve listed mine in parentheses.

  1. What kind or disk drives, and how many of each are you using? (Four 2TB, four 1TB WD green)
  2. Do you have dual-disk redundancy turned on? (Yes)
  3. How much data do you have (% full)? (2.45 TB, about 1/3 full)
  4. Machine model and OS? (3.2 GHZ 8-core Mac Pro, OS-X 10.5.8, nothing else running)
  5. Interconnection details. DHCP vs. static IP, switch vs. no switch? (DHCP, Drobo Dashboard running in standard user mode, directly connected to the second ethernet port.)
  6. Read speed vs. write speed? (I need to test this further.)
  7. Observed behavior – is there a pattern? (The first Xbench results after power on tends to run very fast – 75 MBPS. The second and subsequent ones fall off dramatically.)
  8. What kind of performance do you see with FW800 or USB, compared to iSCSI?

Of all of these parameters, the read speed vs. write speed for a suitably large file or small set of files (such as several .iso images) might be most revealing.

My concern is that when writing smaller file (which I suspect is what Xbench is using), especially with dual-disk redundancy turned on, DroboPro might not be able to keep up with the directory updates and other housekeeping. But obviously his shouldn’t be an issue when simply reading. Now, I’m not using this to steam audio or video, but others seem to be seeing problems even just reading the data.

Right, I’ll follow SuitB’s guidelines and post my settings. And for the record, those peaks and troughs in data transfer aren’t getting any better. It is just hard to predict when they will start happening.

  1. What kind or disk drives, and how many of each are you using? (8 1TB WD Caviar Green)
  2. Do you have dual-disk redundancy turned on? (Yes)
  3. How much data do you have (% full)? (3.27 TB, 61% full)
  4. Machine model and OS? (2.8GHz Macbook Pro, OS-X 10.5.8)
  5. Interconnection details. DHCP vs. static IP, switch vs. no switch? (using DHCP, directly connected via ethernet.)
  6. Read speed vs. write speed? (the highest I ever measured was 60/70MBs)
  7. Observed behavior – is there a pattern? (The bursts only occur if I transfer data over extended periods of time, so over a minute)
  8. What kind of performance do you see with FW800 or USB, compared to iSCSI? (have not tested this to compare)

Hope this helps, in case anyone from DRI does take a look in this thread.

I was busy trying to install Window 7 on top of VMWare last night, so i wasn’t able to do much testing.

But I did try running Xbench three different times, about 30 minutes apart, and each time I got write speeds for 4K blocks of around 75MBPS.

So it is increasingly obvious that there is some kind of internal housekeeping or other overhead going on, perhaps during but certainly after a write operation. I haven’t any idea what is really going on, but perhaps DroboPro is being just a little too aggressive about optimizing layouts, or something. This is pure speculation, but I wonder if they are writing to two identical tracks in a RAID 1 mirror arrangement (or three identical tracks if dual-disk redundancy is turned on), and them coming back afterwards to rewrite the data in RAID6. There is nothing inherently wrong with such an approach – it wastes a little space, but on a transient basis. However, if they are trying to clean up while other writes are going on, competition for the disk, plus rotational delays, etc., it would cause horrible performance problems. (Gee!)

If that is what they are doing, then some fine tuning of the clean-up algorithm to wait a little more after the write has completed, and to immediately postpone such activities if a new write operation shows up might solve the problem.

Now let me think about the read problem, because some people have reported problem while streaming audio or video.

If my hypothesis is close to correct, a pure read operation should never cause any kind of a hiccup – the data is where it is, and doesn’t need to be moved anywhere.

However, a read operation that is taking place at the same time some other process is writing to the disk certainly would experience some interference. So for those of you who have experienced this, was anything else going on within your system?

If not, then there is still the possibility of the read operation being interfered with by some kind of robotic housekeeping.

(I have this mental image of the Roomba vacuum cleaner firing up while you are trying to listen to a quiet string quartet!)

“More data, Scotty! We need more data!”

Is anyone experiencing this problem when NOT using dual-disk redundancy?

Is anyone experiencing or not experiencing the problem when using FW800 or USB?

Putting aside tools like Xbench, what kind of sustained read speeds, and write speeds, are people getting?

Well, THAT was interesting!

I copied six files from my DroboPro to my desktop (hardware RAID 0 capable of nearly 400 MBPS R/W speeds). The files were Windows 7 ISO images, totaling 8.82 GB, with sizes ranging from 3 GB down to 1.45 GB, plus one 28KB doc file.

The original estimate was 8 minutes, or 1.1 GB/minute. or 18.3 MB/sec, and when the copy first started that was about what Activity Monitor was showing me – peaks of around 21 MBPS, and an occasional spike of 31 MPBS, but a much lower average.

Then, about four minutes into the copy, the speed suddenly shot up to around 90 to 95 MPBS, and stayed there for the rest of the time, finishing the copy in about 5 minutes.

Now, what kind of mechanism or anomaly would cause that, do you suppose? The high speed was expected, and quite believable, but I can’t account for the low starting speed. And the hypothesis I posted in the previous thread doesn’t explain this either, UNLESS the vacuum cleaner happened to be running the room all by itself, just when I tried to read the data.

OK. So let’s repeat the test.

Well, exactly the same thing happened. After about five minutes and 4.8 GB, the performance shot up from around 18 MBPS to over 90 MBPs.

Now, 8.82-4.8 GB = 4.0 GB, but the size of the files being copied were 3GB, 2.33GB, 610.2MB. 1.45GB, 1.45GB, and 23KB. And none of those sizes add up to 4.0GB.

I’m stumped, at least for the moment. Does anyone have any other ideas?

Suite B, I’ve seen that exact pattern of behavior, and reported it in detail to Drobo. As I mentioned, they claim to be unable to duplicate the problem but I’m sceptical.

It is obvious to me that it is non-optimal code in the DroboPro. The way it juggles its tasks, between the actual writing of the data and the time to write the redundant data. And there appears to be some fork in the code which ‘kicks in’ after awhile where the behavior changes and you get normal sustained speeds. This happen too regularly for it it be some random glitch.

Same here!! And it is getting worse. Now even SuperDuper cloning of my internal HD to a partition on the Pro takes longer than a night.

p.S: same thing on firewire!

I tried reading a single enormous file – a 67.78 GB BKF backup file, in 17.0 minutes

The Activity Monitor showed peaks as high as 101 MBPS, but the average transfer rate was an acceptable 66.45 MPBS.

Then I turned around and wrote the same single file back to the DroboPro.

Now it is predicting “about 3 hours”, and the Activity Monitor is showing periodic spikes of 86.88 MBPS, but with extensive periods of activity in the 8 MBPS range (previously it was in the KB range).

Now, 15 minutes later, I am seeing peaks of 95MBPS, but an eyeball average of around 60 MBPS, with lots of peaks and valleys from 10 to 84 MBPS.

39 minutes later, the copy completed, with an average speed of 29 MBPS. I really don’t consider that acceptable for a $1500 device.

Well, consider yourself lucky. My peaks may be around 70 MBps but the trough show zero transfer. I have now switched back to firewire 800 and things are mabye not as fast but consistent.