Build Your Own PC
Let us help you get it together, so you can put it together

Skip navigation
Help
 All Forums
 PC Hardware Discussion
 Memory
 New Topic    Topic Locked

All Forums ECC RAM Performance

Author
Page: of 2
Page: of 2

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 19 Aug 2006,  00:35:59  Show Profile
After discussing how much slower ECC RAM might be earlier today, I decided to do some tests to see if it really is much slower compared to non-ECC RAM.

First, some background information:

ECC is Error Checking and Correction in this instance. It allows the detection of one or two errored bits and the correction of one bit. to do this, an extra chip is used. This means that ECC memory is 72 bits wide rather than the usual 64 bits for SDRAM.

The BIOS on the the motherboard, a Tyan S2466 has two ECC settings:

1. ECC Config:
Disabled - No Error checking at all
EC - Error checking active but no data correction
ECC - As EC above but data is also corrected
ECC Scrub - as ECC with memory contents corrected

2. SERR Signal Condition
None
Single Bit - Signal one bit error
Multiple Bits - Signal multiple bits errored
Both

The memory used was 4x 512 MB ECC Registered DDR266 (PC2100), 2.5-3-3-7 Crucial Memory.

The memory speeds were checked with Memtest86 v3.2.

Initially, the SERR option was set to 'Both'

Testing started first with ECC switched off then cycling throught the remaining options: EC, ECC & ECC Scrub. For all cases the following results were observed:

Level 1 cache: 12,269 MB/s
Level 2 cache: 3,905 MB/s
Main Memory: 542 MB/s

It's surprising that the readings were all the same, with and without ECC. Even with the SERR setting set to Disabled, the readings were the same.

To prove that the readings from Memtest86 were meaningful, it was run on an ASUS A7N8X with 2x 512MB DDR266 (PC2100), 2.5-3-3-7 Dual Channel Memory, with the following results:

Level 1 cache: 12,250 MB/s
Level 2 cache: 3,899 MB/s
Main Memory: 963 MB/s

Apart from the Main memory speed which is due to the dual channel, the readings are consistent.

So the question is this:

Is the difference in ECC memory speed only subtly different such that it is too small to be noted? If the ECC speed was only 1 MB/s less, this would only represent a loss of about 0.2%. Given that not only are there ECC circuits, but also registers as well, it is very surprising that no differences were noticed.

If anyone can recommend another (free) bit of software that benchmarks memory speeds, I would be prepared post more results.


Replies

TyranuS
Prehistoric PC Builder

United Kingdom
3784 Posts

Posted - 24 Aug 2006,  14:36:31  Show Profile
Try SiSoft Sandra 2005 SR3 for memory benchmarking.

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 25 Aug 2006,  21:19:09  Show Profile
OK, thanks for the suggestion. I duly downloaded and installed SiSoft SANDRA Lite 2007.9.10.105, ran the "Memory Bandwidth" benchmarks and received the following results:

ECC Scrub
Int ALU: 1352 MB/s
Float FPU: 1312 MB/s

ECC Disabled
Int ALU: 1350 MB/s
Float FPU: 1312 MB/s


So these results reflect those of memtest86. It's looking like the burden that ECC puts on memory performance is neglegible.


Simpsoni28
Advanced PC Builder

United Kingdom
2818 Posts

Posted - 25 Aug 2006,  21:31:53  Show Profile
errr... so ECC actually increases bandwith??? how random...

Project Arctosa: Asus P8Z68-V Pro | Intel i7-2600k | 16GB G-Skill 1600mhz RipJawsX DDR3 RAM | 2x Palit GTX570 Sonic Platinum (SLi) | 2x 64GB Crucial M4 SSD (RAID0) | 2x 2TB Samsung F4 | 2x 1.5TB Samsung F3 (RAID0) | 2x 24" Dell U2410 | Coolermaster HAF X | Corsair HX1050W | Hauppage HVR-1700 | Creative X-Fi Titanium | Logitech Z906 5.1 Surround Sound | Windows 7 Ultimate

Laptop: Apple MacBook Pro 13" Retina

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 26 Aug 2006,  21:15:42  Show Profile
I don't think so... considering that unlike memtest86 which has exclusive use of a processor, Sandra has to compete with other processes. This is it's greatest downfall. I think the extra 2 MB/s for ECC Scrub should be put down to 'statistical errors'.

With only a 0.1% difference, we can safely assume that the two readings are identical.


HAL-9000
Dave, my mind is going

United Kingdom
11223 Posts

Posted - 29 Sep 2006,  15:12:36  Show Profile Visit HAL-9000's Homepage
hi io,

in the test up there the L1/2 cache isn't anything to do with the ram's performance from it's ecc setting, so the differnce of the main memory is the point of interest,

the difference > 421MB/s, 77.67% faster, (542MB/s, 963MB/s),

also the socketA system architecture was very limiting to ram, even though it could run "dual channel" the effect of pluging in another stick was sometimes nothing on performance, where plugging in another stick in to a socket939 would give almost exactly twice the bandwidth, the northbridge/FSB was the bottleneck, so to say the difference was from the socketA's dual channel setup might be flawed in answering the noted differnce..

and could it be that your ECC rig was just pretending to not be ECC but was still limited in the same way even if the setting was turned on or off through it's architecture,...






I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the darkness at Tan Hauser Gate.
All those moments will be lost in time, like tears in rain,
time, to die.


Edited by - HAL-9000 on 29 Sep 2006 15:33:27

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 30 Sep 2006,  16:33:53  Show Profile
quote:
Originally posted by legoman
[...] so to say the difference was from the socketA's dual channel setup might be flawed in answering the noted differnce..


Hello legoman. Agreed, I should have run the ASUS board with only one 512 MB stick to prove this. Unfortunately I don't have a similar rig at the moment. When one comes my way again, I'll have to remember to test it.

quote:

and could it be that your ECC rig was just pretending to not be ECC but was still limited in the same way even if the setting was turned on or off through it's architecture,...



Every time the machine is booted with ECC ON, I have to wait about 2 minutes with a blank screen while the RAM is cleared and checked, before the 'normal' POST starts. That probably amounts to a few days sat staring at that blank screen.... Also, utilities like memtest86 & Sandra, recognise the ECC capability and whether it is enabled or not.

It had crossed my mind that the inherent architecture might be masking the ECC/non-ECC readings. Plus, this is my SMP box, which as you probably know, has the Alpha EV6 bus architecture which is obviously *way* different to that with a single physical CPU.

I recall recently reading about some ECC changes in the Linux kernel, I've yet to investigate this, but I'll report back if I find out anything useful in this context.


HAL-9000
Dave, my mind is going

United Kingdom
11223 Posts

Posted - 30 Sep 2006,  19:16:17  Show Profile Visit HAL-9000's Homepage
hi'ya

glad you didn't take that the wrong way,..,

would be interested to hear if the the changes in linux change performance...




I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the darkness at Tan Hauser Gate.
All those moments will be lost in time, like tears in rain,
time, to die.

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 21 Oct 2006,  17:56:52  Show Profile
I updated my kernel to 2.6.18.1 today, and enabled the Experimental option EDAC (Error Detection And Reporting) (CONFIG_EDAC):

quote:
EDAC is designed to report errors in the core system. These are low-level errors that are reported in the CPU or supporting chipset: memory errors, cache errors, PCI errors, thermal throttling, etc..


Well, no errors reported yet, although reading up on this, memory can be susceptable to bit-flips due to solar winds, cosmic rays and other not-of-this-world influences. So I expect to see something being reported in the logs the next time a solar prominance erupts from the sun's surface.

Anyway, while reading up on the support that Linux has for my Chipset, AMD-762/768, I came across this in AMDs spec for the AMD-762 chipset:

quote:
The additional logic to support the ECC function is costly in
both silicon real estate and system timing. In the ECC modes
that support data correction, one additional system clock must
be used to generate the corrected data. However, because the
AMD Athlon processor checks for its own errors, data is passed
directly through the AMD-762 system controller without an
additional system clock delay.


So this explains the reason why I was getting identical readings with and without ECC enabled. Basically, the ECC is being performed transparently by the Athlon.

The chipset only corrects Single Bit Errors when the data has not come from main memory but from the PCI bus, the Alternate PCI on AGP interface, or the AGP bus itself.

As memtest only checks memory and not busses (well, only the memory bus), that's why there is no delay with ECC on.



jazz
Jazzy PC Builder

United Kingdom
2599 Posts

Posted - 07 Dec 2006,  10:42:59  Show Profile Visit jazz's Homepage
can a stick of NON ECC run alongside a stick of ECC?

Acer Aspire Z3-710
Windows 8.1

Plummer
Robotic PC Builder

United Kingdom
4657 Posts

Posted - 07 Dec 2006,  17:57:20  Show Profile
quote:
Originally posted by jazz
can a stick of NON ECC run alongside a stick of ECC?

Nope.

PC: CPU: Intel Core 2 Duo E8400| Motherboard: Asus P5K| GPU: PALIT 8800GT 512Mb| RAM: GeIL 2x1Gb PC2-6400
HDD: 250Gb Samsung SATAII| Optical Drives: Lite-On DVD RAM Drive, Emprex CD-RW Drive| FDD: Generic FDD| PSU: Corsair HX 620W
Operating System: Windows XP Home

Peripherals: Monitor: Belinea 1925S1W 19" Widescreen| Printer: Dell Photo Printer 720| Keyboard and Mouse: Hiper Keyboard and Microsoft Habu with QPAD Mat| Joystick: Saitek Cyborg Evo

Water Cooling: CPU Block: Swiftech Apogee| GPU Block: Swiftech MCW60-B| Pump: Alphacool Laing DDC-Ultra
Radiator: ThermoChill PA120.2| Fans: 2 x Nexus D12SL-12| Reservoir: 6" ThermoChill ThermoTube| Additive: Zerex

jazz
Jazzy PC Builder

United Kingdom
2599 Posts

Posted - 07 Dec 2006,  18:49:13  Show Profile Visit jazz's Homepage
Thanks Plummer.

Acer Aspire Z3-710
Windows 8.1

HAL-9000
Dave, my mind is going

United Kingdom
11223 Posts

Posted - 23 Dec 2006,  16:00:21  Show Profile Visit HAL-9000's Homepage
quote:
Originally posted by io
In the ECC modes
that support data correction, one additional system clock must
be used to generate the corrected data. However, because the
AMD Athlon processor checks for its own errors, data is passed
directly through the AMD-762 system controller without an
additional system clock delay.



interesting...

.


I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the darkness at Tan Hauser Gate.
All those moments will be lost in time, like tears in rain,
time, to die.

JJBattoe
Senior PC Builder

USA
1387 Posts

Posted - 08 Apr 2008,  22:26:20  Show Profile Send JJBattoe an AOL message Click to see JJBattoe's MSN Messenger address
Just wondering why this is stickied if we still can't tell if it actually does make a difference whether using ECC RAM seeing as it never truly turns off.

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 08 Apr 2008,  23:41:56  Show Profile
If you read the first post you'll see that it does make a difference:

a) It can be turned off
b) It has the potential to signal that one or more bits are in error, and the really clever bit, to recover from certain detected errors.

The posting thread's prime theme was about ECC performance (as the title suggests), and as I later discovered (see further down the thread), the AMD Athlon XP (or at least the controller it is attached to) transparently generates ECC data and so does not cause any performance delays compared to not having ECC.


JJBattoe
Senior PC Builder

USA
1387 Posts

Posted - 08 Apr 2008,  23:53:52  Show Profile Send JJBattoe an AOL message Click to see JJBattoe's MSN Messenger address
I read it all, just what I was taking from the original post was that you were comparing the performance of ECC to non-ECC RAM, not whether having the ECC on RAM on or off would be beneficial to performance. Guess I misunderstood.

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 09 Apr 2008,  17:52:47  Show Profile
Maybe I misunderstood you, but reading your previous comment I see you got the gist of it.


bfbf
Advanced PC Builder

United Kingdom
8058 Posts

Posted - 26 May 2009,  02:00:37  Show Profile
Wikipida suggests that the performance hit is between 0.5 and 2%

However also when I was reading it suggested that there is only 1 error per 1GB per month. So if you get an error what will that course - not much?

Ovs with 8GBs io you are having one error every few days :P

http://en.wikipedia.org/wiki/Dynamic_random_access_memory#Errors_and_error_correction


Apple Macbook and Self built ____ Click here for Example specs 08

Edited by - bfbf on 26 May 2009 02:01:44

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 26 May 2009,  22:45:01  Show Profile
On the contrary bfbf, all of those people out there who have PC's without ECC are the ones having errors every few months! My FB-DIMMS are correcting those single errors silently so I get fewer BSODs and 'funny' errors.

That figure of how much slower the memory is due to ECC is questionable - as you say the Wiki [thanks for the link BTW] states 0.5 to 2% with a reference to the PCGuide, but that states 2 to 3 % without any hard proof.

In any case, as I stated in an earlier post here, the Athlon MP processor is capable of calculating and checking for errors itself so there is no delay (though there probably will be to correct an error).

I'll have to test the Intel 5400 chipset to see what delays (if any) it introduces with FB-DIMMS.


bfbf
Advanced PC Builder

United Kingdom
8058 Posts

Posted - 30 May 2009,  22:27:22  Show Profile
Don't think I have ever had a BSOD or a "funny error" on my current build or my macbook - just don't think memory needs checking anymore unless it is ultra critical....


Apple Macbook and Self built ____ Click here for Example specs 08

io
Advanced PC Builder

United Kingdom
3218 Posts

Posted - 01 Jun 2009,  20:36:26  Show Profile
Well you are contradicting what you linked to - if an error occurs once a month, that one errored bit could be as harmless as changing the letter 'A' to the letter 'a' in a document you were editing.

At worst that one altered bit could corrupt a code portion of memory and cause the CPU to write trash to the hard disk.

You say you don't think you've had anything 'funny' happen, but that's maybe because you haven't noticed it. It doesn't mean to say it's never happened.

Remember that for years the PC could only operate with Parity RAM - a simpler form of error checking comapred to ECC. To keep costs down, Parity checking was dropped (eight chips instead of nine required at manufacture per bank) and non-parity became standard. Next to hard disks, Memory has to be the most failure-prone thing in a PC so to me it's important to ensure the integrity of the PC.


 New Topic    Topic Locked
Jump to 
Snitz Forums 2000