[dorkbotpdx-blabber] Raspberry Pi

[Paul Stoffregen]

Does anyone have a Raspberry Pi they'd be willing to let me use for a
couple hours at the next meeting?

I'd like to try porting/compiling/testing a couple programs. That
should be pretty easy, since I already tested them on a Beagleboard back
when there was lots of hype about upcoming Linux-based ARM netbooks
(before Apple released the iPad). I'm also a bit curious to see what
all this Pi hype has been about...


-Paul
_______________________________________________
dorkbotpdx-blabber mailing list
dorkbotpd...@dorkbot.org
http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber

[Erik Lane]

Well, I'm finally in the area and would like to make it to the next
meeting. When is it? I haven't figured out the schedule yet, other
than that they're on Mondays. Supposedly I have a Raspberry Pi that
will get here Tuesday by the end of the day. I guess if the meeting is
tomorrow that won't work, but otherwise I'll bring it if I can come
and you're welcome to play with it.

Erik

[Jason Plumb]

Hi Erik,

We meet every other Monday. The next meeting is a week from tomorrow.
You can always reference this page:

http://dorkbotpdx.org/meetings

and feel free to subscribe to the google calendar in the middle there
(if you use such things).

Hope you can make it out in a week!

-jason

[Scott Dixon]

Hi, Paul
I have one which is supposed to be delivered tomorrow. I will bring it to the next meeting and you are welcome to play with it.
Scott

[Ward Cunningham]

Welcome.

The next meeting is in a week, on July 2nd.

Save this link:

http://dorkbotpdx.org/meetings

Or remember that "Meeting Info" on the DorkbotPDX site Content Menu takes you there.

[Erik Lane]

Wow, that was a quick response. Thanks, everyone!

I'll do my best to be there, but we just moved (and are soon to move
again - this place is only temporary, and we're frantically looking
for a place in the area to rent or buy) and our little house is
absolute chaos, along with other drama going on, so I can't guarantee
anything. But I'll be due for some time to myself, so I know that I'll
make it a priority.

Thanks,
Erik

[Joel]

If you can't make it to the meeting, let me know - I still owe Dorkbot
a favor from a while back for letting me borrow their BeagleBoards
(thanks to you all!), and I just obtained a Raspberry Pi myself that
I'd be glad to let you borrow.

Joel

[Erik Lane]

I'll try to give some advanced warning. At least a quick idea of what
the odds are - maybe I'll post sometime over the weekend with what it
looks like.

Erik

[Erik Lane]

Just as a heads-up, I've talked to my wife, and barring some crisis
coming up, I will be there on Monday with my Raspberry Pi that did in
fact come as promised.

Paul - I have not had the time to play with it, so I have no idea what
it would take to power it up. I don't know if it will work from USB or
if it needs independent power. At any rate with us still being in the
middle of moving, I have no idea where all my connectors and wires
are, so I can't help with that. I can only bring the board itself and
watch as you play with it. (Not that I'm worried about you breaking it
- I just want to see it work!)

Erik

[Scott Dixon]

I have a pi which I have set up and working, including downloading Linux and loading it on an sd card, setting up the os and networking, etc. I will bring it in Monday. There is enough setup that I wouldn't recommend trying to do it all at the Monday meeting( at least if you expect to actually try anything on it. 

Scott

[Paul Stoffregen]

Thanks Scott, Eric, & everyone!

I started putting together stuff to bring tomorrow to actually use a Pi.  So far, I have:

32 GB class 4 SDHC card with the Debian image written to it.
USB flash drive with my source code and source for several libraries.
LCD monitor, 17 inch (1280x1024) with DVI input + power adaptor
HDMI to DVI cable (worked with a Beagleboard... no idea if it will work on the Raspberry Pi)
USB keyboard, USB Mouse + USB hub
Ethernet cable
USB power adaptor + USB Micro-B cable (to power the Raspberry Pi)
Extension cord and power splitter

Things I do not have:

Raspberry Pi....
Laptop for wifi-to-ethernet tethering (eg: apt-get install some_missing_package)
Other stuff I haven't anticipated needing ??

Can anyone think of stuff I've missed?

Could anyone bring a laptop that can do the tethering, so apt-get might work?

[Jerry Biehler]

HDMI and DVI are the same thing when it comes to the video. HDMI has audio and in the latest revision, ethernet.

[Paul Stoffregen]

On 07/01/2012 02:57 PM, Jerry Biehler wrote:
> HDMI and DVI are the same thing when it comes to the video. HDMI has audio and in the latest revision, ethernet.

So does that mean it will actually work?

I recall the Beagleboard had thorny issues with properly supporting
various resolutions and refresh rates, even though the cables plugged in.

> On Jul 1, 2012, at 2:43 PM, Paul Stoffregen wrote:
>

>> Thanks Scott, Eric,& everyone!

[Jerry Biehler]

Assuming that the chipset supports the resolution that the monitor, yes. I have gone back and forth with hdmi and dvi in various combinations and have never had it not work. This being computers and other consumer goods, not a pi or beagle.

-Jerry

[Scott Dixon]

Hi, Paul,

Sounds like you have more than enough pieces. I have debian already running on my pi and have set up VNC so that it probably wouldn't be necessary to have the monitor, keyboard etc.  But it can't hurt to have them.  I have an hdmi-dvi cable which I know works with the pi. 

Also I have a USB wireless which seems to work with the pi so it should be possible to get it hooked up to backspace wifi. 

I will bring my laptop in case it is needed. 

Scott

[Paul Stoffregen]

On 07/01/2012 03:32 PM, Scott Dixon wrote:

Hi, Paul,

Sounds like you have more than enough pieces. I have debian already running on my pi and have set up VNC so that it probably wouldn't be necessary to have the monitor, keyboard etc.  But it can't hurt to have them.  I have an hdmi-dvi cable which I know works with the pi. 

Also I have a USB wireless which seems to work with the pi so it should be possible to get it hooked up to backspace wifi. 

I will bring my laptop in case it is needed.

Great!

I'm hoping to port the Teensy Loader and maybe other GUI-based software.

[Thomas Lockney]

On Sun, Jul 1, 2012 at 2:43 PM, Paul Stoffregen <pa...@pjrc.com> wrote:
> USB power adaptor + USB Micro-B cable (to power the Raspberry Pi)

Make sure that adaptor supplies at least 1A - the Pi is very picky and
may not boot with less. Even though I've read about folks using
supplies that supposedly only put out 700mA -- I suspect they were
rated below the actual amperage.

[David Turnbull]

I was playing with WSPR on the Peaberry SDR today and came across this article:

Raspberry Pi / Linux Debian Wheezy / WSPR
http://wsprnet.org/drupal/node/3510

-david

[Doug Ausmus]

I am very interested in what you all figure out this evening and what
you do for the Pi although I am out of town all week and will not be
at the meeting- will someone take notes and write something up that
those up still waiting for our Pi's can follow at a later date?

-Doug

[Paul Stoffregen]

On 07/01/2012 03:52 PM, Thomas Lockney wrote:
> On Sun, Jul 1, 2012 at 2:43 PM, Paul Stoffregen<pa...@pjrc.com> wrote:
>> USB power adaptor + USB Micro-B cable (to power the Raspberry Pi)
> Make sure that adaptor supplies at least 1A - the Pi is very picky and
> may not boot with less.

Yup, check, 1 amp rated power adaptor.

I'm heading out now with only 1 errand along the way, so should be there
pretty early around 6.

If anyone's there early with a Raspberry Pi, please let me know.
Looking forward to giving it a try!!

[Joel]

Just for clarity on this point: I worked with the BB a while back, and the Beagleboard doesn't actually do HDMI at all.  Apparently DVI does not necessarily mean HDMI, although the reverse may be true.  BeagleBoard just chose the HDMI<->DVI cable for the phsyical properties of the HDMI connector (it's smaller, makes board layout nicer, etc), and made lots of effort to make sure that it was DVI over a converter cable, and not full HDMI.

That said, how did this go?  I haven't dug into my Pi yet either, and have ambitions of running emulators on it, but have no clue how feasible that is, and haven't looked into it much yet.

Joel

[Paul Stoffregen]

> 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.....

[Monty Goodson]

Not having any experience with embedded linux I'm wondering: Is it necessary to compile on the Raspberry Pi, or could it possibly done offline on a more powerful machine? Does a Raspberry Pi VM exist?

How long was the USB cable? I've seen >1V drop at 1A across a cheap 2m cable, so I could easily see it not working with a powered hub that was on the lower-end of its output spec'd voltage, but perhaps would work with a short cable.

Monty

[Paul Stoffregen]

On 07/03/2012 07:37 PM, Monty Goodson wrote:
> Not having any experience with embedded linux I'm wondering: Is it necessary to compile on the Raspberry Pi, or could it possibly done offline on a more powerful machine? Does a Raspberry Pi VM exist?

There are cross compilers and VMs. I considered that.

The trick with cross compiling a GUI app is first getting the completely
cross environment set up. It's relatively easy to cross compile "bare
metal" or console-only applications that don't link to lots of
libraries. Compiling GUI apps that link to many system libraries, and
testing the actual compiled output so it actually works with the
libraries present on the target... that's is another matter! It's
possible in theory, but to get it all set up properly takes a huge
amount of knowledge, experience and fiddling. Compiling natively,
though slow, leverages the already-working packages from Debian's apt-get.

From what I read, the VMs might be very slow.

Cross compiling is fast, but getting all the target libraries right on
the host is far beyond the work I'm willing to put into this.

> How long was the USB cable?

About 3 feet.

> I've seen>1V drop at 1A across a cheap 2m cable, so I could easily see it not working with a powered hub that was on the lower-end of its output spec'd voltage, but perhaps would work with a short cable.

The same cable worked fine with Scott's power adaptor, but not mine.
The cable I-R drop might have been an issue. I only brought that 1
micro-B cable (and a LOT of other stuff) last night. I'll try the power
adaptor with a short cable later this week.

[Dave Edick]

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.  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.

Some references...

http://forum.xda-developers.com/showthread.php?t=1005633

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=4076

[Paul Stoffregen]

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:

http://www.tomshardware.com/charts/2011-micro-sdhc-charts/Random-Write-4-KB-QD-1-MB-s,2750.html

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.

[Erik Walthinsen]

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.....

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.

Anyway, enough rambling for now, back to cleaning the house.....

[Scott Dixon]

Paul, I will try to benchmark that SD card tonight if I have time. I hadn't realized how much variation there is.
Scott

[Paul Stoffregen]

My Raspberry Pi adventure continues today....

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.

[David Madden]

On 7/5/2012 15:32, Paul Stoffregen wrote:
> 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

[Chris Goodwin]

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. 

--
Chris Goodwin
cgoo...@gmail.com

[Paul Stoffregen]

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......

--
Chris Goodwin
cgoo...@gmail.com

[Jerry Biehler]

Just thought I would let everyone know surplusgizmos is doing 50% off sale on all surplus items in the store this Saturday the 9th.

[Blain C]

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

[Jerry Biehler]

There should have been adapters down there. 

-Jerry

[Blain C]

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.

-Blain

[Jerry Biehler]

Oh well. That's life.

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

[Blain C]

Good to know. Thanks. :P

[Brett]

On 07/04/2012 01:39 PM, Erik Walthinsen wrote:
> 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.

Brett