Quite a bit for you to read!


I also completely doubt this speed knockback would affect anything major like emulators right? like for example using PPSSPP playing GTA and driving really really h e c k i n g fast where it has to continuously load the rest of the map (PSP's UMD Speed was about 3MB/s anyway, then again I would probably just be using a standard SD for that resulting in slower speeds but anyhow) I think 103MB/s is completely fine and besides, I don't think my cheap phone can even go past 40.
Does anyone have a date for when the MUX test thingy will get disabled?
 
Personally, I've always thought that the Pyra would have been just fine running off of microSD media without the eMMC.

The main point to the eMMC is to have something faster than the microSD can be with random read/write where the OS can be pre-loaded to without concern over microSD card variation, speed & size. Sounds like it's doing it's job. That box has been checked. Time to move on.

So, what is left to conquer?
Are the keymats in? How are they?
Are the latest cases in? How are they?
Has the aluminum plate thermal solution been implemented?
Are there any remaining bits & pieces to source and fit to create the first prototypes of -like production- units?
What else is left?
 
So what else is bugging you then that this becomes a deal breaker?
Capture.PNG
 
Last edited by a moderator:
from pre-preorderer who doesn't post a lot...
(i'm not sure why i'm weighing in on this while remaining silent on most issues, but here goes.)

when i first heard about this issue i found it concerning because of how it might affect boot times and the loading of large apps. however, having thought about it a bit, 100MB/s seems incredibly reasonable to me, especially since there are likely other bottlenecks at work. i would not mind receiving a pyra limited in this way at all.

unrelatedly, any ideas on how big the installed pyra os will be? is 2gb a reasonable ballpark? (it's been ages since i used pure debian, and i don't know how different architectures compare in size)
 
Have we reached the point where ED's perfectionism is starting to get in the way unneccessarily?
I've been waiting for this point since it's more or less inevitable with someone so dedicated to making a really well optimized device.
I personally don't have a problem with that and enough patience for however long it takes, but some others may react differently.

Would more RAM speed really make a difference or are there other bottlenecks?
 
unrelatedly, any ideas on how big the installed pyra os will be? is 2gb a reasonable ballpark? (it's been ages since i used pure debian, and i don't know how different architectures compare in size)
yeah It's just about 2GB on a fresh install. My current install with a ton of extra libraries, build tools and some random garbage is less than 8GB. we have a 32GB eMMC, so plenty of room.

Have we reached the point where ED's perfectionism is starting to get in the way unneccessarily?
Right now there is a ton of work being done by zmatt, most of it is figuring out the software end of things, but in the process he's finding some glaring issues with the hardware, some are easily fixed like changing a resistor value, some are more complex like the eMMC. I don't see it as perfectionism, this is work that needs to get done and we're better off in the end.
 
Last edited:
unrelatedly, any ideas on how big the installed pyra os will be? is 2gb a reasonable ballpark? (it's been ages since i used pure debian, and i don't know how different architectures compare in size)

I have Debian 8 installed on a netbook at 2.6GB, with LXDE and LightDM, that includes Pale Moon, Transmission, SSHFS, Gigolo, VLC, Filezilla, Network-Manager, zip support, picture support, abiword, pdf support, and a few others.
 
You launch it.. and ? Peoples just launched HDD bench on their GPD Win, they had results. And then what?

'It is required to humiliate during coffee break, lamers with their pentium 133'.
[Freely translated from an old sarcastic french text available here in extenso to the curious ones. Didn't find any english version, sadly.]

Joke apart, I'm waiting for the tests results and I believe benchmarks are part of those.
'There's too much confusion here, I can't get no relief.'
 
Joke apart, I'm waiting for the tests results and I believe benchmarks are part of those.
'There's too much confusion here, I can't get no relief.'
This.
This discussion seems based on a few ballpark numbers, obtained from what does not sound like thorough testing yet. I get the feeling this leads more to confusion and panic than anything productive.

So, go team Pyra! Looking forward to those benchmarks and whatever else happens in the near future!
 
Right now there is a ton of work being done by zmatt, most of it is figuring out the software end of things, but in the process he's finding some glaring issues with the hardware, some are easily fixed like changing a resistor value, some are more complex like the eMMC. I don't see it as perfectionism, this is work that needs to get done and we're better off in the end.

I wish there were an easy way for us to collectively buy @zmatt a pizza and beverage as a collective, "Thank you!" for the work he has been doing on our behalf.
 
@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?
 
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.
 
@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.

But here it would even be LESS annoying!
Videos are being streamed, so you NEVER need 100MB/s for that.
And normally games also won't need to load huge parts of data into the system as well. A 1GB game will never load 1GB at once, it loads the data when it needs it, so waiting time between a level might be half a second less.... yay.

I don't even know yet if the GPD Win has a FASTER eMMC, to be honest.
I've read a bit more about the benchmark tools used on Windows and it seems they simply read and write on the eMMC with whatever settings the driver in Windows has setup (and usually, you have caching enabled).

For proper benchmarking, you need to use DIRECT reads, and those are quite a bit lower.

The difference between unbuffered and buffered reads in our example is 118MB/s (unbuffered) vs. 131MB/s (buffered).

I have no real idea what is being benchmarked with CrystalDiskInfo on a normal Windows system.

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.

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...

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.

... it adds up with an eMMC speed that's still much faster than in most smartphones out there, probably even the expensive ones.
Now I know there's a reason big companies don't tell you anything about such things.

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.

That's perfectly fine, and I would find it annoying as well, if the eMMC speed would be 30 MB/s or so, as that would be WAY slower than you expect, but the current speed is perfectly fine.
I'm not sure it even makes sense to run it at higher speeds, as it heats up fairly quickly on constant usage at this speed - which is probably why mobile devices usually use slower speeds.

BTW, Nikolaus modified a PCB to bridge the MUX, here is a nice picture:
DSC02737.jpeg

Just for reference: The size of the chip is 4,15 x 4,15mm, so yeah, that's some micro-surgery.

A first test from Nikolaus shows that the speed increases to 118MB/s (with an unoptimized driver, Nikolaus had about 70MB/s before), so it could very well be the speed increase is just minimal.
zmatt will receive that PCB and will do further tests on it.
 
I find it to be sad that the Pyra is supposed to be an open device people should be able to run anything they want on, yet some users make fun of others for having "improbable" or "unreasonable" use cases. The eMMC speed is probably not going to be as fast as advertised in the beginning, and it should be entirely up to the user to reevaluate their options and, if the device is no more fit for their planned use, cancel the preorder. Calling someone a snob for using an open system differently than you do is pretty ridiculous.

I for one am excited again. The fact the speed wasn't exactly known at the beginning of this thread and I'm the first in the line of pre-preorders and want to get the device as quickly as possible (watching the OS and applications evolve first hand is part of the user experience for me) scared me a bit. I never planned to use the microSD card slot except maybe for testing exotic operating systems, so a hardware reduction of eMMC speed to the same levels as UHS-I SD cards or even below would have been a serious issue. But ~100 MiB/s and maybe even a bit more if the drivers can be optimised better should be totally fine for me.

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?
...no ED, I think he meant exactly what he wrote: The SoC. @vcoleiro1 was asked what he meant by "straw that broke the camel's back", and this is an example of other things that annoy him about the Pyra, if I understand his points correctly. Also, the exact part number of the eMMC has been known for a while now, hasn't it?
 
Back
Top