Quite a bit for you to read!

[remjey]

I wanted to add that to my knowledge, very few SD cards have good random access speeds. Often when they advertise several tens of sequential MB/s they will only provide 2 or even 1 random MB/s in benchmarks. This is where the eMMC will be superior to the SD cards, as OS often use more random access than sequential. There are filesystems though that claim to make SD cards better supports for OSs like f2fs or nilfs2.

Anyway I’d be really happy if ED could sell SD cards on his shop that have interesting specs and have been benchmarked by him or a trustworthy person. I’d certainly buy all my SD cards there and I’m pretty sure I’d not be the only one.

 

[EvilDragon]

We don't even know the current speed.

Posted by hns earlier in the thread, he had around 70 - 80 MB/s on the eMMC on a first test.
We haven't poked around much yet though.

 

[Binky]

Anyway I’d be really happy if ED could sell SD cards on his shop that have interesting specs and have been benchmarked by him or a trustworthy person. I’d certainly buy all my SD cards there and I’m pretty sure I’d not be the only one.

Definitely.
Given that even major high-street retailers (WHSmith, Tesco, etc) can't keep their supply chains secure, I'd be happy to pay a fair bit extra for cards that consistently perform as advertised.

 

[Grench]

Definitely.
Given that even major high-street retailers (WHSmith, Tesco, etc) can't keep their supply chains secure, I'd be happy to pay a fair bit extra for cards that consistently perform as advertised.

If anyone can find a reliable decode method for how Sandisk names their cards, let me know. They have recycled the same terms to so many generations of silicone that it is very difficult to even link a benchmark to an actual product.

It does seem that there is a hole in the marketplace for cards guaranteed by the retailer to perform at benchmarked speeds on a specific device.

I'm really interested in how the newer V30 Sandisk microSD cards would perform in the Pyra's internal microSD slot. So I looked into their performance stats on other devices and tried to parse the naming conventions and model numbers and - gave up for now. It is a mess.

 

[Christoph.Krn]

Anyway I’d be really happy if ED could sell SD cards on his shop that have interesting specs and have been benchmarked by him or a trustworthy person. I’d certainly buy all my SD cards there and I’m pretty sure I’d not be the only one.

A few years back, I tried a few brands and eventually settled for Panasonic Gold (only the ones with the golden label!) as "OS root" type SD cards. The ones that I have used have had reliable performance with good IOPS figures (though I've encountered a few reports to the contrary), and Panasonic's cards are apparently pretty reliable in general. Though like I've said, that was several years ago, maybe things have changed. The quality of Panasonic's cards probably hasn't changed much, but maybe there are better ones (i.e., more reliable ones) out there now. Unfortunately there are very few meaningful tests and benchmarks.

There are also industrial grade SD cards for use in embedded applications, by the way. Those can be difficult to find because they're more expensive than the consumer stuff (some of them are SLC, even). I've always thought that those might be a good fit for the Dragonbox shop, and as a manufacturer of the Pandora and Pyra, it might be worthwile for OpenPandora GmbH to ask about reliability and performance figures directly at the manufacturers.

 

[asimov-solensan]

Is always great to have some news. At this point I understand people's axiety, even in my case. I bought an android tablet with a keyboard case to do some tasks that Pandora is just not enough (power, resolution, connectivity, ...) and realized how crippled this OS is for productivity, which makes me want even more.

Maybe I'm pessimist but right now I don't expect a Pyra for 2017 and I'm a pre-preorder. I just wish good luck to the team, it's a pain that this takes so long.

 

[Grench]

If I understand how booting works in these sort of devices at all, you'll probably need a working version of uboot installed on a card in the left slot to allow booting of the OS on microSD, I think. If the eMMC is still functional, it'll use uboot on there if no full-sized SD cards containing uboot are present.

To my understanding:
A copy of uboot is required to be present on the bus that controls the eMMC/microSDXC OR the left SDXC slot.
The eMMC/microSDXC MUX switch is set to default to the eMMC.
The work to have both the eMMC and microSDXC slots both available is ongoing. So far, both can work but the eMMC is forced down to speeds expected from very fast microSDXC media.

My extrapolations:
1. If an SoC daughterboard were configured without the MUX and wired to only the eMMC, the microSDXC slot becomes vestigil. If uboot exists on the eMMC, it should use that to boot. I think this option is likely what @hns was referencing when writing about doing some micro surgery on an SoC board to test the eMMC under more ideal conditions (for the eMMC).

2. If an SoC daughterboard were configured without the MUX (or the MUX set to default to microSDXC) and wired to only the microSDXC, the eMMC could/becomes vestigil. If uboot exists on the microSDXC card, it should use that to boot. This is the option that I was referencing as an option that could be explored for the existing 570 boards. In this scenario, the system would hypothetically operate solely on removable media with uboot and the OS on a card in either the microSDXC or left SDXC slot.

Personally I'm OK with any of the options. I even see some benefits to the concept of a 'Removable media only' version of the Pyra.

 

[wdt]

eMMC have some advantage,, small files write
tkaiser at armbian has done much testing on uSD for SBC,,
the command to find how BAD a card is ,, is
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
(cd to mounted SD, run command)
Most cards are terrible for the 4K & 16K writes
Bottom line,, for reasonable price Samsung EVO, EVO+ (32gB or bigger)
90th percentile or better

 

[vcoleiro1]

Here's some crystal mark tests run on the emmc in the GPD WIN


www.youtube.com/watch?v=MRXOVT-dNOA - See the 6:39 mark

and:

 

[wdt]

The 4K read is surprisingly low
But the write is quite good,
the samsung has 4K write about 12% of full speed,
many cards are a magnitude or more worse,
some more than 2 magnitudes
ie apt-get -upgrade, go away, come back in a day,
if it hasn't crashed

 

[Pocak]

Currently he can only clock it at 142MHz which results in ~70MBps reads (which suggests a 4-bit bus to me, giving a full byte every two ticks). If that's right, 192MHz would result in ~95MBps only.

Perhaps they disabled the upper 4 bits because of the time skew (those lines don't go through the muxer, and thus are not delayed.) With no mux, the full 8 bits could be enabled, giving the claimed 192MB/s @ 192Mhz.

 

[slaeshjag]

No, it has already been figured out that the 142 MHz speed is rounded down. So far, it's running in 8-bit mode. It really shouldn't work at that speed according to the specs, so I'd say more testing is needed, primarily at different work-loads (power-noise etc.) and temperature (it'll get slower as it heats up).

 

[EvilDragon]

Here's some crystal mark tests run on the emmc in the GPD WIN


www.youtube.com/watch?v=MRXOVT-dNOA - See the 6:39 mark

and:

Mine doesn't go higher than 85MB/s. Rev. 2

 

[vcoleiro1]

@ED

I just downloaded CrystalMark 5.2.1 on my GPD WIN and ran it just now.

I got similar results to those in my previous post ie: what others have shown. Write speeds though seem to be even higher

Here are my results - this is my GPD WIN screenshot:

 

[EvilDragon]

Very very weird. I use HDTune (was always the most reliable for me), but wil check CrystalMark as well.

But that's where the fun starts... if different benchmarks show such a huge difference in values, something is weird.

Ah, reminds me: CrystalDiskMark doesn't show cached readings, does it? As that value would be totally useless.
It needs to benchmark uncached reads.

What's especially weird here are the huge differences between sequential and random reads. They should be mostly the same with an eMMC or SSD, as far as I know.

 

[levi]

Perhaps block sizes come into play in flash reads, as well as flash writes? In that a sequential read can just read a block, store it in controller RAM and keep streaming it out, and even preload the next block in time. A random read will probably end up requesting a different block each time, so the controller needs to read that block in before it can chop it down to size to send back.

 

[vcoleiro1]

There is always a big difference between sequential and random reads/writes on both emmc and SD. However, since SD cards generally have very bad latency, SD cards have a much bigger difference between sequential and random reads/writes than you get with emmc. Particulary as the block size shrinks

For example, look at the following page showing comparisons between SD cards. Max Seq reads are in the high 90's for almost all the cards, and writes are not that far behind.
Now look at random 4K reads and writes. You get something like 9.051MB/s and 2.987MB/s

https://www.cameramemoryspeed.com/r...k-extreme-pro-95mbs-uhs-i-u3-256gb-sdxc-card/

 

[AndiTheBest]

I'm more on ED's opinion, benchmarks are not perfect. For all day use, the best comparison would be:
Take a standard pyra, a mux-removed pyra and maybe a gpd win.
Make a video and open for example gimp at the same time and look how big is the time difference until opened, after a fresh reboot (so it won't still stay in ram).
Then copy a 2gb file from/to the internal memory (emmc/ssd/whatever), so you have combined read/write on the same piece of memory.

I know the gpd-win test is different because of the operating system but would be just interesting.

 

[Eight Bit]

Yes, I'd like that.
Just some hands on tests. Maybe throw the Pandora in the mix too.

 

[vcoleiro1]

I'm not sure where all of this is going to be honest.

Frankly, I have the following question. Can the issue be addressed for future batches of the PCB?

If yes, then the only problem is how to off load the 570 issue boards . Since a number of the 1034 pre-orders have said they are willing to accept a board with the issue, then really the only thing to do here is email the pre-orders and ask them if they would take one of these boards. Tell them they will get it first as a carrot, and maybe ED could sign those boards also. I'm guessing ED will get around 570 acceptances. If there is a small shortfall, then sell the rest as signed mementos

If the PCB cannot be fixed for the next batch, then there will be a problem. As a number of people like myself are not going to buy a Pyra with a handicapped emmc.