Category Archives: Hardware

Drobo (3rd gen) to Drobo 5C, part 2

Leave a reply

This is part of a multi-part review of the Data Robotics Drobo 5C.

Drobo (3rd gen) to Drobo 5C review

Leave a reply

My other site, Appleause, will be posting a multi-part review of the recently released 5-bay Drobo 5C:

Drobo (3rd gen) to Drobo 5C, introduction

Drobo (3rd gen) to Drobo 5C, part 1

2 Replies

This is part of a multi-part review of the Data Robotics Drobo 5C.

Drobo (3rd gen) to Drobo 5C, introduction

4 Replies

My long history with external hard drives was covered in an earlier article, so I will just summarize:

I’ve gone through a bunch of hard drives and external enclosures since 1999.

Last year I shared a multi-part series about migrating from a 2nd generation Drobo to the newer 3rd generation models. The 3rd generation version solved most of the performance issues, especially when it came to the time it took to rebuild after replacing a drive. It also added a very important capability: Dual Disk Redundancy

See: What is Dual Disk Redundancy?

This is very important because, without it, when (not if!) a drive fails, during the time it takes to rebuild on to a new drive, any other drive failure will cause loss of data. With drives becoming larger and larger (I upgraded mine, rebuild time also increases. If you buy multiple drives at the same time, you increase the likelihood of getting multiple units that have the same flaw from a bad production run, which increases the odds of a multi-drive failure.

It may seem unlikely, but from reading many articles about RAID systems over the years, it’s far more common that I would have thought.

I have worked around this over the years by always having multiple drives and backing up my important data between them. Thus, on my two Drobos, I have my most important data copied to each unit. This way, even if a Drobo completely died on me, I still have my data on the other one. (It’s also good to have backup hardware in case of a failure. I can swap my drives to the still-working unit and get to anything I need while I wait for the failed unit to be repaired/replaced.)

Of course, this doubles the hardware cost…

With Dual Disk Redundancy, you can set up a Drobo to protect data in a much better way. Normally, every bit of data exists on two drives/ if one drive fails, there is always a another copy. With Dual Disk Redundancy, the data will exist on three drives, so if two fail, you still have a copy.

The problem is … you lose storage space. A 4-bay Drobo filled with four 3 TB drives gives you 8.17 TB of storage for data. If you enable Dual Disk Redundancy, it drops to only having 5.44 TB available. You can see this at the Drobo Capacity Calculator:

http://www.drobo.com/storage-products/capacity-calculator/

When the 3rd generation Drobo came out, they added Dual Disk Redundancy support, but if you were migrating from an earlier 4-bay unit, you could not make use of it unless you had enough free space available.

At some point, Drobo also started making 5-bay units,. This allowed you to have as much storage as a 4-bay offered WITH Dual Disk Redundancy enabled.

The problem is, those 5-bay units were expensive! A 3rd generation 4-bay Drobo sold for $299 or so, while a 5-bay direct-attached drive was $699! That’s quite the premium just to get one extra drive bay.

This changed last October when Drobo announced the new Drobo 5C.

http://www.drobo.com/news/press-releases/drobo-releases-worlds-first-self-managing-usb-c-storage-solution/

At $349, it’s a much better value. It ONLY has a USB-C port, and comes with a cable to plug that in to a USB 2.0/3.0 port on your PC/Mac, so if you preferred Thunderbolt, SATA or FireWire, you are out of luck.

I will soon be receiving a unit to review, and will begin a multi-part article about migrating from a 4-bay Drobo to the new 5-bay 5C model.

More to come…

iCade Mobile controller for $5 on Amazon

Leave a reply

I just used some points I earned on Swagbucks to order a discontinued iCade Mobile controller for less than $5 (with Amazon Prime shipping). Currently, the price has gone up to $9, but either way, it’s a deal if you want an iCade circuit to mess with:

Yes. It's pink. Pink was cheaper. — Yes. It’s pink. Pink was cheaper.

iCade Game Controller (Pink) – Amazon link

I chose the pink one because it was a buck less than the other color. Of course, now it’s going to seem mean to dissect something that “cute.”

The iCade devices, which I have written about before, started out as an April Fool’s joke at Think Geek in 2010. They act like a Bluetooth (or USB) keyboard and some games were written to interpret certain key presses as joystick buttons. Ever since iOS 7, Apple has added official support for game pads so the iCade format is pretty much dead. Still, there are a ton of old apps (over 100) that still support iCade (including Atari’s Greatest Hits and a few other retro emulators).

I plan to dissect mine and use it inside a cheap arcade-style joystick I have, thus allowing me to have something like a Tankstick for iOS (for games that support it), without having to spend any money. I am especially interested in using it for Pinball Arcade and plan to add some buttons on the sides to act as flipper buttons.

I just thought I’d share this, since it’s cheaper to buy this and gut it than to get a cheap Arduino Leonardo type device to hook up via USB adapter cables like my Atari joystick project.

If you get one and hack it in to something, let me know. I’d love to see what you come up with.

P.S. Since 4/15/2014, I have earned over $1419 in Amazon gift cards (and PayPal cash)! Sign up using my link and I get credit: http://swagbucks.com/refer/allenhuffman (Ask me for the tip/howto doc.)

sizeof() matters

3 Replies

Updates:

2016/02/29 – Per a comment by James, I corrected my statement that sizeof() is a macro. It is not. It is a keyword. My bad.

In C, the sizeof() macro can be used to determine the size of a variable type or structure. For instance, if you need to know the size of an “int” on your system, you can use sizeof(int). If you have a variable like “int i;” or “long i;”, you can also use sizeof(i).

On the Arduino, an int is 16-bits:


void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
Serial.print("sizeof(int) is ");
Serial.println(sizeof(int));
}

void loop() {
// put your main code here, to run repeatedly:
}

On the Arduino, that produces:

sizeof(int) is 2

On a Windows system, an int is 32-bits:


int main()
{
printf("sizeof(int) is %dn", sizeof(int));

return EXIT_SUCCESS;
}

That displays:

sizeof(int) is 4

Note: sizeof() is not a library function. It is a ~~macro~~ C keyword that is handled by the C preprocessor during compile time. It will be replaced with the number representing the size the same way a #define replaces the define in the source code. At least, I think that’s what it does.

You should avoid making any assumptions about the size of data types beyond what the C standard tells you. For example, an “int” should be “at least 16-bit”. Thus, even a PC compiler could have chosen to make an “int” be 16-bits instead of 32.

A better way to use data types was added in the C99 specification, where you can include stdint.h and then request specific types of variables:


uint8_t unsignedByte;

uint16_t unsignedWord;

int32_t signed32bit;

But I digress.

The point of this article was to mention that you can also use sizeof() on strings IF they are known to the compiler at compile time. You can, of course, get the size of a pointer:


char *ptr;

printf("sizeof(ptr) is %dn", sizeof(ptr));

Depending on the size of a pointer on your system (16-bits on the Arduino, 32 on the PC), you will get back 2 or 4 (or 8 if it’s a 64-bit pointer, I suppose).

And the pointer is still the same size regardless of what it points to. You still get the same size even if you had something like this:


char *msgPtr = "This is my message.";

printf("sizeof(msgPtr) is %dn", sizeof(msgPtr));

But, if you had declared that string as an array of characters, rather than a pointer to a character, you get something different because the compiler knows a bit about what you are pointing to:


char msgArray[] = "This is my message.";

printf("sizeof(msgArray) is %dn", sizeof(msgArray));

There, you see the compiler actually substitutes the size of the array of characters:

sizeof(msgArray) is 20

This is an instance where using “char *ptr =” is different than “char ptr[] = ” even though, ultimately, they both are pointers to some memory location where those characters exist.

At work, I ran across a bunch of test code that did this:


const char    PROMPT[] = "Shell: ";
const uint8_t PROMPT_LEN = 7;

const char    LOGIN[] = "Login: ";
const uint8_t LOGIN_LEN = 7;

Those strings would be used elsewhere, and the length needed to be known by some write()-type function. Counting bytes in a quotes string and keeping that number updated sounds like work, so instead they could have used the sizeof() macro. Since it returns the size of the array (including the NIL zero byte at the end), they’d need to subtract one like this:


const char    PROMPT[] = "Shell: ";
const uint8_t PROMPT_LEN = sizeof(PROMPT)-1;

const char    LOGIN[] = "Login: ";
const uint8_t LOGIN_LEN = sizeof(LOGIN)-1;

At compile time, the size of the character array is known, and the compiler substitutes that length where the “sizeof()” macro is. If the string is changed, that value also changes (at compile time).

Of course, since we are using NIL terminated strings, you could also just use the strlen() function. But, that is more for strings of unknown length, and it runs code that counts every character until the NIL zero, which is wasted CPU use and code space if you don’t actually need to do that.

My optimization tip for today is: If you are using hard coded constant strings, and you need to know the size of them, declare them as C arrays (not a pointer to the string) and use the sizeof() macro as a constant. Use strlen() only for times when the compiler cannot know the size of the character array (dynamic strings or things being passed in to a function from the outside).

Speaking of that … as long as the compiler can “see” where the array is declared, sizeof() will work. But if you had something like this:


void showSize(char *ptr)
{
printf("showSize - sizeof(ptr) = %dn", sizeof(ptr));
}

int main()
{
const char    LOGIN[] = "Login: ";

showSize(LOGIN);

return EXIT_SUCCESS;
}

…that will not work. By the time you pass in just a “pointer to” the array, all the compiler sees (inside that showSize function) is a pointer, and thus can only tell you the size of the pointer, and not what it points to.

As you see, this tip is of limited use, but I think it is still neat and a potential way to save some CPU cycles and program space bytes from time to time. Since I have worked on a number of Arduino Sketches that have gotten too big to fit (also on some TI MSP430 projects), small tricks like this can make a very big difference in getting something to fit or not fit.

sizeof() can matter :-)

C strcat, strcpy and armageddon, part 3

3 Replies

See also: part 1, part 2, part 3, part 4, part 5 and part 6.

Previously, I discussed a way to make string copies safer by using strncpy(). I mentioned there would be a bit of extra overhead and I’d like to discuss that. This made me wonder: how much overhead? I decided to try and find out.

First, I created a very simple test program that copied a string using strcpy(), or strncpy() (with the extra null added).

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define BUFSIZE 20

//#define SMALL

int main()
{
    char buffer[BUFSIZE];

#ifdef SMALL
    // Smaller and faster, but less safe.
    strcpy(buffer, "Hello");
#else
    // Larger and slower, but more safe.
    strncpy(buffer, "Hello", BUFSIZE-1);
    buffer[BUFSIZE-1] = '\0';
#endif

    // If you don't use 'buffer', it may be optimized out.
    puts(buffer);

    return EXIT_SUCCESS;
}

Since I am lazy, I didn’t want to make two separate test programs. Instead, I used a #define to conditionally compile which version of the string copy code I would use.

When I built this using GCC for Windows (using the excellent Code::Blocks editor/IDE), I found that each version produced a .exe that was 17920 bytes. I expect the code size difference might start showing up after using a bunch of these calls, so this test program was not good on a Windows compiler.

Instead, I turned to the Arduino IDE (currently version 1.6.7). It still uses GCC, but since it targets a smaller 16-bit AVR processor, it creates much smaller code and lets me see size differences easier. I modified the code to run inside the setup() function of an Arduino sketch:

#define BUFSIZE 10
#define SMALL

void setup() {
    // volatile to prevent optimizer from removing it.
    volatile char buffer[BUFSIZE];

#ifdef SMALL
    // Smaller and faster, but less safe.
    strcpy((char)buffer, "Hello");
#else
    // Larger and slower, but more safe.
    strncpy((char)buffer, "Hello", BUFSIZE-1);
    buffer[BUFSIZE-1] = '\0';
#endif
}

void loop() {
    // put your main code here, to run repeatedly:
}

Then I selected Sketch Verify/Compile (Ctrl-R, or the checkmark button). Here are the results:

SMALL (strcpy) – 540 bytes
LARGE (strncpy) – 562 bytes

It seems moving from strcpy() to strncpy() would add only 22 extra bytes to my sketch. (Without the “buffer[BUFSIZE-1] = ”;” line, it was 560 bytes.)

Now, this does not mean that every use of strncpy() is going to add 20 bytes to your program. When the compiler links in that library code, only one copy of the strncpy() function will exist, so this is more of a “one time” penalty. To better demonstrate this, I created a program that would always link in both strcpy() and strncpy() so I could then test the overhead of the actual call:

#define BUFSIZE 10
#define SMALL

void setup() {
    // volatile to prevent optimizer from removing it.
    volatile char buffer[BUFSIZE];

    // For inclusion of both strcpy() and strncpy()
    strcpy((char)buffer, "Test");
    strncpy((char)buffer, "Test", BUFSIZE);

#ifdef SMALL
    // Smaller and faster, but less safe.
    strcpy((char)buffer, "Hello");
#else
    // Larger and slower, but more safe.
    strncpy((char)buffer, "Hello", BUFSIZE-1);
    //buffer[BUFSIZE-1] = '\0';
#endif
}

void loop() {
    // put your main code here, to run repeatedly:
}

Now, with both calls used (and trying to make sure the optimizer didn’t remove them), the sketch compiles to 604 bytes for SMALL, or 610 bytes for the larger strncpy() version. (Again, without the “buffer[BUFSIZE-1] = ”;” line it would be 608 bytes.)

Conclusions:

The strncpy() library function is larger than strcpy(). On this Arduino, it appeared to add 20 bytes to the program size. This is a one-time cost just to include that library function.
Making a call to strncpy() is larger than a call to strcpy() because it has to deal with an extra parameter. On this Arduino, each use would be 4 bytes larger.
Adding the null obviously adds extra code. On this Arduino, that seems to be 2 bytes. (The optimizer is probably doing something. Surely it takes more than two bytes to store a 0 in a buffer at an offset.)

Since the overhead of each use is only a few bytes, there’s not much of an impact to switch to doing string copies this safer way. (Assuming you can spare the extra 20 bytes to include the library function.)

Now we have a general idea about code space overhead, but what about CPU overhead? strncpy() should be slower since it is doing more work during the copy (checking for the max number of characters to copy, and possibly padding with null bytes).

To test this, I once again used the Arduino and it’s timing function, millis(). I created a sample program that would do 100,000 string copies and then print how long it took.

#define BUFSIZE 10
//#define SMALL

void setup() {
    // volatile to prevent optimizer from removing it.
    volatile char buffer[BUFSIZE];
    unsigned long startTime, endTime;

    Serial.begin(115200); // So we can print stuff.

    // For inclusion of both strcpy() and strncpy()
    strcpy((char)buffer, "Test");
    strncpy((char)buffer, "Test", BUFSIZE);

    // Let's do this a bunch of times to test.
    startTime = millis();

    Serial.print("Start time: ");
    Serial.println(startTime);

    for (unsigned long i = 0; i < 100000; i++)
    {
#ifdef SMALL
        // Smaller and faster, but less safe.
        strcpy((char)buffer, "Hello");
#else
        // Larger and slower, but more safe.
        strncpy((char)buffer, "Hello", BUFSIZE - 1);
        buffer[BUFSIZE - 1] = '\0';
#endif
    }
    endTime = millis();

    Serial.print("End time  : ");
    Serial.println(endTime);

    Serial.print("Time taken: ");
    Serial.println(endTime - startTime);
}

void loop() {
    // put your main code here, to run repeatedly:
}

When I ran this using SMALL strcpy(), it reports taking 396 milliseconds. When I run it using strncpy() with the null added, it reports 678 milliseconds. strcpy() appears to take about 60% of the time strncpy() does, at least for this test. (Maybe. Math is hard.)

Now, this is a short string that requires strncpy() to pad out the rest of the buffer. If I change it to use a 9 character string (leaving one byte for the null terminator):

#ifdef SMALL
    // Smaller and faster, but less safe.
    strcpy(buffer, "123456789");
#else
    // Larger and slower, but more safe.
    strncpy(buffer, "123456789", BUFSIZE - 1);
    buffer[BUFSIZE-1] = '';
#endif

…no padding will be done. Without padding, the SMALL version takes 572 and the strncpy()/null version takes… 478!?!

Huh? How can this be? How did the “small” version suddenly get SLOWER? Well, before, strcpy() only had to copy the five characters of “Hello” plus a null then it was done, while strncpy() had to copy “Hello” then pad out five nulls to fill the buffer. Once both had to do the same amount of work (copying nine bytes and a null), it appears that strncpy() is actually faster! (Your mileage may vary. Different compilers targeting different processors may generate code in vastly different ways.)

Perhaps there is just some optimization going on when the destination buffer size is know. (Note to self: Look in to the GCC strncpy source code and see what it does versus strcpy.)

Conclusion:

strncpy() isn’t necessarily going to be slower (at least on this Arduino)!
strncpy() might be significantly slower if you copy a very short string (“Hi”) in to a very long buffer (char buffer[80];).

~~Buyer~~ Programmer beware!

I am sure glad we (didn’t) clear that up. In the next part, I’ll get back to talking about appending strings using strcat() and how to make that safer.

To be continued…

Drobo generation 2 verses Drobo generation 3

Leave a reply

I have been working on a multi-part article about the Data Robotics Drobo storage device. It documents my experience moving from the 2nd generation model to the 3rd generation model.

You can find it over at my Mac-centric site, Appleause. Start here:

Drobo (2nd gen) to Drobo (3rd gen), part 1

Drobo (2nd gen) to Drobo (3rd gen), part 5

Leave a reply

See also: Part 1, Part 2, Part 3 and Part 4.

When we last left off, our hero (that’s me) was waiting to see if hs data survived after moving four hard drives from an old Drobo in to a new one. Spoiler: It did.

With that out of the way, let’s look at some of the differences between old versus new Drobos:

The removable front plate has a logo that is now embossed/raises from the black plastic.
The LEDs are much brighter.
There is a power switch on the back.
Drobo Dashboard gives you several new options!

Paradise By the Dashboard Light

Drobo Dashboard has a few notable improvements when browsing a 3rd generation Drobo:

Drobo 3rd Gen: New System Information status display, featuring Drobo health.

Drobo 3rd Gen: New HEALTH status for each installed drive, too!

Drobo 3rd Gen: New Drive Information status display, featuring health of each installed drive, too!

Drobo 3rd Gen: New Performance status, though mine always shows 0.

And for comparison, the more limited Status display from the 2nd generation Drobo:

Drobo 2nd Gen: Much less status…

Under Volumes, there is now an option to create a special Time Machine volume. My understanding is that this volume will be treated as a size-limited volume, rather than the “grow until it breaks” virtual volumes.

Drobo 3rd Gen: New Time Machine volume support.

The Tools display seems to be the same, except wording is different. “Turn Blink Lights On” versus “Blink Lights”, and “Shutdown” versus “Standby”.

Drobo 3rd Gen: Tools display.

The 3rd gen model adds a new Drobo Settings display. From here, you can set the name of the Drobo (that was possible with the 2nd gen, but was done somewhere else), Disk Drive Spindown, and Dim Lights timeout. There is also a greyed out “Dual Disk Redundancy” selection. According to a feature chart at the Drobo site, this model does support dual disk redundancy where you can have two drives fail and still preserve data. I am unable to test that with my current unit since it was already formatted to use all the disks for storage in the previous 2nd gen model I had.

Drobo 3rd Gen: Drobo Settings display.

Dual Disk Redundancy is a feature I would really like to try out. You have less space available for data, but if you migrate from 2TB drives to 3TB drives, you can do this and end up with about the same amount of storage as before. This will be a topic for another time.

Next time, we’ll compare some data transfer benchmarks. How does a “faster” Drobo 3rd gen via a USB 2.0 port compare to a slower Drobo 2nd gen hooked up via FireWire? I could tell you now, but then you wouldn’t need to wait for the next part.

Until then…

Drobo (2nd gen) to Drobo (3rd gen), part 4

Leave a reply

Faster than a Speeding Rebuild…

Spoiler: Drobo 3rd gen rebuilt in 12 hours what 2nd gen took 120 hours to do. (* Not 100% fair since I was moving a second 3TB drive in, but it’s good enough for a reference point.)

One of the promises of the new 3rd generation Drobo was that it has dramatically faster rebuild times. (Skipping ahead, it looks like the newer model could have done the same rebuild in 12 hours.) On the downside, the new model does not have Firewire, so disk access would be much slower on my old Mac which only has USB 2.0. Newer Macs have USB 3.0, which is supposed to be very fast with the 3rd gen Drobo.

Since I didn’t want to spend months waiting for Drobo to rebuild as I upgraded drives one at a time, and since I feared trusting my data to a six year old end-of-life Drobo and dying hard drives, I decided it was time to upgrade. I do need to point out that I did not go out and buy a new $300 Drobo. I am far too broke for that. But, I do have one to review. If you want to get your own, you can use a special discount code and get $100 off. Go to:

www.drobo.com/macosken

You can learn more about Drobo there, and find a special “KEN100” discount code that lets you pick up a 3rd generation Drobo for $199 (plus about $20 in FedEx shipping). That would be a good price for a dumb 4-bay hard drive enclosure. (This code is supposed to be good until 12/31/2015.)

I’ll wait right here while you go do that . . .

Old Versus New

Drobo 3rd gen (left) vs 2nd gen (right).

One week later… You should now have your new Drobo. The first thing you will notice is their package has gotten much nicer. I blame this on Apple, as they have made boring brown boxes seem downright primitive.

My old Drobo came wrapped in a black cloth bag. The new one comes in a black cloth bag that has handles on it — it’s a Drobo-logo’d version of those reusable grocery store bags! There was also a Drobo window sticker inside just like when you get that Apple sticker with a new Apple product (did I mention blaming things on Apple?). The packaging has much improved.

Everything else should be pretty similar. There is an included USB cable, and the power supply now uses a more standard power cable. The new Drobo looks the same except the logo is now embossed/raised on the front instead of just being painted on. (That’s the easiest way to tell them apart by looking at them when the lights aren’t on. More on the lights in a moment.) There is also a power switch on that back now. (Wow! I can FINALLY turn the thing off without having to yank the power cable.)

There is a warning note attached to the Drobo (and repeated in the included Quick Start guide printed on the inside cover of the accessory box). It says any drives you insert will have their data erased. What!?! I thought I read you could migrate your old “disk pack” from an old Drobo to the new one. Just to be safe, I did some searching on Drobos website and found an article that verified this was possible.

I also contacted Drobo support and they clarified: As long as the units are powered off, the erase will not happen, but if you insert the drives while the Drobo is booted, it will being the process of formatting them for new storage.

PRO-TIP: READ THE INSTRUCTIONS AND WARNINGS! Had I made the mistake of having my new Drobo powered up when I inserted the first drive, I would have lost data!

Once my previous drives (three 2TB and one 3TB) were moved over to the new Drobo, I powered it up to see if my data would survive…

Next time, we’ll find out if my data survived…

Sub-Etha Software

Don't Panic! "In Support of the CoCo and OS-9 since 1990."

Category Archives: Hardware

Drobo (3rd gen) to Drobo 5C, part 2

Drobo (3rd gen) to Drobo 5C review

Drobo (3rd gen) to Drobo 5C, part 1

Drobo (3rd gen) to Drobo 5C, introduction

iCade Mobile controller for $5 on Amazon

sizeof() matters

C strcat, strcpy and armageddon, part 3

Drobo generation 2 verses Drobo generation 3

Drobo (2nd gen) to Drobo (3rd gen), part 5

Paradise By the Dashboard Light

Drobo (2nd gen) to Drobo (3rd gen), part 4

Faster than a Speeding Rebuild…

Old Versus New