Quite a bit for you to read!


well i allready planned to place a huge uSD instead of using the fast eMMC. I could use than my pyra as a backup of my Images and Music from that bulky Desktop PC xD
Even though a uSD is still fast from my point of view.
That 'slowed down' eMMC is not an issue for me. Skip skip skip skip skip. The improved speedup can be addressed in future CPU boards.
Pleeease focus on more important stuff. (cannot wait any more) I want a Pyra in my Hands.
 
There seem to be many people here who think that a reduction of an already fast flash storage's "max speed" would have a heavy influence, that if it's 100MB/s instead of 190MB/s, the system might feel half as fast, so I've wanted to provide some information about why this is generally not how that works: http://www.anandtech.com/show/2614/7 (and the following pages). This is a well-know article from back when the first really good SSD, the Intel X25-M, came to market.

At the time, SSD manufacturers were focussing on high sequential transfer speeds. Intel's X25-M was "slower" than many of those SSDs in that it had a lower maximum transfer rate, but Intel had focussed on the actual benefit of SSDs compared to HDDs: fast random access. Intel's SSD had more reliable IOPS (Input/Output Operations per Second), resulting in systems with X25-Ms being much faster than many other systems with SSDs that had higher maximum sequential speeds. This is why today, when you see SSD benchmarks, there are various numbers for differently-sized accesses (and there are some other factors, too, but those are not relevant in this case). For application performance, random accesses are important. The maximum sequential transfer rate has turned out to be not anywhere as important.

If you have never read that Anandtech article (at least from the point on that I've linked above), then I highly recommend doing that. It was responsible for a fundamental change in how SSDs get made.
 
WTF??
You are wasting your time with that?
I'd rather finally see the real Pyra OS working than to waste time with that issue I don't care much.
zmatt is not the one working on the OS, that's aTc.
Besides, the speed test was just a side product of various hardware tests zmatt is doing so we can make some last fixes if need be (and there are various. Mostly small ones like changing a resistor, coil or whatever, but they improve the stability).
 
I feel like the right way to solve this is to use these boards and give the people who get a slower board a discount on EDs store so they can get a new board later if it's a big deal for them or if it's not a big deal they can get something else. Just an idé. I wonder how much similar stuff happens with development that are not open and people just don't ever notice. Probably all the time. I know that the Nintendo 3DS switched displayed about half way after launch and there weren't much talk about it.
 
Are you sure?
Fine, it doesn't have a "feature" that anyone knows about. Thanks to EvilDragon's openness people are going to know about this. This is not an argument against openness, I 100% support him and his decisions, I'm just being cautionary for when an end user, possibly one with a review blog, starts asking questions.

Devastating? like... it doesn't work? it explode when use? Are you sure that word is the right one.
It's obviously an exaggeration, but you should've been able to understand the point.

Fine. And what it might be?
I don't know, you don't know, none of us can possibly know and that is the point. By saying "it's ok that the eMMC is crippled by the MUX because it's fast enough anyway" you are making an assumption about the entire user-base. It may be ok for 99% of people, but what if there's 1% where they would not just prefer the MUX wasn't there, but the extra 70MB/s would've actually enabled something they could otherwise have done?

I don't understand the distinction you're trying to make. All properties of a design can be considered results of decisions someone made at some point.
What decisions were made that causes people to have problems with their wifi on the Pandora? Do you know them? Because I don't. Never heard of any such thing.
On the other hand we can point out exactly what decision was made here, why it was made, and present an argument as to why it was the wrong decision.
That's the distinction.

Look, the whole point was in trying to market this correctly: if someone does a benchmark and discovers the eMMC is only going 60% of the theoretical maximum and starts asking why, there's a pretty good chance they're going to find EDs comment about the MUXer and know that . Are we going to address their comments by simply saying "eh, it's fast enough, stop complaining"? Or do you want to have a real answer that doesn't make us look like dicks?
 
Fine, it doesn't have a "feature" that anyone knows about. Thanks to EvilDragon's openness people are going to know about this. This is not an argument against openness, I 100% support him and his decisions, I'm just being cautionary for when an end user, possibly one with a review blog, starts asking questions.
At this stage though with the MUX stripped out it seems that it's still not going to hit 192mb/s, but we shall see first.
 
Looks like for some of us the Pyra is actually a spec upgrade to our desktop systems, haha.

Yep. My actual desktop was a refurb when I got it in 2011. I only really use it occasionally for video editing, otherwise I use the Pandora or a Pi2 setup as a minimal desktop.
 
So how could we fix it?
Most likely, there's no MUXer available that would be fast enough.
An eMMC is usually not MUXed, only SD Cards are. And eMMC are capable of being a lot faster than any existing SD Card. That's why these MUXers have no reason to be faster.

A possible fix would be MUXing the MicroSD slot with the SD Slot 2.
That means you can't use both at the same time (unless someone writes a driver for that, as it is possible!), but you can switch between both on-the-fly (without rebooting).

We'll try to make real life tests with both a MUXed and unMUXed eMMC as soon as possible (but it needs a modification on the CPU Board, so it won't happen within a day or two).

My take would be, in case the speed impediment is significant: Drop the muxer and the internal Micro SD capability.
Keep full speed eMMC. Internal eMMC and two SD Card slots, similar to the Pandora. The internal Micro SD was imho nice to have, but not a dealbreaker by far.

And, ignorant as I probably am, I'd think that could be implemented on the current CPU board by mounting different parts ...?
 
@ED
When I said loading data, then mentioned video , I meant loading the video up into the app for minor video editing(ie loading data as opposed to streaming it), ie not playing videos. I do make videos on youtube and it would be handy to have something to make minor edits with on the road..

I'm not sure you know how video editing works... it doesn't load the video you're editing into RAM, heck, that would be horrible!

As you might know, I'm doing video editing as my main job and I've got projects with video clips of more than 100GB... if it would load everything into RAM first, it would take AGES to load a project (and I'd need about 500GB RAM in my system as well).

Videos are made for editing / streaming, which means they have an index.
If your video editing software requests to go to 3:01min in the video, it doesn't LOAD the video up until then, it just jumps there in the file (so it would load about 10 - 20 MB, depending on the video compression and how much it buffers)

The eMMC is probably more than 3 times faster than what you need here.

But it's not just that, it's everytime it reads the emmc, there is that little hit speed wise. If you have an app that makes lots of regular reads, that adds up ,.

Nope, not at all. The time the program needs to request the files, process the data, etc. is probably 5 - 10 times higher than the loading time of the files, the eMMC also needs to seek there.

That's one of the reasons reading a lot of tiny files from an eMMC (or any other storage) is a lot slower than reading big files.
So you won't even get close to the eMMC Bus limit we have right now in most cases (if ever).

Also as I mentioned if you play games that like to load next stage data regularly , it can be a little taxing. etc etc.

I can't think of any game where that difference (probably around 40MB/s) would be noticeable, unless they're very badly coded (or way too heavy for the processor anyways).

If the next level needs to load 100MB more data, the difference is about 0,3s.
So yeah, if the next level is 500MB (half a gig!) of data, then it would take about 1,5s longer to load the level (and then only if the game is actually able to process the data in fullspeed).

How many games are there that need to load THAT much data for a level?
That sounds like "too big for the system" or horribly bad coding.

And properly coded games that have huge data often load stuff in the background. While you're running around, it already buffers the next area, so you won't even have an issue here.

I'm not sure what games you expect to run on the Pyra though :)
Maybe give some examples.

The process along the way has been a step by step stripping down of my wants for the Pyra.

How so? AFAIK, the eMMC speed right now (which seems to not really be an issue at all) is the only thing that comes to my mind. Everything else has been UPGRADED from the initial announcement (except for a 1080p screen, but that was NEVER a sure thing).
And eMMC speed was never even in the specs and is still faster than most mobile devices...?

2) There was the SOC selected which was another let down for me. Not the SOC I'd expect to have in an $800AUD device.

Ah, wait. The SoC was clear a LONG time before the ordering even started.
How can THAT lower the expectations AFTER ordering?

3) Then there was the emmc being just 32GB. That really put me on the razor edge.

... which initially was planned with 4GB, so a huge step up as well.

Sure a biigger emmc option would be more, as with the 30 euro extra for a 4GB RAM option, a number of people probably would have taken the option up though.

Which isn't even feasible, as you have a minimum order quantity of parts.
I cannot simply order 300x32GB eMMCs and 50x128GB eMMCs.
Okay, sure, I could, but then the price would be triple as high (as it would be less than the minimum order quantity).

Additionally, the part needs to be changed during the production run as well, which would mean higher costs as well.

4) Of course the emmc speed possibly being handicapped , is as I said, the straw that tipped me.

Yes, but you still keep insisting it's an issue even though in all use cases you told me, it doesn't even affect anything.

Unless your hobby is to copy huge files to the eMMC and back the whole day, you won't notice a difference.

You know I have backed the Pyra for a long time now, even on a number of occasions writing into tech sites to get stories written up about it. So thats to say, this isn't a hate campaign. I wrote what I wrote because it's how I feel, I know it's not going to resonate with everyone. But if anything, it gives an insight into at least my perspective.

I don't see it as a hate campaign, I just don't see why you still think the eMMC is horribly crippled when in reality, it turned out it isn't so far.

At this stage though with the MUX stripped out it seems that it's still not going to hit 192mb/s, but we shall see first.

That will never happen, as that's the theoretical maximum speed from the datasheet (meaning: no OS overhead, no filesystem, no anything).
 
Everything else has been UPGRADED from the initial announcement (except for a 1080p screen, but that was NEVER a sure thing).
And eMMC speed was never even in the specs and is still faster than most mobile devices

One question remains for me: when can we start playing with our own Pyras? :p

Exciting times :)
 
ED

Again, I'm not saying the emmc speed makes it horribly crippled. I'm saying it was the straw that broke the camels back for me. Are you not familar with that term?. It means it it was the small thing that tipped me. Well not anymore , seeing as you guys seem to have gone a long way to address the issue.

Also, the process I talk about in regards to my confidence being gradually stripped away from buying the Pyra, goes back from the beginning of the project. Some of your comments like below seem like you didn't grasp that. I'm talking about the journey I have gone through learning the finalised cost and different specs - and trying to convince myself to still buy the Pyra despite some things I don't like starting to add up. This goes back to the beginning, ie has nothing to do with the timing of orders. By the way, I have not pre-ordered. I'm still watching to see how it all it all turns out in the end

"Ah, wait. The SoC was clear a LONG time before the ordering even started.
How can THAT lower the expectations AFTER ordering?"


As for the emmc being initially planned to be lower, Yes, 4GB would have seen me out also, but then I remember comments that it would be reviewed , which is why I waited to see. And it did happen that way . Then I remember there was a plan to go with mayhbe 16GB . Which I thought was too low and would have been an out for me yet again. But that changed to 32GB and I was back in the game . But still 32GB was right on the edge for me.



As I said at the end of my last comment though, it seems there now isn't a emmc speed issue. So all is good
 
Last edited:
That will never happen, as that's the theoretical maximum speed from the datasheet (meaning: no OS overhead, no filesystem, no anything).
Thought so, which means it's settled! The eMMC should be good as is!
That's great as we don't have to remove the MicroSD slot or waste 70,000! :)
 
... For the Pyra, ED made a design decision with devastating unintended consequences ...
... Here, a decision was made and there's a very good argument that it was the wrong decision ...

I think you're wrong here. The decision was made in order to provide an additional uSD socket. And therefor the Pyra Devs introduced the Muxer. After that 'right decision' it exposed that the Muxer couldn't fully utilise the emmc transfer rates. That's all. Nothing wrong here. Then they make tests and they showed that the transfer speeds are in a superb range (for a handheld device) and doesn't hamper the utilization of the device in 99% of the usage scenarios.

Congratulations to the Pyra dev team. Please go ahead and bring this extraordinary device to our Pyra community.
 
I have serious doubts that any change regarding this issue would actually turn out to be an improvement in the device overall. In the vast majority use cases whatever you are doing with the data on the eMMC drive will end up taking longer than the data will transfer to memory regardless. As for transferring data between the eMMC and any other place it could exist (SD card, external drive with ESATA external drive with USB, network storage), the eMMC will still be faster than the other interfaces can handle. These factors combined mean that you would spend much more time transferring data back and forth to the eMMC than you could ever save by putting the data there so it could be accessed faster than on the SD card.

I am a pretty patient person when it comes to being willing to wait for the makers of the device getting it right the first time. That doesn't mean I don't want my Pyra sooner rather than later. It just means I want the best device reasonably possible. That seems to be ED's goal as well, so I'm pretty satisfied by the process, even if I don't have the device yet.
 
Just to put it into perspective,, this is not even touching iops
Samsung EVO, usb2 adapter,, you can't get much better than this for small file speed
Of course,, u1 will be faster for large files,, maybe 48 mB/s

Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 3032 2814 6219 6224 6226 2661
102400 16 11939 12308 15989 15892 15826 12408
102400 512 31222 31314 33607 33648 33089 31039
102400 1024 31422 31533 33706 33888 33625 31558
102400 16384 31743 31650 33930 33991 33903 31717
 
Im thinking its gonna take a few more months of testing, checking hardware and with zmatts work etc - little things.

Im not hopeful for a summer release at this point. November/december maybe. So I will wait.
 
I realize it may be a waste of minor amounts of time, but if I understand things correctly, @zmatt will shortly be in possession of the board that @hns did microsurgery on AND one that has not had this modification.

I propose that he divert 20 minutes of his admittedly very precious time to perform some very basic tests.

Using the same OS image and a simple stopwatch, generate 4 metrics.
#1. Cold to booted time for the modified MUXless eMMC.
#2. Cold to booted time for the unmodified MUXed eMMC.
#3. Cold to booted time for the unmodified MUXed uSD (please include brand/model of card used).
#4. Cold to booted time for the left SDXC (please include brand/model of card used).

My prediction is that the difference between #1 and #2 will be within the boundaries of human error of thumb on stopwatch.

#3 and #4 are requested to give relevance to #1 and #2.

If someone with a dev board is so inclined and has the same image, they could run the equivalency for the eMMC and SDXC for the dev board. That would add further relevance to the Pyra results.

This would give us relevant "real world use case" numbers and maybe calm things down a bit?
 
Im thinking its gonna take a few more months of testing, checking hardware and with zmatts work etc - little things.

Im not hopeful for a summer release at this point. November/december maybe. So I will wait.
+1. i'd rather wait for a device the devs and users are happy with than hardware that needs a wiki full of workarounds for issues that could've been fixed with a little bit more time. especially after the switch hardware issues, that iphone antenna bug, and samsung's battery fireworks. and all those other big and small fails that made you think "how could they not have noticed and fixed this before release?".
 
Back
Top