Turn on my /swap partition?


Since you're doing so much more with your card than I am, might it be wise to have the OS and the applications on a journaled file system? Ext{3,4}?
 
Since you're doing so much more with your card than I am, might it be wise to have the OS and the applications on a journaled file system? Ext{3,4}?

I've considered it, but have so far stuck with ext2 for pretty much the same reason most people stick to fat - desktop use. Desktop Linux is fine with an ext2 volume being dismounted and ejected as portable media. It can get grumpy with ext3 and ext4 being used as USB hot-plug devices. It might be better on current distributions though. One of those 'burn me once' things. I may have to give it another shot though since I'm going through the steps.
 
^ If it's Class 6 or Class 10, that's probably contributing to it.


Ever since the first units shipped, certain types have cards - usually of those speeds - have had issues (usually relating to poor controller chips in the cards - as is advised about for some cards on the wiki's SD Compatibility List), especially if formatted with one of the ext* filesystems, which go as far as preventing the machine from shutting down properly, even if you're running from the NAND.

"If it's Class 6 or Class 10, that's probably contributing to it"


I'm firmly convinced that is a myth started by people with class 2 and 4 cards (jealousy) and perpetuated by people who buy cards from disreputable sources trying to get "a deal" (cheap). Putting a class 2 or even 4 card in a Pandora is like tying kids shoes together because it's 'safer' to go slower.
To be honest, it isn't. There really are cards that have bad controller chips that cause these sorts of problems, and these controllers appear in all Classes, but seemingly more often in Class 6 and Class 10 cards. I point it out because I was burned by it with a very expensive Class 6 card from a well-known media-manufacturer (Verbatim). A great many issues folks have reported with SD Cards here, almost always trace back to using cards with these iffy controllers - that's exacerbated by the fact that some manufacturers (such as Kingston, to cite a notorious example) chuck whatever they currently have into their current batches, which then leads to people disbelieving it because "My [card that's warned about on the compatibility list is fine], so everyone claiming otherwise must be wrong, jealous, or have a fake.", and they aren't aware of this manufacturing reality.


Are you sure that convincing yourself that this fact is merely a myth started via "jealousy" and perpetuated by people who've bought fake cards (something I'm sure you're well aware I haven't been afflicted by on either count, myself :p ), isn't just trying to convince one's self that the extra spend wasn't a waste? ;)
 
Last edited by a moderator:
Are you sure that convincing yourself that this fact is merely a myth started via "jealousy" and perpetuated by people who've bought fake cards (something I'm sure you're well aware I haven't been afflicted by on either count, myself :p ), isn't just trying to convince one's self that the extra spend wasn't a waste? ;)

Yep. I'm sure. Having my Pandora be able to multitask and shuffle data around 300-500% (or more) faster by spending $10 more on a (at the time) $100 card is a -bargain-. I own a 32GB Kingston Class 4 card. It reads at about 20% of the speed of the Patriot LX cards. What's your time worth?


Speed's just a question of money. How fast you wanna go? -Grease Rat in Mad Max
 
Are you sure that convincing yourself that this fact is merely a myth started via "jealousy" and perpetuated by people who've bought fake cards (something I'm sure you're well aware I haven't been afflicted by on either count, myself :p ), isn't just trying to convince one's self that the extra spend wasn't a waste? ;)

Yep. I'm sure. Having my Pandora be able to multitask and shuffle data around 300-500% (or more) faster by spending $10 more on a (at the time) $100 card is a -bargain-. I own a 32GB Kingston Class 4 card. It reads at about 20% of the speed of the Patriot LX cards. What's your time worth?


Speed's just a question of money. How fast you wanna go? -Grease Rat in Mad Max
I need stability more, and Class 6 cards weren't delivering it. ;)


For me, much more time was lost when files kept randomly getting eaten due to a bad controller in a top-of-the-line card that didn't handle small writes properly if the card was formatted as ext2, and I had to keep re-copying them over. It didn't help when said card later ate my entire novel (which, mercifully, I'd just backed up).


FAT32 and SanDisk Class 4s all the way is what works for me. I'm glad that higher speeds work for you, though. :)


EDIT: I should note that I work with relatively small files, and don't use the SD Card slots for OSes. A Class 4, which by my testing exceeds its Class as so many do, is perfect for that.


EDIT 2: Oops, I just noticed that you said "read", not "write"! As far as I know, reading speed is nothing to do with the Class marking whatsoever.
 
Last edited by a moderator:
Since you're doing so much more with your card than I am, might it be wise to have the OS and the applications on a journaled file system? Ext{3,4}?

I've considered it, but have so far stuck with ext2 for pretty much the same reason most people stick to fat - desktop use. Desktop Linux is fine with an ext2 volume being dismounted and ejected as portable media. It can get grumpy with ext3 and ext4 being used as USB hot-plug devices. It might be better on current distributions though. One of those 'burn me once' things. I may have to give it another shot though since I'm going through the steps.

Mount Failed


Unable to mount "PandOS":


Unknown file system 'ext4'


X Close


So much for ext4... :)
 
Ha, sorry for the bad advice. An hour after I posted that, I was all "wait, did that version of the kernel have ext4 in it?"

Interestingly enough, it let me format the partition as ext4 - but couldn't mount it. So - is it partially there?
 
Nah, something odd is up. How are you mounting it? When is it giving you the message that it cannot boot?


It may be possible that the uboot can't read the ext4 to boot off of it, but once you're past that part and your running off of the kernel, it can read/write ext4. My expertise wanes at this point.
 
I thought I should post a follow up to this.


At that point I re-partitioned and re-formatted two cards for use in my Pandora.


Card in slot 1 = Patriot LX 32GB SDHC


Card in slot 2 = Lexar Professional 128GB SDXC


/dev/mmcblk0p1 ext3 /media/PandOS 4.66 GiB


/dev/mmcblk0p2 linux-swap 1.86 GiB


/dev/mmcblk0p3 ext3 /media/PanData 23.56 GiB


/dev/mmcblk1p1 ext3 /media/PanMedia 122.97 GiB


What I found is that the ext3 partitions were reading and writing noticeably slower than the system did before. An attempt to write 16GB from my network media library to the /media/PanMedia device was still running at 20 hours when I killed it - the writes were that slow. Playback was occasionally choppy if both cards were in use despite the media files being held on their own card.


So, I re-formatted that partition to /dev/mmcblk1p1 ext2 /media/PanMedia 122.97 GiB. Copying that data to the card then ran in something less than 8 hours - started before I went to bed, was done sometime in between. Exact copy time unknown.


Playing games from /dev/mmcblk0p3 ext3 /media/PanData 23.56 GiB was also painful. Simple games like Vultures Eye that are normally "instant on" were taking tens of seconds to open. In that example a 90K save file for Vulture's Eye was taking 45-50 seconds to load. Leaning on my above experience with changing formats, I backed all of my data from this partition off to the 128GB card in the other slot, nuked the partition and re-formatted it as ext2 for: /dev/mmcblk0p3 ext2 /media/PanData 23.56 GiB.


At this point, Vulture's Eye starts instantly. My 90K save file loads in under a second.


I'm still booting from and running the OS on an ext3 partition on the Patriot LX 32GB SDHC card.


In the case of my cards on my Pandora, ext2 is performing much much better than ext3. ext3 functioned without error, but the performance hit was simply unacceptable.


There has been a suggestion of putting a flag on the ext3 partition's mount instruction. If I get ambitious about partitions and formats again, I'll give it a try. In the meantime, I would be interested to know what other's experiences are with their cards running ext3 vs ext2.


I wish we had a benchmark tool that worked at a file level inside formatted partitions. The dd benchmark on the SD compatibility site is good from a macro level, but functions at a device instead of formatted partition basis. From my experience there can clearly be a dramatic difference between the two.


So - does anyone have additional information? Is this result card based and I happen to have two very different cards from different manufacturers that happen to behave in similar fashion, or is this a more general result?


Thank you.
 
I wish we had a benchmark tool that worked at a file level inside formatted partitions. The dd benchmark on the SD compatibility site is good from a macro level, but functions at a device instead of formatted partition basis. From my experience there can clearly be a dramatic difference between the two.

This is a quick reply, I might test some later....


You can use dd on a file level, too. For example,



Code:
dd if=/dev/zero of=/media/sdcardname/file.img bs=1024k count=500
should write 512MB to file.img. Or is this not what you mean?
 
I wish we had a benchmark tool that worked at a file level inside formatted partitions. The dd benchmark on the SD compatibility site is good from a macro level, but functions at a device instead of formatted partition basis. From my experience there can clearly be a dramatic difference between the two.

This is a quick reply, I might test some later....


You can use dd on a file level, too. For example,



Code:
dd if=/dev/zero of=/media/sdcardname/file.img bs=1024k count=500
should write 512MB to file.img. Or is this not what you mean?

Cool - that will make a great write test. Is there a correlated dd command that could be run to force it to read through that same file? I.e. a read test we could use to go with it? (Obviously I'm not up to speed on dd syntax and function.)


Thanks!


Working from the cards I have in my Pandora at the moment:


Trying different counts to see where it starts to break down -if it breaks down and how many 'is enough' and what it does with different file sizes - is it caching some on the cards?


Using dd if=/dev/zero of=/media/sdcardname/file.img bs=1024k count=25


On ext2 formatted partition on a Lexar Professional 128GB SDXC card: 1.89264 s, 13.9 MB/s


On ext2 formatted partition on a Patriot LX 32GB SDHC card: 2.37753 s, 11.0 MB/s


On ext3 formatted partition on a Patriot LX 32GB SDHC card: 2.47238 s, 10.6 MB/s


Using dd if=/dev/zero of=/media/sdcardname/file.img bs=1024k count=250


On ext2 formatted partition on a Lexar Professional 128GB SDXC card: 27.8559 s, 9.4 MB/s


On ext2 formatted partition on a Patriot LX 32GB SDHC card: 39.6395 s, 6.6 MB/s


On ext3 formatted partition on a Patriot LX 32GB SDHC card: 60.1323 s, 4.4 MB/s


Using dd if=/dev/zero of=/media/sdcardname/file.img bs=1024k count=500


On ext2 formatted partition on a Lexar Professional 128GB SDXC card: 54.3133 s, 9.7 MB/s.


On ext2 formatted partition on a Patriot LX 32GB SDHC card: 81.0573 s, 6.5 MB/s


On ext3 formatted partition on a Patriot LX 32GB SDHC card: 138.173 s, 3.8 MB/s


At 250+ writes it's spreading things out pretty well.


The Lexar card holds up remarkably well under sustained writes.


The difference between ext2 and ext3 on the Patriot card is definitely 'there' on writes. From what I was seeing launching applications from it, though, it may be even worse on reads.


Does anyone else have some data points they can add to the thread? At this point these are all writes only.


Thanks!
 
Last edited by a moderator:
Cool - that will make a great write test. Is there a correlated dd command that could be run to force it to read through that same file? I.e. a read test we could use to go with it? (Obviously I'm not up to speed on dd syntax and function.)
Something like



Code:
dd if=/media/sdcardname/file.img of=/dev/null
should be a good read io test, read from file.img and output it into the null device. Other good examples can be found here: http://en.wikipedia.org/wiki/Dd_(Unix)


You can screw with the byte size per read and all that, though I'm far from an expert for super specific things.


dd wins the award for archaic unix-y fun. Much like iptables.
 
Last edited by a moderator:
Using the 524 MB file that the 500 count version of the write used in my last example:


Using dd if=/media/sdcardname/file.img of=/dev/null


On ext2 formatted partition on a Lexar Professional 128GB SDXC card: 30.5678 s, 17.2 MB/s


On ext2 formatted partition on a Patriot LX 32GB SDHC card: 32.7481 s, 16.0 MB/s


On ext3 formatted partition on a Patriot LX 32GB SDHC card: 33.3049 s, 15.7 MB/s


And now I'm confused. The results are good - but they don't reflect the application based results that I'd seen before between ext2 and ext3. I wonder what the difference was between loading data files in application vs what we're doing here with dd.


Every question's answer leads to more questions. Hmm... That is something to ponder. I may even have to take another card and set up some experimental partitions on it to run some additional scenarios.


In the meantime, if anyone is interested in creating some benchmark numbers for their own cards as above, please tack them onto the chain?


I'm not sure if it matters, but in case it does:


I'm clocked at 800Mhz @3. The Patriot card is in my left slot, the Lexar is in my right. The Pandora was plugged into an old BlackBerry OTG charger for the duration of the tests.


Thank you MrRob!

Sheesh - copy and paste one time in a message and the formatting flags go nuts.
 
Interesting that the reads perform similar. For the sake of science, two things pop into my head:


1. Is it possible that the left and the right card slots do have different speeds? Would be curious to reverse them and see if you get similar results.


2. And you might want to do a reboot after each individual dd command execution. It's possible that part of the file could be cached (though obviously not the whole thing, as you don't have the memory). Though of course that'll make the tests more of a hassle as you need to wait for boot.


Both those things could affect your results (or may not). Don't feel obligated to do any of them, I sometimes find playing games on my Pandora more fun than IO tests, ha. But I'm glad to help. :)
 
Back
Top