Quite a bit for you to read!

Discussion in 'Pyra News' started by EvilDragon, Mar 23, 2017.

  1. Willhelm

    Willhelm Very Active Member

    Aug 19, 2014
    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.
  2. Christoph.Krn

    Christoph.Krn Very Active Member

    Oct 29, 2009
    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.
  3. EvilDragon

    EvilDragon Administrator Staff Member

    Mar 4, 2003
    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).
  4. AnimatedFreak

    AnimatedFreak Very Active Member

    Oct 29, 2011
    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.
    Kippykip likes this.
  5. WizardStan

    WizardStan Mega GP Mania

    May 24, 2008
    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.

    It's obviously an exaggeration, but you should've been able to understand the point.

    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?

    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?
    liveunderwater and ptitSeb like this.
  6. Kippykip

    Kippykip BFG 9000

    Sep 6, 2016
    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.
    ClockworkCoder likes this.
  7. Swordfish II

    Swordfish II Very Active Member

    May 20, 2015
    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.
  8. bukkit

    bukkit Member

    Mar 30, 2011
    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 ...?
    Kippykip likes this.
  9. EvilDragon

    EvilDragon Administrator Staff Member

    Mar 4, 2003
    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.

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

    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.

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

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

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

    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.

    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.

    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.

    That will never happen, as that's the theoretical maximum speed from the datasheet (meaning: no OS overhead, no filesystem, no anything).
    Creature XL, Zogzog, Alberto and 14 others like this.
  10. ClockworkCoder

    ClockworkCoder Chaotic Neutral

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

    Exciting times :)
    Kippykip likes this.
  11. vcoleiro1

    vcoleiro1 Hardcore Member

    Jan 23, 2011

    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: Mar 30, 2017
    levi and Haraldur like this.
  12. 0x14f

    0x14f Member

    Oct 19, 2016
    @vcoleiro1 welcome back :)

    @ED what we really need here down under is an Australian Pyra dealer to make conversion rates tolerable.
    LineOf7s and Kippykip like this.
  13. Kippykip

    Kippykip BFG 9000

    Sep 6, 2016
    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! :)
  14. bubblebee

    bubblebee Member

    Mar 27, 2012
    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.
    tarator, CommanderB, ible and 7 others like this.
  15. CFWhitman

    CFWhitman Member

    Mar 2, 2011
    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.
    tarator and Bokkertoff like this.
  16. wdt

    wdt Member

    Feb 16, 2009
    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
  17. Wrath Of Khan

    Wrath Of Khan Soul soother...

    Dec 29, 2009
    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.
  18. Grench

    Grench Forum Addict!

    Oct 3, 2008
    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?
    drock, ClockworkCoder and Kippykip like this.
  19. jeeks

    jeeks Very Active Member

    Mar 19, 2013
    +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?".
    jorlinn, FBnil and Klumpen like this.
  20. Swordfish II

    Swordfish II Very Active Member

    May 20, 2015
    So let me get this straight. You made a big deal about a whole bunch of stuff, yet you haven't even pre-ordered?
    drock, ChunkyPenguin, mecksg1 and 5 others like this.

Share This Page