Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cores that don't count

muratbuffalo.blogspot.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Cores that don't count

#21

Post by Dylan16807 »

slver wrote: post #18
Dylan16807 wrote: post #15

Earlier quoted context omitted.

Maybe, but in most situations you're probably better off adding some more developer time to work on software bugs than you are doubling your computation cost.

This kind of problems we're discussing and software bugs are not the same thing. A memory bit flip is not really a software bug is it

Of course they're not the same thing. But they both make things go wrong. There are situations where hardware bugs are important, and there are situations where hardware bugs don't make a meaningful difference.

Re: Cores that don't count

#22

Post by rejectedandsad »

Nacraile wrote: post #12
rejectedandsad wrote: post #11

Earlier quoted context omitted.

Why is that a joke? There's a reason why AWS is pushing Gravitron so hard (and they are pretty damn fast)

Why would one presume that the reason has anything to do with computation error rates, rather than something obvious and mundane like "Graviton instances are more profitable"?

Controlling the entire stack, from control plane to core layout is absolutely better for isolating computation error rates if they occur.

Re: Cores that don't count

#23

Post by sennight »

Detection is certainly the harder part - but the rest of it is pretty well-trodden ground. Some POWER9 users noticed that linux was under-reporting their core count and further investigation showed that the CPU's RAS had identified some cores that were acting a little funky - so it automatically dropped them into a guard partition and logged the action in the persistent circular buffer that nobody had bothered writing open source code to watch. Of course IBM had already written a ton of software that had it covered in AIX. I've noticed the same thing on a lot of other platforms, I'm looking at an HP MicroServer right now that has low level hardware error logging that never makes it past the bios firmware - and I've been meaning to fix that for about two years now. It might be a good idea to tackle that issue before we start getting too clever with solutions.

Dynamic reconfiguration: Basic building blocks for autonomic computing on IBM pSeries servers

https://sci-hub.se/10.1147/sj.421.0029

Re: Cores that don't count

#24

Post by cmeacham98 »

etaioinshrdlu wrote: post #9

Maybe we should run the code twice on different cpu architecures and only accept the results if they are identical. I’ve heard of high reliability environments doing this, but maybe there are cases for doing it in web/IT as well. This would help catch a large variety of possible errors, including but not limited to cpu bit flips, cpu bugs, memory errors.

In my experience, achieving perfect determinism across two architectures is a problem that cannot be easily hand waved away.

For 99% of cases it is fine, but when you run into that last 1% it hurts.

Re: Cores that don't count

#25

Post by hypertele-Xii »

remram wrote: post #10
hypertele-Xii wrote: post #5

Earlier quoted context omitted.

wait... consensus algorithms exist? can they work for human brains? experiment : tell a bunch of people that if they form consensus about, say, a color, they all get $5 (or whatever). have them attempt to reach consensus only using the exact mechanisms of a consensus algorithm. (research what they are)

You mean if people perform a successful vote on something they don't care about, you'll give each $5? You don't think anyone could do it in under a minute?

Yeah but like not face-to-face. Using the algorithm, but running on humans. Like the old human computers.

Re: Cores that don't count

#27

Post by YetAnotherNick »

> A deterministic AES mis-computation, which was “self-inverting”: encrypting and decrypting on the same core yielded the identity function, but decryption elsewhere yielded gibberish.

This is such a unlikely thing to happen that it is likely a fault in software that is used to validate this.

Re: Cores that don't count

#28

Post by throwaway2048 »

YetAnotherNick wrote: post #27

> A deterministic AES mis-computation, which was “self-inverting”: encrypting and decrypting on the same core yielded the identity function, but decryption elsewhere yielded gibberish. This is such a unlikely thing to happen that it is likely a fault in software that is used to validate this.

all it takes is something that reliably bitflips a key holding register

Re: Cores that don't count

#29

Post by extrapickles »

Someone wrote: post #17
extrapickles wrote: post #8

What needs to happen is to bring ECC to all levels of a chips logic to solve this. ARM vs RISC-V vs x64 doesn't address the problem as nothing in them inherently solves the problem. Making adders that add with ECC will. If all of the logic also operates on ECC with the data, chip yields will also be improved. Say an core of the chip only produces the correct result 99% of the time, currently you have to disable that…

I’m fairly sure you can’t do that. For example, suppose you have logic that uses some inputs to compute an output: A, B ⇒ C Add ECC bits to the inputs, and you want Aa, Bb ⇒ Cc Now, if you want this to detect errors made by the “⇒” part, you can’t do this as “drop the ECC bits, compute the result, compute the ECC bits of the result”. So, how do you compute the ECC bits from only the Aa and Bb bits without having to c…

You would have to develop a ECC that worked similar to homomorphic encryption, where you can do computations on the chipertext (or in this case, the ECC) without knowing the plain text. For this application, plain text would effectively be the int/float you are doing math on.

Since its possible with crypto, I don’t think it’s an insurmountable problem to create an ECC code where

Ecc(a+b)=Ecc(a)+Ecc(b)

It will likely not be as bit efficient as ECC without that property. Checking the ECC would also add a bit of overhead, so at first you would want to only check on a store instruction where you have to wait to select the RAM page anyways.

Re: Cores that don't count

#30

Post by remram »

hypertele-Xii wrote: post #25
remram wrote: post #10

Earlier quoted context omitted.

You mean if people perform a successful vote on something they don't care about, you'll give each $5? You don't think anyone could do it in under a minute?

Yeah but like not face-to-face. Using the algorithm, but running on humans. Like the old human computers.

All you need is for one person to propose something and a majority to say they agree? Is that what you mean?
Post reply on HN