ECC seems to correct only single bits errors.
Correct. To correct more errors would require more bits. As it is, you already use 10 bits to store 8 bits of information, 'wasting' 20% of the memory chips to allow to a single bit correction and up to two bits of error detection.
It works as follows. Imagine a
0 or an
1. If I read either then I just have to hope I read the right thing. If a 0 got flipped to a 1 by some cosmic radiation or by a bad chip then I will never know.
In the past we tried to solve that with parity. Parity was adding a ninth bit per 8 bits stored. We checked how many zeros and how many 1 were in the byte. The ninth was set to make that a even number. (for even parity) If you ever read a byte and the number was wrong, then you knew something was wrong. You do not know which bit was wrong though.
ECC expanded on that. It uses 10 bits and a complex algorithm to discover when a single bit has flipped. It also knows what the original value was. A very simple way to explain how it does that would be this:
Now you can read six combinations:
We are never 100% sure what was originally stored. If we read
000 then that might have been just the
000 which we were expecting, or all three bits might have flipped. The latter is very unlikely. Bits do not randomly flip, though it does happen. Let say that happens one in ten times for some easy calculations (reality is much less). That works out to the following chances of reading the correct value:
000 -> Either
000 (99.9% sure), or a triple flip (1/1000 chance)
001 -> We know something has gone wrong. But it either was
000 and one bit flipped (1:10 chance), or it was
111 and two bits have flipped (a 1:100 chance).
So let's treat it as if we read
000 but log the error.
010 -> Same as above.
100 -> Same as above.
011 -> Same as above, but assuming it was a
101 -> Same as above, but assuming it was a
110 -> Same as above, but assuming it was a
111 -> Either
111 (99.9% sure), or a triple flip (1/1000 chance)
111 -> Either
000 (99.9% sure), or a triple flip (1/1000 chance)
ECCs does similar tricks but does it more efficiently. For 8 bits (one byte) they only use 10 bits to detect and correct.
ECC registered RAM is only usable with workstation / server boards
ECC unbuffered is usable on Intel Xeon lga1155 or AMD AM3+ on Asus boards.
I already mentioned what the ECC part was, now the registered vs unbuffered part.
In modern CPUs the memory controller is on the CPU die, starting long ago for AMD Opteron chips and with the Core i series for Intel. Most desktop CPUs then talk directly to the DIMM sockets holding the RAM. It works and no extra logic is needed. That is cheap to build, and the speed is high because there's no delay going from the memory controller to the RAM.
But a memory controller can only drive a limited current at high speeds. This means that there is a limit to how many memory sockets can be added to a motherboard. (And to make it more complex, to how much the DIMMs can use, which leads to memory ranks. I will skip that since this is already long).
On server boards you often want to use more memory than a desktop system. Therefore a "register" buffer is added to the memory. Reads from the chips on the DIMM first get copied to this buffer. A clock cycle later this buffer connects to the memory controller to transfer the data.
This buffer/register delays things, making memory slower. That is undesirable and thus it is only used/needed on boards that have a lot of memory banks. Most consumer boards do not need this, and most consumer CPU's do not support it.
Directly connected, unbuffered RAM vs. buffered/registered RAM isn't a case where one is better or worse than the other. They just have different trade-offs in terms of how many memory slots you can have. Registered RAM allows more RAM at the cost of some speed (and possibly expense). In most cases where you need as much memory as possible, that extra memory more than compensates for the RAM running at a slightly slower speed.
The doubt I'm having is (mainly concerning asus am3+ board):
is ECC-unbuffered RAM as good as ECC-registered RAM (from the point of
view of safety and reliability) ?
Or is it a worse choice. I don't care much for the speed.**
From the standpoint of safety and stability, ECC-unbuffered and ECC-registered are the same.
More details: server will use a server case with up to 24 x 3 ½''
drives and should consume as little as possible.
24 drives are going to consume a lot of power. How much depends on the drives. My 140GB 15K RPM SAS drive is drawing a mere 10 watt at idle, same as the 1TB SATA 7k2 disk. At use both draw more.
Multiply that by 24. 24x10 Watt at idle means 240 watts just keeping the disks platters spinning, overcoming air resistance. Double-ish that for in use.
LGA1155 seems to be in that sense a better bet (TDP ~ 20-95W) versus the
others (>80W) for twice the price.
Intel is better at low power CPU's, at the time of writing and for the CPU's you mentioned.
Any suggestion is welcome.
Let's say less than 120W at idle (~ with 10 hard disks out of 24).
If you go for FreeBSD, look hard at ZFS. It can be great. Many of its more advanced features (e.g. deduplication and/or compression) use serious CPU power, and want plenty of memory. ZFS for basic use with ZRAID will do fine on both CPU sets you mentioned and with 16 GB, but if you turn on features like deduplication you should look carefully into the recommended memory needed for your disk capacity; up to 5GB per TB of storage is recommended by some guides.
Two more things:
- I did not see anything about connecting the drives. Some boards may go up to 10 SATA ports. But for anything over that, you will need add-in cards. If you consider hardware RAID then it might be best to plan that from the beginning.
- Drive failure: Should you use SATA port multipliers then look carefully how they act if a SATA drive fails. It often is not pretty. Not a big problem for a home setup, but very much not enterprise grade. You may need to consider how individual drives handle errors too. The reason some drives are labeled as being for "NAS" or "RAID" use is that they handle errors differently than regular drives. With no RAID, you want the drive to retry as many times as possible. With RAID, you want the drive to fail quickly, so you can read from another copy.