Discussion in 'Pyra News' started by EvilDragon, Mar 23, 2017.
HAHAHA what is he worrying about then? I must of missed that
"I must have missed that."
Actual lyrics... not kidding!
You are holding her so tight
Finally she's yours
The summer's giving you more
And everything's alright
WELL THAT REALLY GRINDS MY GEARS. if you haven't even pre-ordered, why the hell are you overreacting then? you have no money in this like alot of us. we all understand whats going on here and also understand that yes there will be set backs and stuff. at least ED and the other guys working on this tell us what they found and how they are fixing it.
i want a system that works, if it takes 4 more months then fine. if it takes longer fine. the end result is what i want
Because he's waiting for the things he cares about to become clear? I think that's very understandable behavior. I do that for a lot of Kickstarter projects.
The Pandora and the Pyra are unique nowadays, so everybody hopes they will become the perfect system for them. Just look at the keyboard threads.
It's really a non-issue though. I get the "more speed = more better", but redoing all the boards could cause a huge delay in actually getting devices. I have pre ordered a pyra and I'd like to have it asap.
Even if it's only a difference of 20MB/s that's still an argument in favour of straight eMMC, no uSD.
I never said I agreed with it, I'm not even saying it's a good argument, I'm simply saying it exists, and if someone comes along and presents it then we need to have a better comeback than "you're wrong, it's good enough as is".
Testing is still going on and there are efforts of getting the software (boot manager and kernel level things) and such working right. hns,zmatt are working through these issues and has found a few things that need to be fixed in the hardware, the eMMC was one, it's likely not that big of an issue, but some of the other things while easier to fix need to be addressed in the final version. I rather be sure that the hardware is not pushed out the door before ensuring it's properly working right. I know the feeling of wanting it now, I have developed a rather unhealthy and expensive retro computer obsession while waiting.
edit: bad sentence structure... sort of fixed.
Who says we have to argue at all? A lot of people don't like the Pandora and won't like the Pyra. They will argue a whole bunch of things before getting to the emmc, just like they already do and you won't change their mind.
It is just like our complaining buddy that hasn't even ordered one but is quick to say every aspect isn't good enough... You only need to say one thing to them "Don't order it."
We need a sub-forum /OtherConsoles/RetroElectronicsObsession (or something along those lines).
I too have found myself having a preference for 'old' hardware - much of which I have repurposed somewhat. A person hasn't lived, or maybe that is suffered, until they have installed Linux on a Zenith 486/25lnp laptop with the 40MB notebook IDE disk swapped out for a 1GB one (floppy, no USB, onboard ethernet). Or how about 'old' audio PA equipment and it's common household uses? We could go message back and forth on old computer and audio hardware for months and stay happily distracted from things Pyra related.
But keep in mind that the decision of providing a uSD slot was done (among others) to have a (save) second place to boot an alternative linux system and the eMMC ought to be only there to provide a place to store the Pyra standard system to boot straight of. That the eMMC in the end get so large (from formerly 4GB to 32GB) and fast, is only because of current availability and not of a planned decision (other than the uSD slot).
Knowing all that, people are wrong when argueing about an eMMC that will be slower driven that it could be.
Knowing all that, I couldn't understand why we are not all happy about a much larger and still very fast driven eMMC (>70MB/s) and having an uSD slot.
Come on Wizardstan! I thought you are the voice of reason 'round here. Since when you are becoming unreasonable?
To me, better shouldn't be the enemy of perfect. Pyra is so much better than Pandora and anything out there now. I say Ed should stop tweaking the Pyra to make it perfect and just release it now!
I would tend to agree with you re: the eMMC stuff; now zmatt's proved perfectly workable speeds can be acheived and we still have the mux so that muSD cards work, that's all good. However, the fact that this bottleneck wasn't discovered during previous testing suggests at least some testing should continue to make sure there aren't other gotchas.
I know my Pandora appeared to be perfectly stable at 1.2GHz until DraStic turned up and started exercising the NEON instruction set - that would only work reliably at 1.1GHz max. Granted, both of these numbers are above the specified 1GHz, so that's all good, but imagine if it would only work at 100MHz below the specified rate when using NEON instructions profusely (at 900MHz for Pandora or 1.4GHz* for Pyra) - then people might be upset that you have to underclock to run NEON code.
* Someone remind me, has ED's crew got the Pyra stable at 1.5GHz yet? I think I've gotten distracted with all this eMMC talk.
Edit: Yep, that was the last news story: https://pyra-handheld.com/boards/threads/4gb-and-1-5ghz-confirmed.79957/
How am I being unreasonable?
I think he means that it's working very well, and even if it doesn't work 100% perfectly, it works well enough that there will be bottlenecks elsewhere so that no one will actually notice that it's not working at the advertised speeds for the eMMC.
Yeah, I agree.
I don't think it's unreasonable to suggest that someone else might not though, and that we shouldn't be telling them their use case is wrong, that it is "good enough" to sacrifice for a feature they may not want or need.
"We should do anything but rush it"
Clearly then the Pyra should be using the same crappy eMMC as the dev board as it would not have been fast enough to get throtled.
The eMMC bus with the MuUX is plenty fast for the Pyra original spec.
A 650HP V8 dropped in a VW van does not equal a 250mph car. It will be way faster than the stock engine, but also limited by the rest of the design.
Replacing a 4GB 40MB/sec eMMC with a 32GB 140MB/sec eMMC will be faster than the original spec, but also limited by the rest of the deseign.
The eMMC got an increase of 800% in capacity and 250% increase in speed and now you want to kill someone else's feature to get 20% more speed? That Sir is cold.
The uSD feature is not the problem. It is functioning in spec.
That the eMMC has been granted an overspeced part is not the problem. Any capacity and speed over original spec is a bonus.
If the eMMC had not been upgraded, this conversation would not be happening.
We're having this whole conversation for the sake of meaningless spec greed.
Your answer to the question of where the other 25MB/sec went from the eMMC part number spec sheet? How about the truth? It is a higher capacity, more powerful, more current part that became available and was added late in the development process. On rare cases of large sequential reads it is throttled a bit by the bus cap. It is far faster than the original part planned, particularly in random reads which is what actually counts on an OS & application "drive".
How about: "During development it was decided after copious amounts of conversation to add a MicroSD slot to function as a backup solution to the eMMC for increased longevity and possible internal storage space expansion. However, during final performance testing it was discovered that the solution used to provide this feature limited the eMMC top speed because of signal delays caused by the part switching between the two. The problem was mitigated as far as it could be and should not present noticable downsides in use cases other than unusually heavy sequential use. Sacrificing some eMMC top speed was considered a reasonable compromise to keep the MicroSD feature and avoid the risk of delaying production."
I know this is basically the "good enough" argument, but it puts it into a context of a compromise between use cases, production realities and history. It doesn't address why the speed wasn't prioritized, like the potential person with an issue would've liked, but should provide a basis for them to understand the situation. Reasonable people will be a bit disappointed that their use case didn't happen to get priority, but accept the rationale. Unless I'm missing something here, there's no globally optimal solution to be found here (full speed eMMC and MicroSD), so a compromise or abandoning one use case over the other is the best we can manage. I think the decision to keep both storage solutions at least viable is not an unreasonable choice given the limited scope of the downside.
been thinking of this for a few years now.... but would there be enough demand here?
If i won Lotto i def would approach ED about at least a bulk order if not an actual dealership.....
Separate names with a comma.