Probably not an issue if you design what ever caching algorithm around the fact you know that flash is backing it. It's relatively easy to model these things and the flash will be guaranteed for a known number of operations.
Digital Foundry Article Technical Discussion Archive [2013]
- Thread starter helio
- Start date
-
- Tags
- digital foundry
- Status
Probably not an issue if you design what ever caching algorithm around the fact you know that flash is backing it. It's relatively easy to model these things and the flash will be guaranteed for a known number of operations.
Can you point me to where you heard this? Given that the OS and recent apps are more or less permanently resident in their own partitioned-off subset of system RAM, it not obvious to me why MS would need to augment their performance even further with a flash cache. Why not just load any additional apps from the HDD when and if they're needed? What's the hurry? It's not like people are gonna complain about texture draw-in issues in their Twitter app, are they? Aren't games more likely to be "pinched" by disk latency or throughput deficiencies, as compared to some app or OS service?
It just seems like a weird allocation of resources to me. I'd like to hear what Microsoft's reasoning was.
Perhaps the 8G flash is used to mirror the RAM when system goes into "hibernate" mode, instead of doing in on the hard drive.
writing to flash that frequently is what will trash the memory, it's smarter to read a lot, like using flash for the OS, that would get updated on occasion, but mostly read
fair enough, can you estimate the MTTF?
Do you mean that the flash memory could have a special role under very specific circumstances and that it could be effectively used as a cache avoiding wear and tear issues? I am wondering how that's possible....not only for a gaming console flash memory but for any piece of flash memory out there.
The flash of the system would be fully exposed in that case, and I guess you could have a maximum of writes per game or flash usage at your disposal? I don't see how you could avoid wear&tear issues though...
Perhaps if you used a fixed part of the flash to cache the data of games, like the original Xbox, which had 6GB of cache in the HDD so games like Halo 2 and other could read a lot faster by using it. It was overwritten every time you played a new game but it remained unchanged for as long as you played a certain game and never swapped games.
As a console consumer, I want things to last as long as possible. The idea of seemingly planned obsolesence is a total turn-off. MTTF is a ridiculous metric from that perspective, and 10 year usage should be considered the *minimum* life of a console.
At the very least, a hdd can be replaced...but embedded flash?
At the very least, a hdd can be replaced...but embedded flash?
Last edited by a moderator:
That's not what I was suggesting, but if the MTTF is like decades then it wouldn't matter.
Well, I'll be disappointed if the flash can't be used for anything more "interesting" than a place to stash OS updates. It seems like the HDD would work just fine for that, and unlike the 360, every XB1 has a hard drive.
But, as many have pointed out, you can only write to flash so many times, and that excludes a lot of potentially cool use cases since you have to allow for that diabolical user that never plays the same game twice in a row, meaning that a game-data cache would need to get refilled perhaps many times each day. While at the same time you need to allow for the user that hibernates his console every time he goes to the bathroom. Neither is a "normal" usage pattern, but either could conceivably use up several thousand write cycles in just a few years.
Myself, I tend to put one game "on the top of the pile" for days, if not weeks at a time. And I think I could live without hibernation, if the "sleep" mode is sufficiently deep. (Another advantage of using power-sipping DDR3?) So, in my perfect world, the flash could be used to try to mask the relative slowness of HDDs when playing games.
Also, in my world there'd be a lot more of it. 8GBs? Really?
But, as many have pointed out, you can only write to flash so many times, and that excludes a lot of potentially cool use cases since you have to allow for that diabolical user that never plays the same game twice in a row, meaning that a game-data cache would need to get refilled perhaps many times each day. While at the same time you need to allow for the user that hibernates his console every time he goes to the bathroom. Neither is a "normal" usage pattern, but either could conceivably use up several thousand write cycles in just a few years.
Myself, I tend to put one game "on the top of the pile" for days, if not weeks at a time. And I think I could live without hibernation, if the "sleep" mode is sufficiently deep. (Another advantage of using power-sipping DDR3?) So, in my perfect world, the flash could be used to try to mask the relative slowness of HDDs when playing games.
Also, in my world there'd be a lot more of it. 8GBs? Really?
If you used enough you could tell developers that each game can use a static flash cache of like 2gb. Make it a read only thing so they can just prioritize and load it up once. Then you would also have enough total flash so that the last 4 games, or so, had their flash cache files saved to avoid rewrites when users are juggling a few games. With 16gb of physical flash you could do that much and still have 8gb left for OS use. I don't know if a static flash cache of that size would be very useful, though.
Its purpose was confirmed at the Xbox reveal back in May.
They can't enable seamless simultaneous loading of apps/skype/iexplorer when the hdd is tasked with pulling game data off the hdd. This flash enables the unencumbered multitasking experience Microsoft has envisioned.
As you can see from the above photo the eMMC4.5 Nand is used in the manner Shortbread described. MLC of 8GB size would eventually wear out the cells if there was data being constantly written to its cells. In the hypothetical "virtual memory" for games situation in which its used for games, 8GB mlc nand does not give much space in terms of wear distribution and once those cells are worn out game performance would unexpectedly drop. Developers would have to design around 8GB flash wearing out.
PS4 was rumored to have 16GB of flash built in. Vita has 4GB of flash for the same purpose. Sony never announced that fact, so we may have to wait for teardowns of the PS4 at release to confirm.
I'd be very surprised* if any device doesn't come with flash. It's cheap and versatile and replaces the ancient necessary ROMs with something more flexible. Vita has Flash, Wii U has flash, XB1 has flash, PS3 had flash, every phone and tablet has flash, TVs have flash...I think we can see where this is going. 
*read 'gobsmacked and utterly confused'
*read 'gobsmacked and utterly confused'
Well... no, it really wasn't. (It did confirm the existence of the flash cache, however.) That vague and hand-wavy quote could mean almost anything. (Or nothing) That statement basically boils down to, "We used a combination of hardware and software to make stuff snappier."
But that's not to say that you are wrong about your hypothesis that the flash is only being used as a non-volatile cache for "OS stuff". That may very well be true. It's a good hypothesis. But it's not been "confirmed" by any statements from MS, IMO.
Really? They can't? Come on. Why not? They've dedicated an absolutely huge amount of RAM to the non-game side of things. In what world does 2GB not leave enough room for a handful of "snap-able" smart-phone-esque apps to remain resident all the time? Leaving stuff in RAM would after all be much faster and even more seamless than streaming stuff in from flash on demand, if that really was MS's overriding priority.
Also, if (a big if, I agree) the flash was instead being used for caching game-data, then the HDD could be comparatively less busy during game play, which would in turn allow it to serve the needs of the OS in a snappier fashion. In both scenarios the desired result is the same, and the hardware resources are the same. They are just allocated differently. The "app snappiness improvement" might be the similar either way, but in my scenario the game performance would be improved as well. (I know it's old fashioned to care about such things on game consoles, as compared to the overriding importance of an instantaneous Skype launch, but I'm funny that way!)
(I'm making fun of MS's apparent priorities above, not yours.)
Again, you're probably right about how things will work. It wouldn't surprise me a bit. But that "evidence" from the reveal doesn't confirm anything one way or the other. You are just choosing to interpret a nebulous statement in one particular way. The fact that flash might wear too quickly if used as a game cache seems like a much more convincing argument to use against me.
How about a giant mega-texture/mipmap cache? The mega-texture/mipmap is loaded into the flash cache and virtual addressed by the MMU. The MMU partitions the texture/mipmap into memory tiles. Then a subset of the memory tiles get mapped to the RAM either DDR or eSRAM or both. Additional memory tiles from the flash are read into the RAM as needed. You get twice the bandwidth than the HDD with the addition that flash is all reads and not handling any write transactions. You are not streaming textures out of the HDD so pressure on the HDD bandwidth is reduced and latency improved.
You don't have to really worry about flash wearing out. New data is only written into flash when you change your game. Unless you are frequently going back and forth with multiple games consistently which isn't a typical usage.
You don't have to really worry about flash wearing out. New data is only written into flash when you change your game. Unless you are frequently going back and forth with multiple games consistently which isn't a typical usage.
It *does* seem plausible that a game gets non interfered access to the resources it uses though. Nobody likes framedrops because of a background app fetching data. The HDD has more capacity so perhaps devs prefer it over using a, somewhat limiting, 8GB Flash for gamedata storage. A game already has a lot of memory available, how much gain in performance could be achieved by using the flash as additional storage?
I agree it's probably not typical, but that doesn't really matter. The hardware needs to not destroy itself, even when subjected to non-typical usage. In a household full of kids, I can easily see several-to-many games being played throughout a normal, screaming-filled day. Allow me to make up some numbers:
Flash can survive 3000 write cycles
Some customers trigger 5 "game transitions" per day
Their flash cache stops working in less than two years
Class action lawsuit
I'm not positive those numbers are plausible, but I think I'm in the ballpark at least. Even if I'm being ridiculously pessimistic, it's not close to being acceptable. In my house, I'd be fine. I go days to weeks between games, on average. But MS dares not assume that's true for everyone.
- Status
Similar threads
