Build your own PC with the UK's most popular how-to guide
Now viewing our PC building forums
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


 

ECC RAM Performance

 New Topic  Topic Locked
 Printer Friendly 
Next Page
AuthorPrevious Topic Topic Next Topic
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.


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.

Go to Top of Page

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.


Go to Top of Page

Simpsoni28
Advanced PC Builder

United Kingdom
2812 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
Go to Top of Page

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.


Go to Top of Page

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
Go to Top of Page

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.


Go to Top of Page

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.

Go to Top of Page

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.



Go to Top of Page

jazz
Jazzy PC Builder

United Kingdom
2566 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?

ASUS X75V
Windows 8.1
Go to Top of Page

Plummer
Robotic PC Builder

United Kingdom
4655 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
Go to Top of Page

jazz
Jazzy PC Builder

United Kingdom
2566 Posts

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

ASUS X75V
Windows 8.1
Go to Top of Page

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.

Go to Top of Page

JJBattoe
Senior PC Builder

USA
1385 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.

Go to Top of Page

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.


Go to Top of Page

JJBattoe
Senior PC Builder

USA
1385 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.

Go to Top of Page
Page: of 2Previous Topic Topic Next Topic 
Next Page
 New Topic  Topic Locked
 Printer Friendly 
Jump To:

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
© 2013 buildyourown.org.uk. All rights reserved.
Go To Top Of Page
Snitz Forums 2000