Swordfish II
Advanced Member
- Joined
- May 20, 2015
- Messages
- 1,175
So dont buy one and stop complaining.
Quite a bit for you to read!
- Thread starter EvilDragon
- Start date
So dont buy one and stop complaining.
levi
Still fresh, damnit!
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'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).
GizmoTheGreen
Active Member
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.
0x14f
Member
- Joined
- Oct 19, 2016
- Messages
- 65
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...
Wrath Of Khan
Soul soother...
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.
Splintercat
Member
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.
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.
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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]
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.
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.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
The fastest car in the world is either a rental with full insurance or stolen.
vcoleiro1
Hardcore Member
- Joined
- Jan 23, 2011
- Messages
- 4,685
@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
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:
Swordfish II
Advanced Member
- Joined
- May 20, 2015
- Messages
- 1,175
Again... Don't get one then
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
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.
Kippykip
BFG 9000
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.
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.
ptitSeb
Serial Porter
Are you sure?
Devastating? like... it doesn't work? it explode when use? Are you sure that word is the right one.
Fine. And what it might be?
This eMMC episode is getting ridiculous.
zmatt
Active Member
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.)
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
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.
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
)I think this is something that... deserves a bit of attention (regardless of mux). Fortunately it's just software™.
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.
second exodous
Advanced Member
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.
Kippykip
BFG 9000
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]
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.
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.
