> I think I can provide a little useful info here. There are dramatic > differences in small file performance on SD cards. This difference is > very noticeable when the card is used as an boot device.
Wow, that is pretty incredible. The "random 4K write" performance is utterly dismal on so many SD cards.
I reformatted my 16 GB USB flash disk and ran Crystal Disk Mark on it from a MacBook Pro booted into Windows 7. Its random 4K write speed is only 0.010, or only 10 kbytes/sec! I had no idea its performance was so bad. I guess that explains why only a small fraction of my 600 meg .tar.gz file was able to extract in 1 hour! Why its partition table got corrupted is still a mystery....
Scott, any chance you could run Crystal Disk Mark on the SD card we were using on your Raspberry Pi? It'll probably require reformatting the card, but maybe a dd image could save and restore the whole thing? I'd be really curious to know how the card we were using compares?
I ran the benchmark on my 32 gig SD card I brought Monday, but we didn't use. It scored 0.597 on the random 4k write test. It's a "SanDisk Ultra, class 4". 597 kbytes/sec isn't wonderful, but it's certainly a lot faster than the 7 to 20 kbytes/sec so many SD cards seem to have on random writes.
From those web pages and a couple others I found with a little googling, it looks like 1.8 Mbyte/sec is about the fastest random 4k write score anyone has found on any SD card. Here's another page.
Pretty amazing how only a few cards manage faster than 20 kbytes/sec:
> People on the B&N Nook Color forum on XDA-Developers benchmarked a > bunch of cards and found the fastest cards were 200 times as fast as > the slowest ones at small file writes. Slow cards were utterly > unusable as boot devices. I encountered this myself and had to get > some new SD cards (Sandisk Ultras) to resolve it.
> It appears the Pi community has discovered this as well.
> On Tue, Jul 3, 2012 at 7:09 PM, Paul Stoffregen <p...@pjrc.com > <mailto:p...@pjrc.com>> wrote:
> That said, how did this go?
> Slowly. Very slowly, and not so well in a number of ways other
> than the extreme Pi slowness.
> First, there were power-up issues. My USB power adaptor, despite
> being a Belkin brand with 1 amp rating, was not up to the task of
> powering the Pi. Scott's power adaptor worked with the same
> Micro-B cable. Looks like I need to find a better USB power adaptor!
> Once it booted up, I plugged in my USB flash disk. So far, so
> good. I had (foolishly) tar'd up my entire wxWidgets directory,
> containing several copies of various versions of the source and
> about a dozen builds. The .tar.gz file was 600 megs. Scott's SD
> card was "only" 4 gigs and didn't have a lot of room, so I did a
> "tar -xvzf" , reading from the file and extracting back to my 16
> gig USB flash disk.
> After about an hour, it ended... badly! There were I/O errors.
> Thereafter, my 16 GB USB flash disk no longer worked. The
> partition table was corrupted. That was the only copy of the
> source code I'd brought. I haven't tried to reformat the card
> yet. In that time, which I think was nearly an hour, only a small
> fraction of the entire archive got extracted!
> With some help from a laptop with wifi (I can't remember whose), I
> managed to log in remotely to my home machine and grab another
> copy of the source code. This time I made a point to get only the
> things absolutely needed. Using Jerry's USB flash disk, we got
> the files over to the Pi.
> That .tar.gz file was "only" 20 megabytes. I did the extract
> reading from the USB flash disk and writing to the SD card. I
> didn't time how long it took, but it was very slow, with plenty of
> time to go get another beer.
> Then I tried running the wxWidgets ./configure script, with a
> bunch of options my software needs the library to use. On a
> regular PC it takes maybe a minute. I didn't time it, but it was
> at least 20 minutes until it stopped, complaining that the Pi was
> missing the GTK2 development headers.
> Maybe about an hour was spent trying to get internet connectivity
> for the Pi. Scott's USB-wifi adaptor needed more power than was
> available (or had some other mysterious problem, but we figured it
> was power), even using a powered USB hub I brought. Next a laptop
> was tried, and pings worked, but apt-get did not. Finally, a wifi
> router appeared and saved the day.
> Running "apt-get install libgtk2-dev" took about 3 minutes to
> download lots of packages, and just over half an hour to extract
> and install them!
> The we ran the wxWidgets configure script again. It was finally
> able to complete, taking almost half an hour. By then, it was
> getting pretty late, about 10:30. I'm pretty sure running "make"
> would have taken at least 10 hours, perhaps much longer. It
> really is that slow.
> Dan plugged in his Pi, which had a media-playing distro on the
> card. The Raspberry Pi booted up slowly and was a bit sluggish
> (but not terribly slow) navigating the very pretty menus. It
> played The Big Lebowski, or at least the first several minutes of
> it, in beautiful 1080p (or some scaled down res that fit my
> monitor... we never did confirm what res it was). The video
> playback was very good, without any apparently skipping or
> buffering. It was late and the Backspace folks announced they
> would close soon, so we shut it down just before the scene where
> Lebowski's rug gets damaged.
> Dan loaned me his Pi. I'm planning to set it up in another room
> and use a kitchen timer to remind myself to go back every couple
> hours to run the next command. Maybe after a few days I can get
> some code compiled that way?
> Scott believes some of the slowness might have been due to his SD
> card being a "class 6". Apparently the Pi really only supports up
> to class 4, so maybe it was having trouble? I'm skeptical. It
> really is terribly slow. I do have a 32 GB class 4 card for
> testing. I'll begin another multi-day attempt later this week.....
> Thanks for the tip Dave. I had no idea SD card random write performance
> varies by about a factor of 100 between different cards.
I haven't been following this thread, but I am interested in why exactly it is that random writes suck so badly.
What follows is just a random dump of thoughts on the matter though.....
I highly doubt it's something to do with the actual SD interface, as it's basically just an SPI or quad-SPI connection. Is it something to do with the host polling the card for page-erase completion, in which case it might be mitigated with a tuneable on the host? I wouldn't think it's that either though since there's such variation between cards, unless the card suggests a polling period. I know too little about the protocol as far as that goes.
Thinking about it more, I'm guessing it has more to do with flash page size and rewrite times. If you only write 512b to the card and the flash page size is bigger than that, it'll be forced to read that whole page, erase it, and then rewrite the merge of the old data and the new sector.
You'd think that since 4K is a common flash page size, and the random writes are 4K, that you'd be fine. However, unless the controller is smart enough to start the read-erase-write cycle on the first sector, then *notice* that the next sector is sequential and try to coalesce the writes, it's going to end up doing *8* r-e-w cycles every single time. Going to a 4K sector size could eliminate the problem, but leading-edge SATA hard drives are only just now supporting 4K, I wouldn't expect SD cards to do it yet. Maybe that's what the higher class cards are capable of?
Looking into the SD architecture a bit, it looks like the picture is even worse. They're arranged in up to 4096 "clusters" with up to 512 "blocks" per, where originally a block = 512b sector, but later could be 1k or 2k. Either way, the *cluster* is the flash page erase size, which means you could have a erase size of 1MB. That makes the 8x r-e-w cycles need to "randomly" write a 4KB block suck really bad, but it does also strongly imply that sequential erase clustering is generally done, because that'd the only way you'd get decent sequential write performance (get write of first sector, read and erase entire cluster, get write of sector++ and *not* restart the erase, repeat for entire cluster).
As far a usage on a Nook or Pi, I suspect your killer is atime. Be default (at least historically) the filesystems are set to record the timestamp of every *read* access to every file, which means the inode of every file has to be subtly altered. This will cause a *massive* number of small writes especially on boot, which could explain what's going on. Setting 'noatime' on all filesystems would help that significantly.
Another probably better option, and where TRIM comes into play again, would be to use something like JFFS2 on the SD card. Such filesystems are *extremely* aware of the physical structure of flash-based devices, to the point where they "waste" space by trying to treat the device as "append-only". Rather than erasing and rewriting data repeatedly in a given sector of the hardware, it will "journal" the data changes in such a way as to almost totally eliminate read-modify[erase]-write cycles.
When you have a piece of hardware with a hard-wired flash chip on the board (rather than an "ATA" protocol to an SD card), JFFS2 will actively pre-erase as much of the flash space as it can, sequentially, in order to make writes nearly instantaneous (since erases take *far* longer than the actual write). For an SD card or even a modern SSD, that's where the TRIM command would come into play. However, I have no idea if the SD protocol has any provision for that.
The main difference in this case between a SD card and a larger SSD would be that the SSD has far more resources at its disposal in order to reorder and map the logical sectors into actual physical flash pages. An SSD will wear-level in such a way that the mapping becomes totally chaotic across the entire device, whereas an SD card *might* wear-level in very small blocks (because of silicon-size constraints, basically). Because SSDs actually have a little bit of headroom relative to their advertised size, they can do a *little* bit of pre-erase even without TRIM. SD's not so much.
Paul, I will try to benchmark that SD card tonight if I have time. I hadn't realized how much variation there is.
Scott
On Jul 4, 2012, at 11:31 AM, Paul Stoffregen wrote:
> On 07/03/2012 08:17 PM, Dave Edick wrote:
>> Paul,
>> I think I can provide a little useful info here. There are dramatic differences in small file performance on SD cards. This difference is very noticeable when the card is used as an boot device.
> Wow, that is pretty incredible. The "random 4K write" performance is utterly dismal on so many SD cards.
> I reformatted my 16 GB USB flash disk and ran Crystal Disk Mark on it from a MacBook Pro booted into Windows 7. Its random 4K write speed is only 0.010, or only 10 kbytes/sec! I had no idea its performance was so bad. I guess that explains why only a small fraction of my 600 meg .tar.gz file was able to extract in 1 hour! Why its partition table got corrupted is still a mystery....
> Scott, any chance you could run Crystal Disk Mark on the SD card we were using on your Raspberry Pi? It'll probably require reformatting the card, but maybe a dd image could save and restore the whole thing? I'd be really curious to know how the card we were using compares?
> I ran the benchmark on my 32 gig SD card I brought Monday, but we didn't use. It scored 0.597 on the random 4k write test. It's a "SanDisk Ultra, class 4". 597 kbytes/sec isn't wonderful, but it's certainly a lot faster than the 7 to 20 kbytes/sec so many SD cards seem to have on random writes.
> From those web pages and a couple others I found with a little googling, it looks like 1.8 Mbyte/sec is about the fastest random 4k write score anyone has found on any SD card. Here's another page. Pretty amazing how only a few cards manage faster than 20 kbytes/sec:
> Tomorrow I'll set up Dan's Pi with this "fast" 597 kbyte/sec card and see how it runs.
> Thanks for the tip Dave. I had no idea SD card random write performance varies by about a factor of 100 between different cards.
>> People on the B&N Nook Color forum on XDA-Developers benchmarked a bunch of cards and found the fastest cards were 200 times as fast as the slowest ones at small file writes. Slow cards were utterly unusable as boot devices. I encountered this myself and had to get some new SD cards (Sandisk Ultras) to resolve it.
>> It appears the Pi community has discovered this as well.
>> On Tue, Jul 3, 2012 at 7:09 PM, Paul Stoffregen <p...@pjrc.com> wrote:
>> That said, how did this go?
>> Slowly. Very slowly, and not so well in a number of ways other than the extreme Pi slowness.
>> First, there were power-up issues. My USB power adaptor, despite being a Belkin brand with 1 amp rating, was not up to the task of powering the Pi. Scott's power adaptor worked with the same Micro-B cable. Looks like I need to find a better USB power adaptor!
>> Once it booted up, I plugged in my USB flash disk. So far, so good. I had (foolishly) tar'd up my entire wxWidgets directory, containing several copies of various versions of the source and about a dozen builds. The .tar.gz file was 600 megs. Scott's SD card was "only" 4 gigs and didn't have a lot of room, so I did a "tar -xvzf" , reading from the file and extracting back to my 16 gig USB flash disk.
>> After about an hour, it ended... badly! There were I/O errors. Thereafter, my 16 GB USB flash disk no longer worked. The partition table was corrupted. That was the only copy of the source code I'd brought. I haven't tried to reformat the card yet. In that time, which I think was nearly an hour, only a small fraction of the entire archive got extracted!
>> With some help from a laptop with wifi (I can't remember whose), I managed to log in remotely to my home machine and grab another copy of the source code. This time I made a point to get only the things absolutely needed. Using Jerry's USB flash disk, we got the files over to the Pi.
>> That .tar.gz file was "only" 20 megabytes. I did the extract reading from the USB flash disk and writing to the SD card. I didn't time how long it took, but it was very slow, with plenty of time to go get another beer.
>> Then I tried running the wxWidgets ./configure script, with a bunch of options my software needs the library to use. On a regular PC it takes maybe a minute. I didn't time it, but it was at least 20 minutes until it stopped, complaining that the Pi was missing the GTK2 development headers.
>> Maybe about an hour was spent trying to get internet connectivity for the Pi. Scott's USB-wifi adaptor needed more power than was available (or had some other mysterious problem, but we figured it was power), even using a powered USB hub I brought. Next a laptop was tried, and pings worked, but apt-get did not. Finally, a wifi router appeared and saved the day.
>> Running "apt-get install libgtk2-dev" took about 3 minutes to download lots of packages, and just over half an hour to extract and install them!
>> The we ran the wxWidgets configure script again. It was finally able to complete, taking almost half an hour. By then, it was getting pretty late, about 10:30. I'm pretty sure running "make" would have taken at least 10 hours, perhaps much longer. It really is that slow.
>> Dan plugged in his Pi, which had a media-playing distro on the card. The Raspberry Pi booted up slowly and was a bit sluggish (but not terribly slow) navigating the very pretty menus. It played The Big Lebowski, or at least the first several minutes of it, in beautiful 1080p (or some scaled down res that fit my monitor... we never did confirm what res it was). The video playback was very good, without any apparently skipping or buffering. It was late and the Backspace folks announced they would close soon, so we shut it down just before the scene where Lebowski's rug gets damaged.
>> Dan loaned me his Pi. I'm planning to set it up in another room and use a kitchen timer to remind myself to go back every couple hours to run the next command. Maybe after a few days I can get some code compiled that way?
>> Scott believes some of the slowness might have been due to his SD card being a "class 6". Apparently the Pi really only supports up to class 4, so maybe it was having trouble? I'm skeptical. It really is terribly slow. I do have a 32 GB class 4 card for testing. I'll begin another multi-day attempt later this week.....
The Pi does not like booting up from my Sandisk card. I've power cycled many times, and so far managed to get it to boot up twice. It seems to only boot if the power has been off for a very long time, like half an hour.
I tried 3 different power adaptors, and finally I got a voltmeter out and measured on the PTC fuse and 3.3 volt regulator. The Pi is getting 5.1 volts. I'm pretty sure it's not the power. With the same power adaptor, the Pi boots every time from the Corsair card.
The Pi actually runs pretty well when using the Sandisk card... the 2 times I've managed to get it to actually boot. One of those times, I did the "apt-get install libgtk2.0-dev" (that took over half an hour to extract/install at Backspace), and it took only a few minutes! The SD card speed seems to make a HUGE difference.
These are the 4 cards I have.
Sandisk Ultra, 32 GB, class 4, random 4k write = 597 kbytes/sec
Transcend, 32 GB, class 10, random 4k write = 10 kbytes/sec
Kingston, 2 GB, random 4k write = 15 kbytes/sec
Corsair, 2 GB, random 4k write = 96 kbytes/sec
I'm starting over with the Corsair card, which isn't nearly as fast as the Sandisk, and only has 2 gigs, but at least the Pi boots up reliably.
Running on the Corsair card, the install part of "apt-get install libgtk2.0-dev" took 3 minutes and 12 seconds, which is dramatically faster than the 30-40 minutes it took at Backspace running on Scott's card.
I tried to re-run with the Sandisk card, which seemed to go very quickly, but so far I haven't managed to get the Pi to boot with it again.
I'm trying now with the Transcend card, and so far it's still stuck in the initial "apt-get upgrade" which ran quickly on the other 2 cards.
It's running terribly slow, about like at Backspace on Scott's card. I might not even bother trying the libgtk2.0-dev install. It's unusably slow.
One thing is certain, the SD card's random write speed makes a huge difference. It's a shame the Pi almost never boots up with my Sandisk card, because it actually runs pretty well with that one.
> Paul, I will try to benchmark that SD card tonight if I have time. I hadn't realized how much variation there is.
> Scott
> On Jul 4, 2012, at 11:31 AM, Paul Stoffregen wrote:
>> On 07/03/2012 08:17 PM, Dave Edick wrote:
>>> Paul,
>>> I think I can provide a little useful info here. There are dramatic differences in small file performance on SD cards. This difference is very noticeable when the card is used as an boot device.
>> Wow, that is pretty incredible. The "random 4K write" performance is utterly dismal on so many SD cards.
>> I reformatted my 16 GB USB flash disk and ran Crystal Disk Mark on it from a MacBook Pro booted into Windows 7. Its random 4K write speed is only 0.010, or only 10 kbytes/sec! I had no idea its performance was so bad. I guess that explains why only a small fraction of my 600 meg .tar.gz file was able to extract in 1 hour! Why its partition table got corrupted is still a mystery....
>> Scott, any chance you could run Crystal Disk Mark on the SD card we were using on your Raspberry Pi? It'll probably require reformatting the card, but maybe a dd image could save and restore the whole thing? I'd be really curious to know how the card we were using compares?
>> I ran the benchmark on my 32 gig SD card I brought Monday, but we didn't use. It scored 0.597 on the random 4k write test. It's a "SanDisk Ultra, class 4". 597 kbytes/sec isn't wonderful, but it's certainly a lot faster than the 7 to 20 kbytes/sec so many SD cards seem to have on random writes.
>> From those web pages and a couple others I found with a little googling, it looks like 1.8 Mbyte/sec is about the fastest random 4k write score anyone has found on any SD card. Here's another page. Pretty amazing how only a few cards manage faster than 20 kbytes/sec:
>> Tomorrow I'll set up Dan's Pi with this "fast" 597 kbyte/sec card and see how it runs.
>> Thanks for the tip Dave. I had no idea SD card random write performance varies by about a factor of 100 between different cards.
>>> People on the B&N Nook Color forum on XDA-Developers benchmarked a bunch of cards and found the fastest cards were 200 times as fast as the slowest ones at small file writes. Slow cards were utterly unusable as boot devices. I encountered this myself and had to get some new SD cards (Sandisk Ultras) to resolve it.
>>> It appears the Pi community has discovered this as well.
>>> On Tue, Jul 3, 2012 at 7:09 PM, Paul Stoffregen<p...@pjrc.com> wrote:
>>> That said, how did this go?
>>> Slowly. Very slowly, and not so well in a number of ways other than the extreme Pi slowness.
>>> First, there were power-up issues. My USB power adaptor, despite being a Belkin brand with 1 amp rating, was not up to the task of powering the Pi. Scott's power adaptor worked with the same Micro-B cable. Looks like I need to find a better USB power adaptor!
>>> Once it booted up, I plugged in my USB flash disk. So far, so good. I had (foolishly) tar'd up my entire wxWidgets directory, containing several copies of various versions of the source and about a dozen builds. The .tar.gz file was 600 megs. Scott's SD card was "only" 4 gigs and didn't have a lot of room, so I did a "tar -xvzf" , reading from the file and extracting back to my 16 gig USB flash disk.
>>> After about an hour, it ended... badly! There were I/O errors. Thereafter, my 16 GB USB flash disk no longer worked. The partition table was corrupted. That was the only copy of the source code I'd brought. I haven't tried to reformat the card yet. In that time, which I think was nearly an hour, only a small fraction of the entire archive got extracted!
>>> With some help from a laptop with wifi (I can't remember whose), I managed to log in remotely to my home machine and grab another copy of the source code. This time I made a point to get only the things absolutely needed. Using Jerry's USB flash disk, we got the files over to the Pi.
>>> That .tar.gz file was "only" 20 megabytes. I did the extract reading from the USB flash disk and writing to the SD card. I didn't time how long it took, but it was very slow, with plenty of time to go get another beer.
>>> Then I tried running the wxWidgets ./configure script, with a bunch of options my software needs the library to use. On a regular PC it takes maybe a minute. I didn't time it, but it was at least 20 minutes until it stopped, complaining that the Pi was missing the GTK2 development headers.
>>> Maybe about an hour was spent trying to get internet connectivity for the Pi. Scott's USB-wifi adaptor needed more power than was available (or had some other mysterious problem, but we figured it was power), even using a powered USB hub I brought. Next a laptop was tried, and pings worked, but apt-get did not. Finally, a wifi router appeared and saved the day.
>>> Running "apt-get install libgtk2-dev" took about 3 minutes to download lots of packages, and just over half an hour to extract and install them!
>>> The we ran the wxWidgets configure script again. It was finally able to complete, taking almost half an hour. By then, it was getting pretty late, about 10:30. I'm pretty sure running "make" would have taken at least 10 hours, perhaps much longer. It really is that slow.
>>> Dan plugged in his Pi, which had a media-playing distro on the card. The Raspberry Pi booted up slowly and was a bit sluggish (but not terribly slow) navigating the very pretty menus. It played The Big Lebowski, or at least the first several minutes of it, in beautiful 1080p (or some scaled down res that fit my monitor... we never did confirm what res it was). The video playback was very good, without any apparently skipping or buffering. It was late and the Backspace folks announced they would close soon, so we shut it down just before the scene where Lebowski's rug gets damaged.
>>> Dan loaned me his Pi. I'm planning to set it up in another room and use a kitchen timer to remind myself to go back every couple hours to run the next command. Maybe after a few days I can get some code compiled that way?
>>> Scott believes some of the slowness might have been due to his SD card being a "class 6". Apparently the Pi really only supports up to class 4, so maybe it was having trouble? I'm skeptical. It really is terribly slow. I do have a 32 GB class 4 card for testing. I'll begin another multi-day attempt later this week.....
> One thing is certain, the SD card's random write speed makes a huge
> difference. It's a shame the Pi almost never boots up with my Sandisk
> card, because it actually runs pretty well with that one.
Have you tried booting/running with a USB disk (i.e., a SATA or SSD with
a USB converter)? It might be useful for making the mistakes that would
be time-consuming if you were running from an SD card.
Also, not sure if this would matter, but I have one of my GuruPlugs
running with a micro SD card in a tiny USB-SD adapter, and it appears to
work OK. Seems like it'd be worth a try on the RPi as well.
-- Mersenne Law LLC · www.mersenne.com · +1-503-679-1671
- Small Business, Startup and Intellectual Property Law -
1500 SW First Ave. · Suite 1170 · Portland, Oregon 97201
On Thu, Jul 5, 2012 at 4:00 PM, David Madden <d...@mersenne.com> wrote:
> Have you tried booting/running with a USB disk (i.e., a SATA or SSD with
> a USB converter)? It might be useful for making the mistakes that would
> be time-consuming if you were running from an SD card.
The Pi's boot loader looks to the SD card for its boot code; there's no
BIOS, and it's hard coded to do this. It should be possible to write boot
code to the SD to mount and boot from a USB drive, but I'm not sure whether
anyone has done that yet.
> On Thu, Jul 5, 2012 at 4:00 PM, David Madden <d...@mersenne.com > <mailto:d...@mersenne.com>> wrote:
> Have you tried booting/running with a USB disk (i.e., a SATA or
> SSD with
> a USB converter)? It might be useful for making the mistakes that
> would
> be time-consuming if you were running from an SD card.
> The Pi's boot loader looks to the SD card for its boot code; there's > no BIOS, and it's hard coded to do this. It should be possible to > write boot code to the SD to mount and boot from a USB drive, but I'm > not sure whether anyone has done that yet.
The one USB flash disk I have that's of reasonable size (16 GB) benchmarked at the same slow 4K random write speed (only 10 kbytes/sec) as the worst of my SD cards!
I ran for a while with the Transcend card (random 4k write = 20 kbytes/sec), and indeed the Pi ran much slower, but still not nearly as bad as we experienced on Monday at Backspace.
I also got a kernel panic while running with the Corsair card.
So far, my Raspberry Pi experience is not going so well......
Just thought I would let everyone know surplusgizmos is doing 50% off sale on all surplus items in the store this Saturday the 9th. _______________________________________________
dorkbotpdx-blabber mailing list
dorkbotpdx-blab...@dorkbot.org
http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
Hey all. Was just at this sale, and picked up a few surplus lacie drive
adapters. They're USB3, but require an external 12v 3a adapter. The adapter
from lacie round $29.99. Was gonna ask if anyone has an adapter of
comparable specs. I have a barrel connector that fits, so I can swap it out
easily.
I can pay with (some, I'm broke) money, or a beer or two at a meeting.
> Just thought I would let everyone know surplusgizmos is doing 50% off sale
> on all surplus items in the store this Saturday the 9th.
> _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpdx-blab...@dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
> Hey all. Was just at this sale, and picked up a few surplus lacie drive adapters. They're USB3, but require an external 12v 3a adapter. The adapter from lacie round $29.99. Was gonna ask if anyone has an adapter of comparable specs. I have a barrel connector that fits, so I can swap it out easily.
> I can pay with (some, I'm broke) money, or a beer or two at a meeting.
> -Blain
> On Jul 5, 2012 4:33 PM, "Jerry Biehler" <jerry.bieh...@gmail.com> wrote:
> Just thought I would let everyone know surplusgizmos is doing 50% off sale on all surplus items in the store this Saturday the 9th.
> _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpdx-blab...@dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber > _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpdx-blab...@dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
One thing to keep in mind with the hard drive adapters. If they are intended for 3.5" hard drives they will need 12v. Some cheaper ones will need 12 and 5v. Anything that was intended for a 2.5" drive will be 5v.
-Jerry
On Jul 7, 2012, at 5:45 PM, Blain C <blain...@gmail.com> wrote:
> Sadly, we all thought they were 5v at the time, and so that's what I
> walked away with. Now that I know, they're closed. I feel kinda
> stupid, honestly.
> On 07/04/2012 11:31 AM, Paul Stoffregen wrote:
>> Thanks for the tip Dave. I had no idea SD card random write performance
>> varies by about a factor of 100 between different cards.
> I haven't been following this thread, but I am interested in why > exactly it is that random writes suck so badly.
> What follows is just a random dump of thoughts on the matter though.....
Here's another data point for the raspberry pi/sd card discussion:
Yesterday I went to Costco and bought a Sandisk Ultra 2-pack of 8GB class 6 SD cards for about $18. The CrystalDiskMark 4k random write score is 1.629.
