Which is the fastest SD card for Pyra?


Ted

Member
Joined
May 2, 2016
Messages
101
Location
Beijing, China
As of today, which is the fastest SD card for Pyra?
How about the SanDisk Extreme PRO 256GB SD card?
 
depends on what the transfer speed turns out to be. there is no point in a card that is much faster than the transfer speed of the pyra.
 
As I understand it, the Pyra will support UHS 1, but not UHS 2 (it doesn't have the physical pins to make those cards go any faster). As such the SanDisk Extreme Pro range might be a good choice, but I wouldn't expect the largest capacity card to necessarily be the fastest - it's probably having to do more trickery to pack that much into the available physical space. While the 256GB card isn't the largest - there's now a 512GB one, but only available in Extreme Pro configuration, so I guess yields are flaky at best, it's the largest that appears to be properly in mass production. So a 128GB card may be faster.

Also, different generations of cards have different real world speeds. I came across the case of a SanDisc Ultra card that this year had an uprated top speed, but actual speeds especially write speeds took a bit of a tumble compared to last year's card. But that's a plain Ultra card, so a very different beast to an Extreme Pro.

In practice, the Pyra's SD slots will almost definitely have limitations that stop them reaching the speeds that other devices can - we don't know yet. IIRC someone did trawl through the schematics and work out the bandwidth the system dedicates to those slots though, but I don't remember the results.
 
The Pyra supports UHS 1 - 104 MByte/s (SDR104)

Which means Samsung Pro series with speeds: Read 90MB/s,Write 80MB/s will be the ideal sweet spot.
They will become more cheap and accessible, and they have 10 years of warranty.
 
The Pyra supports UHS 1 - 104 MByte/s (SDR104)
To be clear, this is definitely true on the eMMC bus (mmc2) which is used for the eMMC and internal uSD. Of the other 4 buses in the OMAP5430 specification, one operates at SDR104 (mmc1), another at max SDR50 (mmc5), and the other two at SDR25 (mmc3 and 4). I remember that in the OMAP5432 only 4 of those 5 are available, with one being used by the wifi, leaving only 2 possibilities for external slots. The problem is I can't remember which is which. If I dig deep into my memory and say the first thing that comes up I'd say mmc1 (SDR104) is the left hand slot, mmc3 is for the wlan, mmc4 (sdr25) in the right hand slot, and mmc5 was removed in the OMAP5432, but that could be complete bullshit.
 
To be clear, this is definitely true on the eMMC bus (mmc2) which is used for the eMMC and internal uSD. Of the other 4 buses in the OMAP5430 specification, one operates at SDR104 (mmc1), another at max SDR50 (mmc5), and the other two at SDR25 (mmc3 and 4). I remember that in the OMAP5432 only 4 of those 5 are available, with one being used by the wifi, leaving only 2 possibilities for external slots. The problem is I can't remember which is which. If I dig deep into my memory and say the first thing that comes up I'd say mmc1 (SDR104) is the left hand slot, mmc3 is for the wlan, mmc4 (sdr25) in the right hand slot, and mmc5 was removed in the OMAP5432, but that could be complete bullshit.

Which brings us back around to:
Sometime after a few Pyras are in the wild, a good project for someone to do would be to create a "Pyra SD card & slot benchmarking tool". Ideally this would allow the end user to benchmark microSD cards in all 3 slots (internal, left, right) and SD cards in the left & right slots and give the user the option to input card manufacture & model. The results would then, with users permission, be uploaded to a central repository. Not a tiny project. But, having a normalized method and a centralized database would allow us to quickly build a repository of knowledge to answer the OP's question. Bonus points if it allows benchmarking media in the USB ports as well.

Right now, the best SD card for the Pyra is the one you haven't bought yet. Cards keep improving in size and speed with the overall trend to cheaper per size and speed. General production release is months away. Let the prototypes go out and with any luck the users of those units can start giving some anecdotal feedback on what they are seeing with the different cards that they have access to. I'm trying very hard -not- to purchase any cards specifically for the Pyra until after my Pyra ships.
 
Such a database could be started by someone making a template form, and posting it in a new thread, so that data can be collated. I'll start with:
Code:
Make:
Model:
Year first available:
Speed benchmarked (MiB/s) read:
Speed benchmarked (MiB/s) write:

A benchmark tool would be welcome. Most benchmarks I've looked at destroyed whatever was on the card, and when I tried benchmarking my own media, I tried dding from /dev/random, but my machine wasn't able to give me random data at all rapidly, so I ended up using /dev/zero but that's easily compressible by any hardware layers between me and the drive, so still not ideal. Some benchmarking tool that doesn't destroy data, but uses genuinely complex data to test with would be good then.
 
Such a database could be started by someone making a template form, and posting it in a new thread, so that data can be collated. I'll start with:
Code:
Make:
Model:
Year first available:
Speed benchmarked (MiB/s) read:
Speed benchmarked (MiB/s) write:

A benchmark tool would be welcome. Most benchmarks I've looked at destroyed whatever was on the card, and when I tried benchmarking my own media, I tried dding from /dev/random, but my machine wasn't able to give me random data at all rapidly, so I ended up using /dev/zero but that's easily compressible by any hardware layers between me and the drive, so still not ideal. Some benchmarking tool that doesn't destroy data, but uses genuinely complex data to test with would be good then.

Since the Pyra is expected to have varying speeds by each of it's 3 card ports, the database would need read/write numbers for each. Bonus would be if it also had provisions by each of the 3 USB slots AND for the eSATA, so 7 categories of 'slot/port'?
 
That's true. Also, cards often behave differently depending on whether file reads and writes are contiguous or split amongst different sectors. Sometimes also transfer size can have an impact, especially on small blocks smaller than the card's block size.
 
Such a database could be started by someone making a template form, and posting it in a new thread, so that data can be collated. I'll start with:

... I tried dding from /dev/random, but my machine wasn't able to give me random data at all rapidly, so I ended up using /dev/zero but that's easily compressible by any hardware layers between me and the drive, so still not ideal.

Would dd-ing from "/dev/(u)random" into a file before dd-ing onto the sd-card help in this situation?
 
In Ubuntu/mint there is a drive benchmark tool:
https://help.ubuntu.com/stable/ubuntu-help/disk-benchmark.html
No, I'm still not a fan of Ubuntu - mostly due to Unity - which I know can be swapped out - but it still bugs me.

BUT - if I recall correctly from my last foray into it, there was a pretty good visual disk benchmark tool in it. I wonder if that or some other already built equivalent from the Debian repository might make a good 'core' to build something like this from?

Agreed that it needs to be non-destructive while still getting comparable benchmarks and recording which of the mixture of slots/ports it was done for. And - is there any compelling reason to restrict to just physical ports? How about something that can be run against any mounted file system? I.e. SSHFS volumes over network, WiFi portable disk drives, cloud drives, etc...?

So - it should detect and track on it's record:
User input card brand
User input card model - might be good to have it pull up an alphabetical pick list of previously input cards for the stated brand?
User input pyra boards screen name or anonymous (optional)
User notes about this test (optional)
Date of benchmark
Slot/port being benchmarked (left SD, right SD, internal uSD, USB 2.0 #1, USB 2.0 #2, USB 3.0 OTG as host, eSATA, Other)
If other 'slot', explanation of what this is. Ex: SSHFS volume

The resulting table should be able to feed a database that can be point & click queried in the FAQ to select the brand, card model and have it display back all tests performed on that card/device and maybe averages - though I doubt we'll all spend the time to generate dozens of tests of the same cards.

It would be very cool, but I don't have the knowledge or the time to gain the necessary knowledge to build it.
 
Back
Top