Comment by hinkley | Hacker News Reader

Comment by hinkley | Hacker News Reader

I am utterly in awe every time there's a breakthrough in durable random access memory, where someone (often the author) is so very excited about how this will mean we will never have to power off our computers again. Flip a switch and it's instantly on!

Have you lost your ever-loving mind? Of course you're going to reboot. Bit rot improvements have only ever been incremental. To a first order approximation we've expanded from a day or two to a couple of weeks/months for general purpose computers (I argue that servers are not GP, and so their spectacular uptimes don't translate).

In thirty years, that's barely more than an order of magnitude improvement. You're gonna need a couple more orders than that before taking away the reboot option sounds anything like sanity. If you can keep a machine from shitting the bed for 2-3 times longer than the expected life of the hardware, then we can talk, but I'm not making any promises. Until then I'm gonna reboot this thing sometimes even if it's just placebo.

Quite a bit of our infrastructure runs for very long periods (long in IT terms) - years between faults or reboots.

Sure lots of domestic modems & routers have to be reset often, but it's common to find infrastructure routers that are only reset when they have to be moved! Says a lot about the software in domestic equipment.

I've worked with a mainframe that ran for a decade, and was only rebooted when a machine room fire required a full powerdown "right now"! But people are impressed when their Windows stays up for a few day %#%$#@#$!!

And remember Voyager, been ticking along since 1977.

But all these impressive systems are built to be impressive. Probably error correcting RAM, etc. Shows we can build reliable hardware. And if a substantial fraction of users wanted it, things like ECC RAM etc would be only fractionally more expensive than our error prone alternatives.

Of course,

how much of that hardware can run a random executable from the web? and does so pretty often?

That’s a fair point but kind of seems like a straw man compared to the Voyager example

My argument was towards the network/IT equipment, but Voyager is even more special since it's a very application specific system.

Generalization itself is hard, it gets MUCH harder when you have to care about back compat and random executables that can alter system state because previous versions allowed that behavior and it needs to be supported for the common cases moving forwards.

This is what I meant by that parenthetical about not being general purpose.

A computer used for a single task is a bit like a 4WD truck that only stays inside the city limits. It could do those things, sure, but it never does, so it hasn't really proven anything.

> A computer used for a single task is a bit like a 4WD truck that only stays inside the city limits. It could do those things, sure, but it never does, so it hasn't really proven anything.

Not really. That's very different from a very application specific hardware+software being used for the exact purpose vs a very general purpose hardware+software being used for all sorts of things.

It's more like using a F1 car to race vs taking your average sporty car to a race track.

Sure that F1 car will race better, but at the end of the day you can't drive home in it or move kids/groceries around in it.

No disagreement in general, but to your point of infrastructure routers (assuming you refer to ISP and Internet backbone infrastructure):

Having worked in ISP security, IMHO a years-long uptime of such critical components is nothing to be proud of (anymore). Quite the contrary, those are complex components, so if you care about security you have to regularly patch them, including occasionally required reboots. Just look at the list of security advisories of relevant vendors (Cisco, Juniper, Nokia/Alcatel-Lucent, etc), you can find scary vulnerabilities! Granted, "rebooting" a core router is more nuanced than a regular PC (you can e.g. reboot one management engine of a pair; or just a line card; etc), so it does not always mean that the entire traffic stops because of it.

Oh and btw. your network design should be able to cope with such necessary reboots, otherwise you have a single point of failure.

Regards

All DDR5 DRAM ICs have on-die ECC. This is new for DDR5.

And the highest data rates to date with the signal integrity requirements that accompany it. Got a piece of dust pushed down by your CPU cooler saddling two DIMM pins? Get ready for your machine to shred your data. And that's just a common simple scenario. I's be surprised if real world error rates in nominal scenarios won't be higher than with DDR4.

You may be right, however, you could have said the same thing for ddr4 vs 3, with its crazy new high data rates!

And again still likely be right. 10 years ago consumer electronics marketing never included signal integrity stuff like eye diagrams but now pretty much every nvidia announcement with a new memory standard does. We're really pushing ever closer to channel bandwidth limits and corners that could be cut in the past can no longer be cut. ECC is more important than ever.

That's not the type of ECC the parent was talking about. That's because the densities and clock rates are so high for DDR5 that it needs ECC to function properly, but like most standards the minimal implementation is really quite watered down. It doesn't correct the entire range of bitflips that a server with ECC RAM does.

Disagree. Parent was discussing the need to reboot after a system has been on for a long number of hours. The failure mode, assuming it's related to the DRAM, would be an accumulation of bit-flips in the DRAM. Every memory has some FIT/Megabit rate. The on-die ECC added in DDR5 spec will be highly effective in addressing this failure mode.

Channel ECC is the ECC type most directly relevant for high clock rates and signal integrity aspects. I agree with you that Channel ECC becomes a practical requirement to meet the interface transaction rates of DDR5. It is also true that channel ECC is not mandatory in DDR5 and is not implemented by mainstream CPU platforms (like previous DDR generations).

If the on-die ECC reduces the error rate but the lack of standard channel ECC increases the error rate, because of the much more demanding signals, then it's not clear at all that the overall rate of error will lower.

In fact it could very well be higher depending on how the physical module is designed.

I imagine some portion of bit-flip induced reboots are due to the actual DRAM chips, but also some portion will be due to everything else that can bit flip both on the memory module itself and in the interconnect.

I haven't seen anything yet to say that DRAM chip bit flips will be in the majority.

It's never been clear to me if the ECC is necessary for DDR5 to operate, or just a nice feature. Do you or any other readers happen to know the answer?

> And remember Voyager, been ticking along since 1977.

This is running a single unthreaded process.

My Mac, which isn't doing anything fancy, has over 500 processes running on it. In fact, I just checked to see if anything bad was going on, and I recognize everything I look at - almost 100 processes from Chrome alone, for example.

How sure am I that all of these processes are running correct code? Chrome is running "101.0.4951.54 (Official Build) (x86_64)", which gives a hint of the disposable nature of that binary.

> And if a substantial fraction of users wanted it, things like ECC RAM etc would be only fractionally more expensive than our error prone alternatives.

I started in the PC industry in 1988.

Then, they did. All IBM PC kit used 9-bit RAM, with a parity bit.

It was discarded during 1990s cost-cutting.

I don’t see any relation…? What’s stopping you from rebooting a system with NVRAM? What’s stopping you from shutting it down? Hibernating it? Nothing.

However, NVRAM enables power-efficient sleep. My old ThinkPad used almost all of its battery charge overnight in S3 standby. On the unreasonable efficiency of instant-on computers

That seems very poorly designed. My Acer, a 5 year old laptop, uses a few percent at best overnight.

My “old ThinkPad” is now 15 years old, so yeah. Things have improved a lot since then.

It was only after people got used to Microsoft products, for which the company categorically refused to refund anybody, that they would not consider needing to turn things off and on as a reason to send them back for a refund.

Probably the FTC should have stepped up and ordered Microsoft to issue refunds. But they didn't, and here we are.

You are not wrong. Bill Gates is the hero of his own story, but the villain in millions of others. I mean this as a joke (or do I?) but the service Larry Ellison provides by the barrel and Steve Balmer provides by the glass is keeping Bill Gates from being the biggest bastard currently living (I gather that the Carnegies or Rockefellars were not great people half the time either). As a certain defrocked comedian used to say, they're old and they're trying to buy their way into heaven.

Even with perfect hardware you will still have to reboot due to software instability. Lots of software isn't even tested to run for weeks/months/years.

That is just the Microsoft effect. Before Microsoft, anything that didn't run through the entire warranty period was returned to the vendor for your money back. And, you got it.

Before complex GUIs. Ftfy

GUIs do nothing more complex than many things that have to work right, so do. It is only tolerance for crappy software that allows it to be foisted on us.

The Therac-25 (https://en.wikipedia.org/wiki/Therac-25) didn't have a complex GUI. However, I hope that those affected by that bug did get their money back (and then some). Not that money can really help you if you get exposed to fatal levels of radiation, but...

I'm also speaking of e.g. the junkware running on automotive headunits. These systems are expected to be shut down at least once a day, so overall focus on (not only long-term) stability is really low.

Those came in post-Microsoft. Peak Microsoft was the US Navy ship dead in the water, towed back to port, because they had stupidly put MSWindows in charge of it.

The only reason I reboot my Linux laptop, or desktop, is when a kernel update appears. This can even be a year.

I run xorg, and requiring X11 to restart is equally rare. Thus, I often go for months or longer, without a restart at the gui level.

If I get a browser update, I restart that, and so on.

Microsoft has conditioned the world to accept absurdity. Just the lost productivity alone, due to reboots...

Reply on news.ycombinator.com