Roku Developer Program

[EnTerr]

This question is about practical limitations (performance/wearout/etc) using roRegistry. What would be a reasonable frequency of storing values to the registry? For example, is dropping a blob (say 8kb) to registry 60 times per second acceptable?

Motivational example: i am playing with a simulation, which for purposes herein is a "state machine". At each moment of time it has its current state, then it changes to something else and so on, evolving. When channel is exited, that state will be lost unless stored somewhere - and registry the only (local) means of persistence. If there were "OnExit" event in BrS, i'd use that - but since there isn't, next best thing is to continuously store the state to registry (and presumably flush to disk). I expect there are some practical limitations to that - first as performance but also continuous writing is not healthy for the flash memory, if i remember - they were talking about flash wear-out?

PS. as usual i did my due diligence of reading the wiki and searching forum but there was no discussion of what i ask.

[RokuJoel]

Sometimes, even years after you enter the magical castle, these questions still remain a mystery...

viewtopic.php?f=34&t=34433&start=0&hilit=writing+to+flash+screensaver

- Joel

[RokuMarkn]

I would say that writing the registry 60 times a second is several orders of magnitude away from reasonable. You're correct, writing to Flash is slow, and excessive writing wears it out. I'd say something like 100 registry saves per day is quite reasonable and conservative. If you think you need to write a _lot_ more than that, it would be better to rethink what you're doing. Eg. does your state machine really need to be saved at the exact millisecond that the user exited? Or, could it be saved by an explicit user action rather than automatically?

--Mark

[destruk]

If we had a call available to us when the user presses the Home button, that would reduce the necessity for saves to the registry so often, or calls to the server to store information that needs to be persistent. But you guys removed any capability of doing that years ago. For bookmarks of a movie during playback - a two hour movie saving every minute would be over your recommended 100 writes per day. You might say to save the position when the video player screen is closed, but that doesn't help if the user exits by pressing Home.

[EnTerr]

"RokuMarkn" wrote:
[...] does your state machine really need to be saved at the exact millisecond that the user exited? Or, could it be saved by an explicit user action rather than automatically?

A screensaver is under consideration - there is no way for a screensaver to know it is being exited so it can persist the last state, is there?

The real problem is the lack of "OnChannelExit" kind of event. And hence coming up with workarounds, as in the case of preserving video play position.

[EnTerr]

"RokuJoel" wrote:
Sometimes, even years after you enter the magical castle, these questions still remain a mystery...

Wait, WAT?!
There is a castle in Saratoga and nobody told me? My interest is piqued.
Are there any sleeping beauties to kiss and dragons to slay - or is it all dungeons* and no dragons? :twisted:

*) on the bright side, you Joel now have the prerogative to rummage through the dungeon, find precious items and hand them to the poor (developers). Which makes it kind of a Robin Hood mandate.

[EnTerr]

I did some performance tests and there is no Roku player in existence that can hammer to disk the registry anywhere near 60 times per second; flushing to disk is too darn slow. My test was to write 8kb randomized data to registry, rinse, flush and repeat 100 times, time it, /100. Here are the results:

• 4200 model (Roku 3) = 23ms/flush


• 3xxx models = 49ms


• 20xx model = 71ms

There are some interesting caveats. For example, always storing the same data seems extremely fast when repeating the operation - so obviously flush() does not save to file if no real changes were made (optimization). Also, if stored data changes but is very small (one byte), timing is better (17, 34 and 23ms, respectively) - that hints that data compression and/or slow crypt routine is being used. That's why i used big and randomized string, to avoid "cheats" and be more realistic.

So. Depending on the model, if all the BrS code is doing is hammering the registry to disk, at most it can do that 14 to 43 times per second, depending on the model. But in reality, since channel has to do something else like math or graphics, it can afford to flush once per second or less - with wear-leveling it will take hundreds (if not thousands) of years to wear out the flash => not a real concern; yay for unintended consequences.

The nasty part is that if i am doing animation at 30fps, i have 33ms per frame so when trying to save the registry, i will miss a frame - which leads to a noticeable jerk. Be it once per second or once a minute, it will be a visible hiccup. There is not a chance that Registry can do its saves on a separate thread, i presume?

[RokuMarkn]

"EnTerr" wrote:

So. Depending on the model, if all the BrS code is doing is hammering the registry to disk, at most it can do that 14 to 43 times per second, depending on the model. But in reality, since channel has to do something else like math or graphics, it can afford to flush once per second or less - with wear-leveling it will take hundreds (if not thousands) of years to wear out the flash => not a real concern; yay for unintended consequences.

Hm, you might want to recheck your math. The way I calculate it, assuming perfect wear leveling and approximately 100MB available for writing, about 6000 16KB writes will write every block in the flash once. Assuming 100K writes per block before wearout, that allows about 600 million writes. At one per second, that's only 19 years. Still a long time, but not thousands of years.

--Mark

[EnTerr]

"RokuMarkn" wrote:
Hm, you might want to recheck your math. The way I calculate it, assuming perfect wear leveling and approximately 100MB available for writing, about 6000 16KB writes will write every block in the flash once. Assuming 100K writes per block before wearout, that allows about 600 million writes. At one per second, that's only 19 years. Still a long time, but not thousands of years.

Mine was a wild-jack guess, since i lacked 2 important numbers: flash size and spec on #re-writes*. Thank you for providing some clarity. I'll only weakly argue to double that to 40yrs in consideration of storing 8kb (avg size + compression) and not 16kb.

Any chance of getting "OnExit" event though, instead of monkeying with frequent saves?

*) search i did now shows "100,000 Program / Erase cycles" in spec sheet for 256MB Spansion SLC NAND used in (some) Rokus. There is also the case where static wear leveling would spread the writes over all of 256MB and not just the 100MB, by swapping hot and stale blocks periodically - but i don't know if that is in use here.