There is a problem with "cheap" monitors and DDC/CI: some of them use EEPROMs to store brightness settings, and this limits you to about 100,000 writes.
Worrying about this is the main reason we don't ship DDC/CI with f.lux. (I know that some more modern monitors use NAND and don't have limitations like this.) Anyone know if these fears are overblown?
This program should make sure to change brightness enough to reduce the lifespan to less than 2 years. Then the user will have free lifetime updates of monitors! (I reckon this would fall perfectly within normal use of a monitor. Hence, an RMA case will kick in)
I tried to achieve basically what this app does on manual mode some years ago. “How hard could it be?” are the famous last words etched in the three ATI video cards I bricked before giving up.
For things like setting brightness or toggling devices that ought to be dead simple, stuff like DDC/CI and HDMI-CEC being broken on so many levels never fails to make me spectacularly sad.
Not related to monitors, but this is how I bricked my old Lenovo Thinkpad W520 4 times. I switched between the Intel and Nvidia GPUs via the BIOS setting enough times to wear out the BIOS chip. I didn't figure out what was going on until my 3rd replacement.
I suppose it's a type of problem that solves itself: If companies are dumb enough to store brightness settings in EEPROM, they're only doing it because no one uses DDC/CI.
Use DDC/CI, and they'll stop. Even NAND is wrong if brightness is actually dynamically controlled, it should just be RAM.
Ahh, but this information needs to make it to consumers so they don't get stuck with dud monitors that have internal storage that rapidly wears. How, as a consumer, do I know which monitors store settings in such a manner and therefore avoid them when making purchasing decisions? Perhaps Lunar and Flux could make monitor recommendations with affiliate links, Wirecutter style. I don't want to have to research, just tell me what works best so I can pull my credit card out.
Such monitor recommendations could only be based on people tearing down things, which is outside the scope of Lunar and f.lux.
There is never a guarantee that you don't get stuck with a dud monitor, in any aspect. However, companies making products with bad reliability is going to face high support/warranty fulfillment costs and get a bad reputation. And if it fails within warranty/consumer protection periods, you lose nothing.
So, write away, and flood bad manufacturers in complaints. It's all you can do as a consumer - the alternative boing to get AMD, nVidia or Intel (or Displayport/HDMI interest forums) to be interested in making requirements against display manufacturers on the matter.
Wait...so after the 100.000th write, your monitor will be forever stuck on the brightness it was set to that time?
BTW, assuming I change brightness 20 times per day, that would still give me 5000 days ≈ 13,5 years of service. By that time I definitely hope to use a different monitor than today
No, after 100.000th write your monitor is toast because the EEPROM died. Also note that most people change brightness in increments, with each step causing a write.
You could pay to buy monitors for people and ask them to toggle the brightness until it dies, then record it down on a wiki and opensource this information.
I've been reading that NAND flash doesn't support erasing individual bytes, while EEPROM does. If there's some way to attempt this and know the outcome, maybe that's a way to figure it out.
Early EEPROM could only be wiped entirely (but as this was done electrically, it was still an improvement over UV-erased EPROM), while EEPROM at the time of Flash's creation could often be byte-erased (as is the case now).
Nowadays "EEPROM" mostly refers to small, slow, rarely written config storage for microcontrollers. As thus, they are also usually accompanied by low write/erase endurance despite their byte-erase granularity.
Flash was meant as a higher capacity/performance version indeed sporting full block erasure as a downside, but nowadays it has supplanted EEPROM in all categories but small micro-controller usages. Plus, as capacity is now cheap, high write loads can easily be supported with write levelling (that is, writing to new locations instead of erasing/writing the same block over an over.)
The problem is that eeproms don't do wear leveling. Not internally and they're usually controlled by a simpler microcontroller that doesn't have enough resources to do it in software.
So every time you write to three same byte you're writing the same cell. 100.000 cycles is actually much more than current flash generations.
These days basically every kind of mass storage device you will use has its own dedicated controller chip which is pretty much a cpu with its own RTOS now. Those 2 cent 8kb eeprom ICs don't but its crazy how complex something like an sd card is.
Hmmm. I hope the firmware authors weren't that dense. I would imagine they do a write when you exit the brightness change menu.
100,000 is a typical eeprom guaranteed write count. It will likely last much longer. The eeprom is probably much bigger than they need for such an application so they could actually handle the wear case by moving to alternate locations when write failures occur.
> Hmmm. I hope the firmware authors weren't that dense. I would imagine they do a write when you exit the brightness change menu.
This is not an option when using DDC/CI, where each brightness change is an isolated command. Plus, the OS is likely to emulate a smooth transition by sending even more commands than the end-user dictated.
Sure, the firmware could defer storing to EEPROM until a timeout from last command, but I would not credit the average display firmware as being that thoughtful.
> 100,000 is a typical eeprom guaranteed write count.
No, it's usually an estimated write endurance at a certain voltage and at 25°C, with the number based on calculated risk of failure being lower than a non-zero threshold. Higher temperature and voltage leads to higher failure rates.
I have dealt with several EEPROMs dying after just thousands of writes, including ones in products manufactured at a previous employer (where the EEPROMs were replaced with modern flash). Reserve EEPROMs for when writes are the exception.
I tried to find a source for these concerns. Although I can find documentation on DDC (until 1998) and EDDC (since 1999), and indeed read that these often use EEPROM, I cannot find any reference of someone who broke his monitor by changing the brightness too often.
This utility is very useful combined with the adaptive brightness of my iMac so I am tempted to use it. But I would appreciate any supporting evidence of this concern.
You never know if a wear leveling algorithm has been implemented so flash type isn't going to make lifetime determinable. Even without, 100 erases a day will last for 3 years or longer.
My monitors rarely last that long (at least, before I find it's worth it to upgrade), but like a lot of folks, I put most of my money into good monitors, keyboards, and color laser printers rather than the computers themselves, because I can generally get at least 5-10 years out of the peripherals. Computers themselves rarely last me more than 3-4 years, although my wife still uses one of my old Surface Pro 3s as her main computer - it's held up better than the SP4s.
If I could get a pair of Surface Studio touch monitors to dock with a Surface Pro/Book, I'd buy them, but yeah, I'd be real careful with them, too...
Worrying about this is the main reason we don't ship DDC/CI with f.lux. (I know that some more modern monitors use NAND and don't have limitations like this.) Anyone know if these fears are overblown?