prefman save - dangerous? [premature flash wear]

[vasile-gh]

TL;DR: IMO excessive use of prefman to load/save settings will decrease camera life.

Experiment: change a setting (any setting) and pull the battery. Result: the setting is not remembered unless a normal power off takes place. => Samsung engineers made sure that settings are saved to camera flash only when really needed. this begs the question: why not save every time a setting is changed, which is both easier and safer? IMO the answer is that they wanted to avoid excessive flash wear.

Fact: @ottokiksmaler proved that internal camera flash is very slow.

My conclusion: Samsung used low quality flash (read: slow, maybe with low write cycle count) in the NX line, to keep costs down, and they relied on the fact that there are not going to be many instances when writes take place (on power off only).

BTW, I am not quite sure what the EV_UP EV_DOWN method is supposed to achieve - is it for custom video profiles (just like C1 and C2 dial work for photo?) - if yes, we should probably try to find better ways than imposing camera reboots - I am sure we could build something better with libprefman.

In the meantime, I do not know about you but I will (personally) not use that profile save method for my cameras.

[KinoSeed]

If you want to be able to update NTSC/PAL you will need to reboot on NX500 NX1 has that small reboot built-in as prefman ID 1

you have to excuse my bluntness but going into wild speculations on "bad parts" in the device is nonsense.

if you have any specific question feel free to ask

[vasile-gh]

@KinoSeed I am not in the habit of doing wild speculations. And I generally refrain from calling other's hypotheses "speculations" without at least some arguments.

I stated what I think, I presented the reasons I think so. If you are so sure they are not valid, please state so and put some arguments on the table as to why you think I am not right.

Calling my statements "wild speculations" without any arguments as to why does not advance the discussion.

[vasile-gh]

And no, I do not excuse your bluntness - this is a forum where politeness goes a long way.

[KinoSeed]

speculation ˌspɛkjʊˈleɪʃn/ 1. the forming of a theory or conjecture without firm evidence.

your only "evidence"? - Fact: @ottokiksmaler proved that internal camera flash is very slow.

There's nothing more to comment about that.

[vasile-gh]

So you choose to only read the second part of my post, and do not give me a reasonable explication as to why Samsung engineers only write to flash when absolutely necessary, and they go to some length to make their code more complex.

[ottokiksmaler]

FWIW, most (if not all normal) manufacturers of SD cards (internal disk is emmc) do wear leveling (see links in this http://electronics.stackexchange.com/questions/27619/is-it-true-that-a-sd-mmc-card-does-wear-levelling-with-its-own-controller discussion, referenced SanDisk pdf is no longer at that address but can be found via Google, I have it if someone needs it).

That said, prefman dumps work with larger blocks of data so not sure how it affects things. There's no firm data pointing one way or another but I prefer to err on the safe side - I have minimized writing to any internal disk and I do writes to /tmp that lives in RAM. This does not solve issue with having data that needs to survive full power cycles - so we need to find a suitable solution for that.

I would prefer a method that enables setting individual parameters similar to st cap capdtm usr/var set/get/list. But we would have to make it like poker or our proof of concept prefman tool.

[KinoSeed]

Prefman works with two devices - NAND (mtd device) and eMMC on a profile UP/DOWN the saved size is 66Kb on FullSave (essentially camera backup) the full amount is about 6Mb

the slow speed performance (and wear-tear) comes from the raw NAND / mtd device, which will not be used/written on in the next version v1.70 (as it appears that it's not needed)

[KinoSeed]

"Sandisk have a white paper that explains the wear levelling logic in their cards, and goes on to give estimates of the card's life under a number of scenarios. Executive summary: unless you are hammering the card non-stop, it will last decades."

So it is reasonable to expect that even e few hundred profile changes a day will not affect the lifespan in any realistic manner.

[vasile-gh]

Which is precisely the reason for which you rubbish (ok, call it wild speculation) my argued opinion and soon after write here:

this is related to profile-loading, which requires the profile loaded in ram to be stored in order to be activated (and to survive restart). What is not done anymore is saving the profile also to the raw-NAND, which makes it faster, and since NAND is subject to wear-tear issues, it will be much better for your camera life (in case you switch profiles frequently).

Yes, I understand perfectly.

[KinoSeed]

@vasile-gh, the raw NAND (mtd device) and eMMC are two separate and different devices, and the speculation about "bad quality emmc" was and still is nonsense speculation. (and as it turns out unfounded, as the slow speed had nothing to do with the emmc)

[vasile-gh]

Interesting. So you think I wrote eMMC. I suggest you re-read my post.

[KinoSeed]

@vasile-gh your words:

Experiment: change a setting (any setting) and pull the battery. Result: the setting is not remembered unless a normal power off takes place. => Samsung engineers made sure that settings are saved to camera flash only when really needed. this begs the question: why not save every time a setting is changed, which is both easier and safer? IMO the answer is that they wanted to avoid excessive flash wear.

mtd is not the "camera flash", it's the emmc - is. the fact that they are saved every time you turn off the camera, mean that on each power-down those are re-saved to nand too.

The evidence is sufficient, to conclude that the emmc (camera flash) is safe for normal use. I consider the topic closed. : ) cheers

[vasile-gh]

@KinoSeed I see you continue to insist on putting words in my mouth. Again, I did not mention emmc. I have been aware for quite a while (actually since a few days after I started to look into the NX500 - circa March if I remember correctly) of the fact that the cameras have two types of flash (by the way, both emmc and mtd are flash, the only difference is the way they are accessed).

In case you did not know, a significant difference between the two is that emmc usually has wear-leveling implemented (at the controller level) whilst mtd does not, meaning that any repetitive writes on to mtd will end up in the same flash cells, eventually causing the respective flash cells to fail. And by the way, TLC flash cells have typically +/- 1000 write cycle life, MLC have 10000, and SLC have 100000 [see here]. I do not know what type of flash Samsung used for the mtd, but I prefer to assume the worst.

And before you say 1000 is plenty, let me tell you that I just received a second warranty replacement of a 128GB microSD card I purchased last June (and this card has wear leveling) - this is to say that typically above means just that: typically, i.e. more or less.

Finally, as I alluded above, this is a place where I'd like to hope that discussions would be rational and above all else polite.

I quite understand that you may not agree with some of my thoughts, and I am all right with it. What I am in general not all right with is, amongst other things, bluntness (as you call it).

And now I am ready to join you in the willingness to consider the topic closed.

regards

[KinoSeed]

@vasile-gh , I just quoted you. The difference between raw-nand and emmc is significant, and it's not only in the way they are accessed.

I see no reason that we get into detailed discussion about that, as it does not matter, other than the difference raw-nand - prompt to wear and tear, emmc under normal use - good for decades.

You assumed the emmc is bad quality, because it's slow (and based your speculation on that), but it is not, as we can see that the raw-nand device is the reason, which is to be expected.

When it comes to changing settings I am pretty sure, that if you switch from pal to ntsc for example, you will get the settings written if not the raw-nand, then at least the emmc. (without using prefman)

And let's say you use "st cap capdtm usr/var set/get/list" - then what? how are you going to "commit" them? as ntsc/pal even need a reboot.

To summarize, there is absolutely no evidence, that emmc will have any adverse effect being saved on (even a few hundred times daily), and the only fact that you base your speculation on, was related to the raw-nand, which is now not used.

So again, I see no reason to continue this topic, and I trust everything is clear now.

[vasile-gh]

@KinoSeed Here emmc comes again. Something I never wrote. I wrote flash.

But I now (finally) realize my mistake: in fact you changing the saves immediately after my post has absolutely nothing to do with it, since the initial post is in any case absolutely unfounded as you explained above.

And you were in fact quite polite: you told me that I have to excuse your bluntness.

So I must apologize, and I do.