Speed - 43MB/s max

I have a Drobo S currently attached via FW800 to my MacBook Pro (Unibody). When transferring data between a LaCie Rugged 500GB disk and the internal hdd of the MBP (a 500GB WD blue) i get around 50MB/s.
With Drobo S it is a measly 42MB/s with peak up to 43.5. This is as you might imagine a bit frustrating since i hoped for the increased speed promised by Drobo S over Drobo FW800.
In my Drobo S i currently have three drives: one Samsung 1TB F1 and two Seagate Barracuda LP 2TB.

Any suggestions/advice?



mine is as fast as my 4 year old iomega NAS drive. . . . . . . .

I did think the drobo S would be fast, I read 80mb/s ?

mabe a update will fix it?

On your Drobo S, dual-disk redundancy (DDR) or single-disk? Seems you’d be using SDR, but I’ve learned not to assume. :slight_smile:

Running in SDR. Latest Mac OS X (10.6.2) an latest DD and firmware revisions.

Drobo is not a RAID 0.
It is thus perfectly normal that it is not faster than an external FW800 or USB2 disk.
Furthermore, parity calculation and control will make it slower than the slowest disk in your Drobo-S.
Sorry to disappoint you, but the 42MB/s you get out of your Drobo-S could be considered as an excellent figure by previous Drobo (non S) users…

It’s kind of like the whole move toward having more, though not necessarily faster, cores in CPUs…

Splitting the workload is good and speeds things up to an extent, but managing it does take work.

Think of building a house. A single person might be able to manage 20 workers. But imagine if you had 100 workers… you’ll need more management help.

That is not quite true. The data you are writing out is spread over multiple hard disks. When you write out data it probably waits for the slowest drive to finish, but you are only writing a fraction of the data to that particular drive. Also when using drives of different sizes the slowest drive is also the smallest and so will be used the least.

Unfortunately, the disk access time has 3 components, and the 2 biggest ones are independent of the data transfer length :

  • seek time (the arm moves to the proper cylinder)
  • latency time (1/2 rotation)
  • transfer time (the bytes transfer)

Smaller blocks to read or write mean less transfer time, but typically it is less than 30% of total. Sequential long blocks transfers DO increase disk and Drobo transfer rate, but the spread on multiple disks and length reduction is not enough to decrease the degradation due to spreading (non-synchronized disks => longer latency) and software parity computation.
And disk buffers are flushed by long sequential transfers, so their acceleration is minimal in that case.

Try adding more drives. Get rid of that samsung, I’ve only heard bad stories about their drives.

i had 3 1.5tb samsungs in my 'pro for a while, and they worked perfectly.

i used to have a f1 (samsung) in my desktop for a while and it was VERY fast.

overall ive only ever been impressed by their drives

funny how experiences vary.

the one thing that would be ideally sped up on mine would be the access time for itunes, 3-5 seconds waiting to play a track is looking like my drobo s will be on ebay soon.

for everything else its fine but my 3.5tb music library, the only reason i bought the drobo, its not really very good at all.

if datarobotics can speed this up ill be happy cos for everything else its fine, fast, no probs, just wished my music wouldnt sit for a few seconds to think about playing the track . . . . .

ohh all my drives are 7200, gigabit ethernet using a 3com 24port managed switch, rackmount jobbie no expense spared it was perfect before i moved it all to the drobo (was on internal drives in my sept 09 8 core 16gb mac pro)

thats really stranger, i wonder what is slowing it down

i would suspect itunes does multiple accesses when working out where the track is located (reading from your itunes DB then etc etc)

and unfortunately multiple read is what drobos are a bit sucky at.

Spared no expense… except for the Drobo?
Given the rest of your equipment, I’m wondering what your initial “requirements spec” were, that’s all. :slight_smile:

Also, how long has it been since you loaded/formatted your Drobo? Given that you have 3.5TB of music, it might still be balancing the data.

that was my other thought, with a setup like that, why not get the 'pro (which would go nicely in the rackmount)

Just setup my Drobo S with eSATA and I’m getting between 45-80 MB/s.

I’m copying from a local SATA drive to the Drobo S which I have 5 drives (2TB, and 4 500GB) which all are at 7200RPMs. I’m just using rsync --progress to get my results. But doing large ISO disk images I average 70MB/s or so. Doing other types of files I’ve seen it go from 45-80. But anything that takes more than a couple seconds seem to go around 70MBs.

I’m using ext3 with a 8TB LUN. I’m trying to fill up past 2TB to see if I get any of those slow down type problems or if I have any problems deleting. But right now things are about as fast as my local SATA drives for copying and moving things.

Thats pretty impressive compared to the 2nd Gen 4-Bay Drobo.

Are the speeds the same for both read and for write?

I’m not sure what the read speed is, but that’s what I’m getting for write speed. I’m not quite sure how to test read speed. Guess I’ll need to download some disk I/O tools. Know of any good ones?

I did a speed test on Linux that shows pretty good results. Here you go:

Unit information

File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load

Sequential Reads
Identifier FileSize BlkSize NumThr Rate (CPU) AvgLat MaxLat

2.6.31-16-generic-pae 1778 4096 1 88.85 6.956% 0.044 1039.58 0.00000 0.00000 1277
2.6.31-16-generic-pae 1778 4096 2 ###### 399.2% 0.004 0.23 0.00000 0.00000 517
2.6.31-16-generic-pae 1778 4096 4 441.41 247.3% 0.024 1979.86 0.00000 0.00000 178
2.6.31-16-generic-pae 1778 4096 8 220.50 225.4% 0.069 3927.04 0.00154 0.00000 98

Random Reads
Identifier FileSize BlkSize NumThr Rate (CPU) AvgLat MaxLat

2.6.31-16-generic-pae 1778 4096 1 ###### 97.40% 0.003 0.01 0.00000 0.00000 1302
2.6.31-16-generic-pae 1778 4096 2 ###### 226.3% 0.003 0.01 0.00000 0.00000 977
2.6.31-16-generic-pae 1778 4096 4 ###### 1144.% 0.005 0.03 0.00000 0.00000 244
2.6.31-16-generic-pae 1778 4096 8 ###### -66.2% 0.004 0.02 0.00000 0.00000 -1953

Sequential Writes
Identifier FileSize BlkSize NumThr Rate (CPU) AvgLat MaxLat

2.6.31-16-generic-pae 1778 4096 1 38.74 8.698% 0.094 1638.72 0.00000 0.00000 445
2.6.31-16-generic-pae 1778 4096 2 35.93 22.22% 0.205 1674.82 0.00000 0.00000 162
2.6.31-16-generic-pae 1778 4096 4 24.97 49.06% 0.583 6019.41 0.00792 0.00000 51
2.6.31-16-generic-pae 1778 4096 8 25.91 112.9% 1.129 4749.09 0.01364 0.00000 23

Random Writes
Identifier FileSize BlkSize NumThr Rate (CPU) AvgLat MaxLat

2.6.31-16-generic-pae 1778 4096 1 2.50 0.575% 0.004 0.03 0.00000 0.00000 434
2.6.31-16-generic-pae 1778 4096 2 2.23 1.143% 0.005 0.03 0.00000 0.00000 195
2.6.31-16-generic-pae 1778 4096 4 2.06 2.264% 0.008 0.40 0.00000 0.00000 91
2.6.31-16-generic-pae 1778 4096 8 2.38 4.684% 0.010 4.20 0.00000 0.00000 51

Try a simple file copy using dd. The example below reads a file off the drobo and writes it out to /dev/null (nowhere).

dd if=/mnt/Drobo/somefile of=/dev/null bs=512k

Should print out a speed at the end.

Becarefu using dd. The blocksize, bs=512k, has a HUGE impact on results. On my DroboPro, I “dd-ed” a file to /dev/null with bs=512k, it copied at 70.8MB/sec. Setting bs=1024k resulted in 90.9MB/sec, i.e. 30% faster.