Quite a bit for you to read!


@ED,

Well upto a few seconds here and there to load things is annoying for me. By the way I also said loading data (video for example, next stages in a large games etc) ie so not just apps. That said, Is it a deal breaker in itself, no, and I have said that now 3-4 times. It is the last straw for me. The other things that put me off is the small emmc size itself, since I plan to use that almost solely. To be direct - I'm also not entirely happy with the SOC used. I know there was not much choice, so there's no blame for that. That said it doesn't change the fact that for me personnaly it's a dissappointment not to have a better SOC in a device that costs as much as the Pyra - and yes I understand why it costs as it does. Combine that with a few other things, and it all adds up to the straw that is the emmc speed for me.

I'm sure I'm going to get blasted by pretty much everyone, saying that everyone of those points are invalid becuase they personnaly have no issues with them. I appreciate for others that certain things weigh differently and that the SOC is more than fine for most and that even the emmc is fine for them.etc . I keep saying this, but each to their own. I just find it hard now personnaly for my likes and dislikes, to justify what is nearly $800 Australian (inc delivery) for a Pyra which has those niggling attributes that annoy me . Again each to their own.

It would be great if the issue is fixed, but from the sounds of your comments , it sounds like you are not planning to address the issue. Is that the case?

So dont buy one and stop complaining.
 
I too am surprised that vcoleiro plans to not even plug in an SD card to put DBPs on, but I thank him for stating those plans. It's not a use case I'd really considered, so it's valuable to know. I'm still not sure it's a big use case on a system with three SD slots, plus eSATA and USB ports, but it shows us that we shouldn't make assumptions.

I'd be interested to know what the write speed is like, and what the small block size rates are. 100MBps+ seq. read speeds are nice, but I don't plan to pull large files off me eMMC often myself - most likely I'll be loading small program files and config files. And if this really is delaying half of the bus lines, I'd like to know whether writes are reliable, as a corrupted OS is a bit of a faff to recover from. I'd guess testing that reads actually return the right data should be just as effective at proving the bus is reliable, so validated reads would be nice to have too (just sha256sum some biggish data, pop it on, pop it off and check the checksum).
 
I guess you mean size, since you don't know anything else about the eMMC... but you're aware that prices increase A LOT after 32GB?
So, for example, just using 64GB eMMC would've increased the price by about 40 EUR. Well, unless you want us to use a cheap eMMC, where the speed is pretty slow...
is there a "cheap" larger eMMC that is slower but not bottlenecked by the muxer? haha

Jokes aside, I still stand by my initial comment I am fine with this... realistically the user experience is minimally impaired.
 
It is the last straw for me.

Sad to see you (and anyone for that matter) jump off the Pyra ship. Gnarly specs were never my focus, but I feel the pain of people who do care about them.

Hate that manufacturers of pocketable SoCs and accompanying components cockblock enthusiasts and experimentators for years. They could be afraid of lukewarm profits, but Raspberry Pi and Arduino beginner packs did it for desktop-ish applications, didn't they?

Probably it's just too early for pocketable revolution because making a pocketable which wouldn't fall apart after 3 days of use is hard and expensive...
 
Its not looking like an issue for me. So it maybe could be many times faster but its still as fast or faster than your average mobile phone? I always thought all the storage slots were overkill to a certain degree anyhow. The pyra has many.
 
Even with some small setbacks, the pyra looks like it's going to be a massive upgrade to the Pandora.
And I'm pretty happy with my Pandora.

Strange to hear about the cases having issues due to being rushed, I hope that gets fixed.
I'm happy with the eMMC speeds being faster than 30 MBs for sequential read/write.
 
You launch it.. and ? Peoples just launched HDD bench on their GPD Win, they had results. And then what?
The GPD doesn't have a "feature" that has forced a speed reduction. For the Pyra, ED made a design decision with devastating unintended consequences. It doesn't matter whether 105MB/s is "fast enough", it isn't as fast as it would be if the MUX weren't there, and some users are going to pick up on that. This isn't like the Pandora, where people with no understanding of the technology complained that the SD cards were too slow; or how the wifi never quite worked right for some people, an unfortunate lack of resources; there is a legitimate complaint here that a decision was made before all the facts were had and that decision has lead to an imperfect device with a component behaving lesser than it could be. With the Pandora's wifi, no decision was made, that's just the way it was, no matter how much testing went into it. Here, a decision was made and there's a very good argument that it was the wrong decision. That absolutely needs to be spun properly.
You can't just say "oh, it's fast enough" in this case, even though it's almost certainly true; people who complain about the speed are doing so from a totally legitimate position and we have no right to dictate their use case. This is literally why other forums hate us, for downplaying flaws and telling them "they're holding it wrong".
This is a flaw, we need to fully acknowledge it, and prepare ourselves for when inevitably someone will come in and complain that the eMMC doesn't transfer their DVD collection as quickly as it should given the specs or whatever. The 118MB/s benchmark is a good step: it isn't all that much faster without the MUX anyway, could be deemed a reasonable tradeoff for the ability to add a uSD card in-line. I don't know, what else can we add in there?
Just... stop saying it's "good enough" when you don't know what someone else's use case might be.
[doublepost=1490755993,1490755839][/doublepost]
Strange to hear about the cases having issues due to being rushed, I hope that gets fixed.
It's literally just a matter of waiting a little longer. If you pull plastic out of it's mould before it's cool enough it warps; that's what appears to have happened here. They just wait a little bit longer and it won't warp when removed.
 
  • Like
Reactions: m@t
The GPD doesn't have a "feature" that has forced a speed reduction. For the Pyra, ED made a design decision with devastating unintended consequences. It doesn't matter whether 105MB/s is "fast enough", it isn't as fast as it would be if the MUX weren't there, and some users are going to pick up on that.

But that's the problem... it most probably just isn't as fast as possible when benchmarking.
In reality, the OS has to handle that amount of data, and that will most likely be the limiting factor.

What difference is in two cars where one can reach 125mph and one 150mph when there's a maximum speed limit of 120mph on the street?

Yes, in theory the 150mph car is faster, but in reality it isn't.
 
@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.. 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 ,. Also as I mentioned if you play games that like to load next stage data regularly , it can be a little taxing. etc etc. So is it a big issue for me - as I said no it's not. Annoying for me for sure, I am really impatient - Absolutely Yes. Like I said, the emmc speed is not the biggest issue though, it's everything else that has whittled down my want for the Pyra , the emmc speed being the last straw.

On top of all that I hate using SD cards becuase Ive had a number crap out on me, it's sort of now for me, like driving a car you have had issues with. I just don't want to do it.

We are a bit screwwed in Australia with the currency exchange. $800 Aud (delivered) is a lot of money, my expectations are high for that kind of cash. As you'd expect

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

1) The $800 cost, I might talk myself past that, but then I expect a lot

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. Again, I a lot of convincing needs to be done to pass me through that gate. Along with the cost, the negatives for me are adding up. By the way, once again I understand you didn't have much choice, it is what it is.

3) Then there was the emmc being just 32GB. That really put me on the razor edge. As I said, I don't like using SD at all. Side note: 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.

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

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.


My opinions aside, I think as someone else may have mentioned, the biggest issue with the mux issue, is that it will get picked up and used by detractors outside this forum to talk down the Pyra. Just as they commonly use the cost, and 2013 SOC to talk down the Pyra. ie not good from a marketing perspective to give haters another thing to bring up.

All that said, I'm glad to see big progress is being made to address the issue with the emmc speed. Which means , maybe I can talk my self back into the game :)
 
Last edited:
The 118MB/s benchmark is a good step: it isn't all that much faster without the MUX anyway, could be deemed a reasonable tradeoff for the ability to add a uSD card in-line. I don't know, what else can we add in there?
Just... stop saying it's "good enough" when you don't know what someone else's use case might be.

IMHO the EMMC is just there to run the OS and programs. Random reads are where it shines for that - and those should be unaffected.

uSD is light years faster now than it was back when we argued out eMMC vs USD for a primary internal boot media. So is eMMC. uSD is now nearly as fast as eMMC was back then. eMMC is now as fast as PC SSD drives were back then.

Pandora eMMC was @ 30MB/s
Pandora SD slots were each @18MB/s

OMAP5 dev board's Kingston eMMC is @45MB/s

Pyra EMMC without MUX is going to be @125-140MB/s
Pyra EMMC with MUX is going to be @75-115MB/s
The Pyra's uSD slot is 95MB/s
The Pyra's left SD slot is 95MB/s
The Pyra's right SD slot is 24MB/s

Once it is faster than 75MB/s on more than one media source, throw a party. Someone might think you're wanting to run an enterprise level database server in your pocket at the current speeds. The uSD is now fast enough to run the OS. The eMMC is faster still, particularly with random reads/writes. The EMMC being used is way faster than the original spec or the devboard. Original expectations have been exceeded. The current eMMC is faster than enough, just not as fast as it could be if the uSD slot and everyone who wanted it were shoved off the raft.
 
But that's the problem... it most probably just isn't as fast as possible when benchmarking.
In reality, the OS has to handle that amount of data, and that will most likely be the limiting factor.

What difference is in two cars where one can reach 125mph and one 150mph when there's a maximum speed limit of 120mph on the street?

Yes, in theory the 150mph car is faster, but in reality it isn't.
That's how I feel with modern smartphones, 4K screens and a ton of power just to run mostly freemium games like flappy bird, and the top of the line emulators could already run 100% on budget android phones.
My $100 phone can actually do way more than my Galaxy S4 simply because of the Android version is higher and runs the PlayStation emulator/GBA just as good. It's just the camera quality is bad which I very rarely use anyway.
@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.. 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 ,. Also as I mentioned if you play games that like to load next stage data regularly , it can be a little taxing. etc etc. So is it a big issue for me - as I said no it's not. Annoying for me for sure, I am really impatient - Absolutely Yes. Like I said, the emmc speed is not the biggest issue though, it's everything else that has whittled down my want for the Pyra , the emmc speed being the last straw.

On top of all that I hate using SD cards becuase Ive had a number crap out on me, it's sort of now for me, like driving a car you have had issues with. I just don't want to do it.

We are a bit screwwed in Australia with the currency exchange. $800 Aud (delivered) is a lot of money, my expectations are high for that kind of cash. As you'd expect

The process along the way has been a step by step stripping down of my wants for the Pyra.
...
I've paid about the same premium (I believe $941 in total? More than I should have but that's with vouchers to help out ED), but knowing that the alternative is the GPD Win which has a lot more flaws I'm personally not fond of and doesn't have the awesome community behind it like the Pyra/Pandora does, I'm never gonna back out unless something detrimental happens.
Also I was planning on doing minor video editing too and playing a bit with OBS but I was planning to put videos on the SD card because, well they're videos they take a LOT of space. The eMMC was just going to have programs installed to it since it's only 32GB and 103MB/s is more than fast enough for me for loading programs. I was originally expecting the MUX to cut it down to something like 48MB/s. Not quite sure why you don't like SD cards so much, they're usually lifesavers.
I'm also planning to replace my smartphone entirely with the Pyra when calling/SMS gets developed for it. And I absolutely hate touchscreen only devices. So for a device with this many features in general, this is a device I'll probably see once in a lifetime so the $941 is worth it for me. Yeah the specs may not be the top of the line but you can do a lot more on a mid-spec device compared to a high spec android device.

Again this is entirely my viewpoint and opinion on it, but it's sad to see you go so early. :(
At the end it's your choice.
 
The GPD doesn't have a "feature" that has forced a speed reduction.
Are you sure?

For the Pyra, ED made a design decision with devastating unintended consequences.
Devastating? like... it doesn't work? it explode when use? Are you sure that word is the right one.

Just... stop saying it's "good enough" when you don't know what someone else's use case might be.
Fine. And what it might be?

This eMMC episode is getting ridiculous.
 
Whatever "handicapped" is. zmatt was running the "handicapped" eMMC with 103MB/s already today.
To be specific, the results I get are:

(dd iflag=direct if=/dev/mmcblk1 of=/dev/null bs=4M count=256)
read 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9219 s, 83.1 MB/s
read 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9004 s, 83.2 MB/s
read 128 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 10.3783 s, 103 MB/s
read 128 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 10.4196 s, 103 MB/s
read 192 MHz 8-bit: (fail)

(dd oflag=direct of=/dev/mmcblk1 if=/dev/zero bs=4M count=256)
write 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 14.1563 s, 75.8 MB/s
write 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 14.0769 s, 76.3 MB/s
write 128 MHz 8-bit: (fail)

I've also tested 128 MHz read / 96 MHz write with random data instead of zeros to ensure the interface would get properly stressed, this also gave no errors.

(Note that it was already my expectation that write would give problems sooner than read.)

103MB/s is still ~90MB/s less than it should run, we'll see how it works when a prototype CPU board is modified disabling the mux.
Keep in mind that a theoretical "192 MB/s" is still not going to result in a real-world 192 MB/s, as seen by the fact that "96 MB/s" and "128 MB/s" become 83 MB/s and 103 MB/s respectively even under the best conditions I can easily create right now.

To give another point of reference, here's an UHS-I SD card at 48 MHz:
read 48 MHz 4-bit: 268435456 bytes (268 MB, 256 MiB) copied, 11.8947 s, 22.6 MB/s

100MBps+ seq. read speeds are nice, but I don't plan to pull large files off me eMMC often myself
Fair enough, although since the concern was the mux I've been specifically testing the interface between omap5 and eMMC, not really the eMMC itself.

And if this really is delaying half of the bus lines, I'd like to know whether writes are reliable, as a corrupted OS is a bit of a faff to recover from.
Every command and every block of data is protected by a CRC, so silent errors are not possible.

The better question is whether the driver recovers gracefully from CRC errors by retrying the failed transfers, or even switching to a lower speed if necessary. The answer to that is: no, its way of dealing with errors in general currently is:

return -EIO; /* make it someone else's problem */

(comment added by me :p )

I think this is something that... deserves a bit of attention (regardless of mux). Fortunately it's just software™.

This isn't like the Pandora, where people with no understanding of the technology complained that the SD cards were too slow; or how the wifi never quite worked right for some people, an unfortunate lack of resources; there is a legitimate complaint here that a decision was made before all the facts were had and that decision has lead to an imperfect device with a component behaving lesser than it could be.
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. It's moreover impossible to make all relevant decisions fully informed by all facts that might be relevant, the Pyra would never come to exist. Moreover all facts were available here, the problem is putting them together, not forgetting about one, and realizing that a problem exists.
 
Wow, now this reminds me of the Pandora development. I still have a PC that has a mechanical drive, I think it is maxed out at like 70 MB/s so anything over that is good enough for me. I'm saying for me, I know others will have problems with it.
I'm on a mechanical drive too, never used a SSD drive due to the price of them. Can't say I've ever benchmarked a mechanical one but if the Pyra is faster than my main goto computer, I'm sold regardless!
[doublepost=1490769302,1490768544][/doublepost]
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.
We needed to know for sure whether it would be a massive difference or not, and before that we were getting a lot lower speeds than 103MB/s before the drivers were optimised.
 
I just really don't think anyone is going to notice the lower speed. It's already way faster than my computer, and that loads things quite quickly. Next stages in games, video data, you're not going to notice a difference. I don't think it's worth it to address the issue, IMO.
I'm on a mechanical drive too, never used a SSD drive due to the price of them. Can't say I've ever benchmarked a mechanical one but if the Pyra is faster than my main goto computer, I'm sold regardless!
Yeah, it's already faster than my main computer as well.
Looks like for some of us the Pyra is actually a spec upgrade to our desktop systems, haha.
 
Back
Top