Tony_Scarpelli :
Xeon with ECC is about 15% slower than non ecc ram with Xeon or i7.
Speed is not the reason to go with Xeon Ecc setup.
Everything I have seen says that ECC adds a very small (0.5-2%) loss in performance compared to the same type of non-ECC RAM. The overhead in ECC memory is in the memory controller performing the error detecting calculations.
non ecc ram will have a soft error 1 in every 6-24 months the way most of us use our computers. This error might but not always end up in a hung program or even a crash. Software has some ability to correct errors for example corrupt data won't be saved to disk without being checked, and refused and resent for.
This is why Intel recommends Xeon/Ecc as a Mission Critical solution. ECC has a 9th chip to keep the parity bit.
Memory errors occur when a memory cell that holds active data unintentionally changes the value of the stored bit of data. This can occur because of a defective memory module, RF interference, DIMM age, or background radiation. So if you use a small percentage of your available RAM, you will see fewer errors. If you do not do many r/w operations to your RAM, you will see fewer errors. If you live in a place with lower than normal background radiation, you will see fewer memory errors. Most people have no clue as to how many errors really occur on their systems since systems running non-ECC memory do not detect memory errors. The errors silently occur and may do anything from having no effect at all all the way to causing a BSOD or kernel panic. Just about all servers have ECC memory and servers can log ECC errors. Google did a study of its servers and found that they had 25,000 to 75,000 errors per billion device hours per Mbit of RAM. That works out to one error every 2-5 hours per GB of RAM. Other studies quote anything from figures similar to Google's all the way to one error every 100 years per GB of RAM. Google's data comes from servers that they run at high CPU and memory usage levels, other studies quote other usage figures.
I have several systems that use ECC memory:
1. Workstation- 5 ECC errors in 12 months of operation, has 16 GB of memory. Fairly constant use of about 4 GB of memory. This works out to one error per GB of memory occurring every 3.2 years. Note that the ECC errors all happened when I was running CPU and RAM-intensive applications on the machine.
2. Old file server- no ECC errors recorded in 15 months of operation, had 1 GB of RAM. This system rarely saw any real loads and had a static RAM usage of about 50 MB.
3. Current server- no ECC errors recorded in six months of operation, has a fairly constant use of about 2 GB of its 4 GB of memory. Again, it doesn't have much CPU usage.
4. HTPC- while it uses ECC memory and ECC works, its chipset is bugged (Intel E7520) does not notify the OS when it has an error. One has to look in the BIOS error logs for ECC errors. The last time I checked it, it had no errors in six months of operation using 1 GB of RAM. It uses about 400 MB of RAM. I recently upgraded to 6 GB of RAM (somebody was giving away RAM) and haven't rebooted to check if there are ECC errors logged.
So in my observation, ECC errors do happen but they are not all that common UNLESS you run something CPU and RAM-intensive that needs a lot of RAM. Then you will likely see ECC errors and may want to detect and correct them. Your software likely does not do any error detection and correction apart from crashing if the error causes an overflow or a pointer to reference an invalid address or other problem that causes the program to have a segmentation fault and crash. An error that still results in "valid" data will cause your program to mis-calculate everything from there on out and your result will be screwed up.
Similarly Unregistered memory is faster than Buffered memory. Buffered mem is for higher energy requirements and is useful in really large memory and also slightly slows the memory function as it has what amounts to a wait state as it clears the registers.
Assessing the performance difference between registered DIMMs (RDIMMs) and unbuffered DIMMs (UDIMMs) is very difficult as it depends a lot on your computer's setup and your workload. Registered memory delays all read and write commands by one clock cycle compared to unbuffered memory for the first clock cycle of a burst memory operation. Thus big long streaming operations on RDIMMs are essentially the same latency as on UDIMMs, while very random accesses are slower on RDIMMs. RDIMMs also allow for a 1-cycle command rate with multiple DIMMs compared to needing a 2-cycle command rate with two UDIMMs in a channel, which means that both UDIMMs and RDIMMs thus have the same 2-cycle effective command rate with two DIMMs per channel. Also, recognize that you can put a MUCH larger quantity of memory in a system using RDIMMs than UDIMMs because RDIMMs can use many more memory ICs per DIMM than UDIMMs can, plus you can have three RDIMMs per channel compared to two UDIMMs. UDIMMs can have up to two 64-bit ranks per DIMM using 8-bit-wide memory ICs. Current state-of-the-art memory tech is 4 Gbit ICs, so you can have 8 GB per unbuffered module and stick four of them in a dual-channel machine, good for 32 GB. Registered DIMMs can have up to four 64-bit ranks using either 8-bit-wide or 4-bit-wide modules. You could stick 64 four-bit-wide data ICs (or 72 with ECC) on a single module to make a 32 GB module. You can stick up to six of those in a dual-channel machine, good for 192 GB of total RAM. Caching data in RAM is a lot faster than reading it from disk, so having a lot of RAM for disk caching can lead to considerably better performance. However, registered memory usually carries a considerably premium over unbuffered, so you may be able to afford more unbuffered than registered memory.
Oh, and I should probably add a little bit about Fully Buffered DIMMs as well, since "buffered memory" generally refers to FB-DIMMs. FB-DIMMs are a special type of registered DDR2 that was mostly used on Intel's previous-generation Socket 771 Xeons as well as in a few other low-volume servers such as some Sun UltraSPARC units. They are not compatible with any other kind of DDR2 and won't even physically fit in a slot designed for other kinds of DDR2. It's essentially a cross between Rambus's RDRAM and DDR2, with a serial rather than parallel memory interface, very high memory cost, and memory that runs extremely hot. It's also very slow compared to any other kind of DDR2 with extremely high latencies. The appeal of FB-DIMMs were that you could stick 8 DIMMs in a single channel and that it was much easier to route the wires on the motherboard to FB-DIMMs than with conventional DDR2 (or DDR or DDR3 for that matter.) Intel ended up abandoning FB-DIMMs for conventional registered DDR2 for its last LGA771 Xeon chipset (i5100 "San Clemente") and used normal DDR3 in the next generation of servers (Nehalem, Westmere.)
)
Facebook
Twitter
Instagram