Sd card speed standards?

[theredbaron]

What is the fastest speed standard that the pyra supports? Both full and micro sd card? I searched the forum, and saw some info from 2 years ago, mainly about how they would need benchmarks after launch. As there are a few prototypes in the wild, and we are close to being close to shipping ( )I figured I would bring it up again.

Aka, if a sandisk extreme pro 170MB/s goes on sell, should I get it? Or is the Ultra 100MB/s already using all the available bandwidth? For the full size, is there any reason to go micro with adapter instead? I remember it at least use to have better random access, I think. Is this no longer the case? Is there any reason, outside of cost, to go lower capacity?

I use to love researching this stuff, but my job leaves little free time as of late, so I defer to y'all. Any advice given would be appreciated.

 

[Grench]

There are a lot of things that make the answers to those questions complicated.

To my understanding...
Internal microSDXC has a theoretical max of 100MB/s, but it is duplexed with the eMMC, so will be something less than that.
The left SDXC max should be 100MB/sec.
The right SDXC is created from scratch via electronic wizardry from GPIO lines and should max out around 48MB/s.
The eMMC part has a peak max of @200MB/s, but with the multiplexer for the microSDXC on it, drops to @170MB/s.

As far as what cards to buy for it today goes, my suggestion is "none". Capacities and card quality continue to progress and prices have usually declined over time. I have made the mistake several times of buying cards for devices before the device is made only to buy "better" cards once I have the device months or years later.

But yes, a good solution to group benchmarking and posting results to a centralized database would be fun.

 

[theredbaron]

I have no intention of buying anytime soon either, buying after mine ships probable. Was just wanting the info for when I do. Plus, just wanted to know as I could find no info.

So, if I were to mount /home, have it be the first sd card? Then the second for media, and the micro as a backup os? Best bet?

 

[levi]

I wouldn't bother buying a MicroSD for the internal slot to begin with. The only use presently is to put an OS on it and select that one from boot, but what's stopping you using the internal emmc to begin with?

As for the left slot, any card claiming above 104MBps must be with lying or using UHS2 or 3. The SD slots on the Pyra only support UHS1, and who knows what the UHS1 speed of any card that only gives you later UHS stats? They might have more RAM for buffering but who knows until we can benchmark it.

 

[docbroke]

So, if I were to mount /home, have it be the first sd card? Then the second for media, and the micro as a backup os? Best bet?

I would prefer to keep /home on eMMC, where all the "." files will live. Left SD card will mount on /home/SD1 or something like that where I will have my all data. This way if SD card is removed all my "." files will still be there. I will also sync all the "." files from eMMC to SD card to keep a backup ( a cron job running rsync will do). In future I am planning to use microSD for trying alternate OS ( ? android ) when they become available.

 

[levi]

In a standard debian setup, SD cards will get picked up by the automounter and put in /media/some_id. From there the dbp scanner should pick up any dbps and add them to the menu.

It's slightly unclear to me what the expected behaviour in terms of software writing .config and other dot files to /home/user. On the Pandora it was considered bad form for any pnd to do that, but clearly any debian packages you install will write their .config there, but should dbp-based software be precluded against doing the same any more?

 

[docbroke]

Mounting of any drive can be defined in /etc/fstab, where I plan to define mount position for my left SDcard, so it will always mount in a fix location. Other cards/pendrives may be allowed to automount at /media using udisks ( that's what default debian uses I guess), However I prefer to use udevil with vifm for automounting ( inplace of udisks with gvfs and thunar/pcmanfm).

Ideally no software should touch users /home directory and "." files, they should write their config in /etc or should provide sample config files in docs. So that user can copy that manually to his/her /home/config and modify as per need. This also makes it easier to maintain personalized config files. In debian some softwares creates it's own config files in /home but only when such files are not present from before. Also no /home files should be removed automatically when software is uninstalled.
[doublepost=1566273478,1566273321][/doublepost]It shouldn't matter much for DBP scanner though, as it is trivial job to find mounted media, using command like "lsblk" or "mount"

 

[levi]

Software can only write new files under /etc if they're run as root, and you really don't want to run everything as root. /home/user/.config is the right place for most stuff to put its configuration.

The idea on Pandora partly came about because it had a tiny internal flash drive where the OS was installed, so writing megabytes to /home risked filling it up. The other reason was to make software more modular, so that if instead config files get written into the appdata folder on the SD card, so that if you remove the card all of your configuration goes with it. I tend to think the latter still applies to dbps on the Pyra, even if the reasoning behind the former applies much less with 32GB of flash to hand.

 

[docbroke]

You got me wrong there. Software do not run as root but they are installed by root ( otherwise how they will end up in /bin or /usr/bin ). The default config files in /etc are created at the time of installation, from that user can copy the config to /home/config. These are not modified except at the time of software installation/upgrade. However for DBPs or PNDs that are never installed to the system but runs from SD card, writing config to /etc or any system folder is out of question (unless it is run as root, which is not a good option), so only safe option is to keep config on sd card or write to /home/config. I feel both options are fine. Only issue I see is possibility that DBP may overwrite some config files already present in /home/config.

 

[Grench]

I wouldn't bother buying a MicroSD for the internal slot to begin with. The only use presently is to put an OS on it and select that one from boot, but what's stopping you using the internal emmc to begin with?

32GB vs up to 1TB in a simplified single file system?
Anyone planning to use just the 32GB eMMC? Enough for OS and quite a few apps sure, but media files?
I could see using just the micoSDXC and leaving the eMMC as a recovery/rescue OS. Put the world on the microSDXC and use the two front slots for on/offloading/copying SDXC media.

As for the left slot, any card claiming above 104MBps must be with lying or using UHS2 or 3. The SD slots on the Pyra only support UHS1, and who knows what the UHS1 speed of any card that only gives you later UHS stats? They might have more RAM for buffering but who knows until we can benchmark it.

Agreed. We need someone to write a card/device benchmak app that gives the user to opt to upload the card info and results to a central repository. Likely won't happen until well into general release though. All the current devs are working more important stuff.

 

[docbroke]

32GB vs up to 1TB in a simplified single file system?
Anyone planning to use just the 32GB eMMC? Enough for OS and quite a few apps sure, but media files?
I could see using just the micoSDXC and leaving the eMMC as a recovery/rescue OS. Put the world on the microSDXC and use the two front slots for on/offloading/copying SDXC media.

That is putting all eggs in single bin.
I would say 32 GB microSD should be enough for alternate OS. I would prefer to put main OS on eMMC. eMMC will be faster (AFAIK) so OS and apps can load quicker from that. All the data ( large files, music, movies, games) can be kept on left slot SD card, which will serve both main OS and alternate OS.

Another advantage of this is if something fails ( OS fails to boot or some issue you can't figure out quick enough), you can simply wipe your microSD or eMMC and reinstall the OS, no need to worry about loosing any of the data.

 

[levi]

However for DBPs or PNDs that are never installed to the system but runs from SD card, writing config to /etc or any system folder is out of question (unless it is run as root, which is not a good option), so only safe option is to keep config on sd card or write to /home/config. I feel both options are fine. Only issue I see is possibility that DBP may overwrite some config files already present in /home/config.

Assuming the DBP system is somewhat equivalent to the PND system, it doesn't do anything to the applications configurations, it just handles mounting the .dbp and running the executable. It's then up to the application to spit out it's configuration as required, just as it normally is.

@Grench Media on the OS partition? That's why the device has two full sized SD slots!