A programmer writes about functional programming, OCaml, and why computers should use error-correcting memory, with opinion pieces on languages.
HN cites its ECC memory articles for bit-error rates; commenters say the first estimate was flawed, was revised after criticism, and still seems too high.
lol @ "they should sell hard disks with 10^15 reliability instead of 10^14!" This is the funniest outrage I've seen in a while, just because the suggested fix is so specific and (relatively) low for the huge amount discussed.
It's like saying, "It's an outrage that this drink holds only 37 ounces! For this kind of money I expect it to hold at least 38 ounces. I would pay for that."
-
My 4 downvoters are clearly a lot worse at math at I am.
Let me spell it out for you:
"Reliability of 100000000000000 is unacceptable! I need exactly 1000000000000000 of reliability (a factor 10 difference only)."
If you don't see how that is funny, the problem is with you, not me. That's a hilariously specific, and small, change.
"Man, having a 30% chance of a bit flipping if I read 4 TB is unacceptable. I should have to read like...40 TB for a 30% chance of a bit flip!"
It's particularly funny because in the face of this being unacceptable, I would expect a solution, like error correction, that adds 5-10 orders of magnitude (many bit flips have to all happen in the same sector, by coincidence, at the already low 10^14 rate), for it to make it past the error correction layer.
The other thing is that given that we're talking about ERROR RATES, I cannot possibly believe that they have it down to such a specific number as 100000000000000. It would have to be a range. You should target more than 1 order of magnitude to get something more reliable (like ECC RAM versus regular RAM).…
Well, I might have been the first to put OCaml in space, specifically on low-Earth orbit aboard GHGSat-D in 2016. I designed the payload software as a collection of SystemD services talking over DBus, and it included a CCSDS-to-DBus bridge to talk to the platform (the thing that hosts the payload, controls and steers the satellite). The payload also did perform symmetric-key encryption of the resulting data, as per regulations.
I gave a talk about the payload software at the Paris OCaml users group.
The reason for selecting that archicture was that I didn't expect to write the whole payload software by myself, and I assumed that when some other developers join in they would, obviously, not want to use a weird language like OCaml, and so they could write their portion in C/C++/whatever and the system could still work. Of course that didn't happen.
I'd be surprised if the company still uses OCaml, as the standad tendency is to revert to "industry-standard" languages to get industry-standard problems. The whole processing and simulation toolchain was also written in OCaml.
Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them.
EDIT: Found my slides https://lambda-diode.com/static/data/GHGSat_OCaml.pdf
I want a laptop with 64 or 128 GiB of Chipkill ECC RAM. Any of this soldered-on, anti-R2R/-consumer Apple trend-copying is BS. This crap about "YAGNI" or "it costs too much" have no idea what they're talking about and don't understand the reasons or use-cases.
At home, I may have a 96 core EPYC with 512 GiB of Reg'd ECC RAM, but it doesn't have the locality or reachability of something that's with you. Network presence and low-latency aren't a given.
https://en.wikipedia.org/wiki/Chipkill
Edit: Resources:
https://cr.yp.to/hardware/ecc.html
http://lambda-diode.com/opinion/ecc-memory
https://tedium.co/2021/01/06/error-correcting-code-memory-history/
[PDF] https://defcon.org/images/defcon-21/dc-21-presentations/Schultz/DEFCON-21-Schultz-Examining-the-Bitsquatting-Attack-Surface-WP.pdf
DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (trivia: at the time of filming, I was excessively-hungover and laying across 6 seats in the middle of an empty area to the extreme right, from the podium's perspective. I did watch the presentation with sunglasses on indoors because my eyes weren't cooperating nicely with photons.)
https://youtu.be/aT7mnSstKGs
Edit follow-on:
And I don't want to lug-around a 17" Russian tank laptop that needs wheeled tracks to move. 13-15" max.
This is absolutely true. Every time you run it, a non-prime has probability of at most 1/4 of passing.
Run it 5 times, and you'll catch 99.9% of non-primes.
What about neutron flips? Judging from http://lambda-diode.com/opinion/investigations/transmutations/.../ecc-memory-3 you can probably expect one every 4-5 years.
If you run MR 20 times, your odds of wrongly declaring a non-prime prime are on the same order of magnitude as the number of microseconds in a 5 year period. So yes, neutron flips and MR errors are on par with each other.
If you're concerned, just run MR a few more times. :-)
Great thanks!
[edit]
Looks like the calculation was revised [0] after criticism:
> Under these assumptions, you'll have to wait about 33 to 600 days to get a 96% chance of getting a bit error.
What's more worrying is the variance, the above calculation is based on expected well behaved DRAM.. yet some computers just seem to have manufacturing defects that make the incidence of errors high enough to be a regular problem.
[0] http://lambda-diode.com/opinion/ecc-memory-2
Why do you consider ECC the biggest scam out there?
Btw, is there any updated paper/source with some stats on bit-flip odds in modern computers?
Last I've read was this one [1] but it's been debated to death. [2] [3]
[1] http://lambda-diode.com/opinion/ecc-memory
[2] https://news.ycombinator.com/item?id=1109401
[3] https://www.reddit.com/r/programming/comments/ayleb/got_4gb_ram_no_ecc_then_you_have_95_probability/