The government imposed a 12% GST on all computer gear just because they felt like it. Would making ECC RAM GST exempt satisfy you?
34 karma · joined February 11, 2022
The government imposed a 12% GST on all computer gear just because they felt like it. Would making ECC RAM GST exempt satisfy you?
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.
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 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.
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.
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.
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 hope that my blog posts on these topics will save some people some money.
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.
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.
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?
I've seen this in DC grade SSDs, NAS grade hard drives, and SSDs sold in high end laptops.
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.
For the moment the Librem 5 seems to be using apps designed to work on PC desktops but at lower resolutions.
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.
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.
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.
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.