etbe

Why is taxing non-ECC RAM instead of ECC RAM more of a problem in this regard than the thousands of other taxes?

The government imposed a 12% GST on all computer gear just because they felt like it. Would making ECC RAM GST exempt satisfy you?

But no-one here has advocated banning anything. Please read before replying.

I respect the time of my readers by accurately presenting my claims. It seems that everyone other than you was able to understand "My experience of memory errors".

If it's none of your business why are you getting so involved in this discussion?

Good point. Some googling suggests that plastic may be better than metal as hydrogen absorbs high energy protons without generating secondary radiation.

The people designing RAM and motherboards and the people working at JEDEC will of course know more about these things than almost everyone who reads hacker news. But I'd still prefer not to just blindly trust that they do the best things for us and have some documentation available.

Is anyone here good at navigating patent records? I would be surprised if there isn't something to be revealed in a patent but I don't know how to find it.

How do YOU propose doing this when most computer "experts" have never used ECC RAM and when it's only available in high end specialist systems that aren't on sale in regular computer stores?

I think my knowledge of the topic is pretty good but I learned from this discussion that almost all AMD CPUs support ECC RAM and you apparently just need a motherboard to match. When accompanying people who were buying "gamer" PCs (after they rejected my recommendation for a second hand workstation grade computer with ECC RAM) I never witnessed store staff saying "hey you could get a motherboard with ECC support".

The original IBM PC/XT had parity RAM. In the early PC/XT and PC/AT clones you had banks of 9 DIP sockets for memory chips with the 9th being for parity.

The DDR4 ECC RAM has 72 bits total and 64bits of data which means the same 9/8 ratio of data storage to usable data as the original PC/XT.

The Z80 and 6502 based computers in the 80s typically didn't have parity RAM. The Amiga and Macintosh were higher performance systems in the 80s which also didn't have parity RAM.

We could and should have gone straight from parity RAM to ECC RAM for everything.

I'm planning some RAM purchases for the end of this year, I expect the crash to happen in a few months.

BTRFS has checksums on all metadata. It isn't designed to cope with bad RAM but has been shown to be somewhat resistant to it to the degree that BTRFS developers can recognise symptoms in problem reports.

Whether a filesystem could be designed to operate in the face of random memory changes would be an interesting computer science research topic. But for getting working systems having RAM just not fail is a better option.

No-one ever proposed making non-ECC RAM illegal, that's a straw-man.

Restricting risky items is standard practice for all governments. All the "use by" dates on food etc are from government regulation. The current experiments with "raw milk" shows that you can get away with flouting food safety regulations and not have immediate problems.

I can only report what I have seen. Feel free to write your own blog post reporting what you have seen.

Yes a kernel taint is a really good idea!

For second hand gear RDIMMs are significantly cheaper than UDIMMs. As all RDIMMs have ECC that means generally ECC is cheaper for second hand systems.

Aliexpress had $50 single socket motherboards for Xeon E5-26xx CPUs and $150 dual socket motherboards last time I checked that use DDR4 RDIMMs.

Before the prices went up due to AI foolishness DDR4 RDIMMs were $1.20AU/G means means something like $US0.80/G.

I have a HP Z640 that only has 3/4 DIMM slots working. Reseating the CPU didn't help and the same CPU works perfectly in another Z640. I never found out the cause. It was sold as "unknown condition for parts" so $50 for a server that works perfectly apart from one DIMM slot is still a good deal.

A very large portion of people who go from working on consumer grade systems to getting enterprise grade stuff for their home lab make a mistake like that, I did some similar things, my biggest mistake was spending $300 on non-refundable ECC RDIMMs without realising that my server (the cheapest Dell Txxx server) took ECC UDIMMs.

I hope that my blog posts on these topics will save some people some money.

https://www.theregister.com/on-prem/2021/06/04/fyi-todays-co...

Google and Facebook report a few unreliable CPU cores out of thousands of systems. Meaning maybe a 1/10,000 rate of repeatable CPU errors.

https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Google reports 8% of DIMMs being affected by errors. While the differences in metrics prevent comparing the two things directly it seems that DRAM errors are more common than CPU errors.

People outside the US have a significant lack of Internet functionality when there are problems with submarine cables, but it hardly ever fails. Apart from when certain countries sabotage things.

If you only need 100M deep water then you don't need to go far offshore, there are places where it's only about 1KM out. 12M of water is used for storing spent nuclear fuel assemblies and less than half of that is needed for protection so 5M should be adequate for stopping cosmic rays and that depth is common in harbours for recreational boating, such harbours shouldn't have issues of cable breakage.

But the real issue for comparing submarine and orbital computers is cooling. Space is cold but doesn't allow easy transmission of heat.

Companies making DRAM have no incentive to make the best products theoretically possible, they just want them good enough to not get many returns and avoid the risk of a class action lawsuit if a significant pattern of problems appears.

Avoiding returns for ECC DIMMs is a harder challenge when they are used in an environment where the server will have a management system that tracks errors over all time and when there might be a network management system tracking all errors over all systems.

Avoiding returns for non-ECC DIMMs is easy when a few errors per month won't be noticed by most users who assume that Windows always crashes anyway.

Has any DRAM company tested chips and made non-ECC DIMMs from the ones that have lower quality?

As an aside are the 2^N*3 sizes of DDR5 DIMMs (like 24G and 48G) made from chips that had errors in one section and got reconfigured to have 3/4 the capacity to not use the bad parts?

Does this imply that the all plastic gamer PCs (that are more designed to be art projects than serious computers) are bad and that everyone should be using systems with solid steel cases to block radiation?

The majority of storage errors I've seen since using BTRFS and ZFS everywhere have shown up only as the storage returning corrupt data and claiming it to be good. I've seen drives and SSDs return dozens of errors per month for months on end without any SAS or SATA errors or any SMART errors.

I've seen this in DC grade SSDs, NAS grade hard drives, and SSDs sold in high end laptops.

Systems with "consumer amounts of RAM" are often run with what you might call "consumer amounts of sysadmin knowledge" and not notice the errors.

One time I took a working workstation from my home to my parents' home to give them. When I booted it up it gave a lot of strange kernel errors which I googled and discovered were reports of ECC correction. I reseated all DIMMs and it was fine. If that gave errors a few times a year instead of thousands of times on the first boot I wouldn't have noticed.

I know a guy who uses old rack mount servers as workstations and he gets that. I guess it's a good option if you like wearing hearing protection at your desk as he does.

That sort of thing seems like a good idea. There are X programs (and presumably Wayland programs) that do similar things (like web browsers stopping things when switching to a different tab or minimising the window). But we could probably do better with different interfaces.

For the moment the Librem 5 seems to be using apps designed to work on PC desktops but at lower resolutions.

By default qtwayland5 is not installed, should this be considered a bug?

https://puri.sm/posts/my-first-year-of-librem-5-convergence/

The Purism CSO has been running a Librem 5 as his primary desktop PC for over a year.

When Plasma was first released I was probably running hardware slower than a Librem 5.

Web sites review phones based on weight. Phones are designed for review as a higher priority than being designed for use.

Do you know of a good web site explaining how this works? My Android phone used to kill my Jabber client all the time until I got to using Conversations which has a notification all the time which seems to be the way to avoid being killed while running in the background.

It would be nice to be able to reliably run background apps on Android.

Also as an aside Android doesn't appear to reliably kill background processes, it kills them if it thinks that something else needs the resources. Running the Facebook app is one way of triggering Android to kill a bunch of background apps.

My first Android phone was a Sony Ericsson Xperia x10i. With that phone I could go to sleep while playing music from the SD card and wake up 8 hours later with plenty of battery left. The same phone however would run out faster if doing stuff over Wifi or using GPS. It was mostly a matter of how much power different things took.

One of the things I want to do on my Librem5 is monitor my servers, so that will involve polling things every few minutes. PowerTop says that I can save power by changing the polling for USB, but that changes Wifi ping times from ~1ms to ~350ms. Eventually I'll probably try experimenting with that to get an option with a 10ms ping time that still saves some power.

All programs on the Librem5 appear to be in Debian packages and most of them seem to be identical to the ones in Debian. The document you cited has procedures for getting packages in PureOS independently of Debian, but it seems that most of it will be stock Debian. For my development it seems easier to just upload to Debian and wait for the next Debian release for it to be officially part of PureOS, I'll setup my own apt repository for the things I do and publish the URL for anyone who's interested.

As for apps being suspended, most apps are suspended when there's nothing to do. If a graphical application is minimised so it doesn't have to redraw the screen then it should either be doing nothing or occasionally polling a server if that's it's design.

Web browsers are an interesting corner case as web sites often have JavaScript that wants to run all the time and there's some trade-off between doing what the web site wants and saving CPU/energy. But that's probably not going to be an OS issue for PureOS but an Epiphany browser issue.