I also tried Call of duty 2 with 1.3 patch, but single core is able to handle it with 85+ fps most of the time. During heavy firefight in later missions it can drop to about 50-60 fps which is still manageable. Graphics details on maximum. This is probably where you would benefit from dual core.

In Company of Heroes I have found it impossible to defend territory with just infantry and vehicles even on easy difficulty as AI attacks multiple sectors simultaneously. Any tank left unattended will get destroyed by AI AT gun. It's probably better to build machine gun nests and AT guns. Still, AI is very good at finding weak spots. The problem is mainly in 2 player maps as the front is wide. This is an issue in skirmish games. In campaign it is manageable as AI is easier. It will not swarm you with tanks.

I tried what happens if you run with 3x 1GB DDR400 (Kingston HyperX mixed with OCZ Platinum) and we get a reboot after BIOS applies memory settings with Turion 64 MT-40. This happens with Command Rate 2T, +0.2V memory voltage and conservative timings. Using single sided Kingmax 512MB DDR400 for 2.5GB RAM didn't change anything.

The motherboard did boot at lower DDR speed so DDR333 is likely possible with 3GB RAM. DDR333 is only suitable for someone wishing to run Windows Vista/7 due to lower speed.

While there existed unbuffered DDR400 with ECC, these will likely not improve memory stability at 3GB + DDR400. They were suitable mostly for home users. I found that the BIOS of Gigabyte GA-K8NE does contain a couple of settings which seem to be activated only if ECC memory is present. The following Kingston modules are unbuffered ECC: KVR400X72C3A/1G

To run 3GB at DDR400, likely registered memory modules are needed. These are very rare. If anyone has them and got them working in socket 754 then let us know. The following Kingston modules are registered ECC: KVR400S4R3A/1G , KVR400D8R3A/1G

AlexZ wrote on 2026-07-07, 20:23:

I found that the BIOS of Gigabyte GA-K8NE does contain a couple of settings which seem to be activated only if ECC memory is present. The following Kingston modules are unbuffered ECC: KVR400X72C3A/1G

My Gigabyte motherboard also has these options in the BIOS.
I suppose so.

Because I’m definitely using non-buffered ECC modules (9 chips on each side).
But these options don’t appear in the BIOS.
I can only see them using the MODBIN utility for AWARD BIOS.
Well, it won’t make any difference anyway. Buffered modules reduce the electrical load on the bus, whereas ECC ones will simply result in Windows displaying messages saying a memory error has occurred. That’s all.

I managed to get 4x unbuffered ECC KVR400X72C3A/1G for 5€ each, new ones, never used, in original package (seller has 5 more, but I don't need that many). They have manufacture date 2010/2011, not sure who used ECC DDR1 back then! It's probably why they never sold.

When I put them into Gigabyte GA-K8NE, enter BIOS and press ctrl+F1 I see additional ECC related settings in Advanced Chipset Settings.

They don't work with Command Rate 1T or CAS 2 at DDR 400 with 2 sticks as these are not high performance sticks.

After very basic testing, they appear to work at these timings with 2 sticks
- Tcl 2.5, Tras 7T, Trcd 3T, Trp 2T, Trrd 2T, Trc 9T, Trfc 14T, Trwt 2T, Twr 2 bus clock, Twtr 2 bus clock, Async Latency value 7ns

Not sure why "L2 cache background scrubber" and "DCache background scrubber" don't appear without ECC memory as they are cache related and memory independent. It means scrubbing engine will proactively check L1/L2 cache for errors when idle and correct them. "DRAM background scrubber" means the same but for memory and naturally requires ECC memory. The BIOS has a typo and says "Disbaled" instead of "Disabled". If you prefer system stability you should turn these settings on.

Keep "ECC Memory Interlock" on "At Least One", that allows ECC to work in case there are mixed modules and not all support ECC.

For basic ECC stability one should enable:
- DRAM ECC feature control
- ECC MCE enable
- ECC Redirection - to write back corrected data to memory, otherwise it is corrected just in memory controller

For extended ECC stability one should also enable:
- all 3 scrubbers to scan for errors proactively. DRAM scrubber causes significant transfer penalty, memory bandwidth drops to about 60%.

For paranoid ECC stability one should also enable:
- Chip-kill mode enable - protects against entire RAM chip failures

For extended features like scrubbers or Chip-kill I found it to be best to use the sticks in Auto mode. Using aggressive timings led to problems during boot.

After playing with it a bit, I would recommend to enable DRAM ECC feature control, ECC MCE enable, ECC Redirection.

The ECC mode of unbuffered Kingston KVR400X72C3A/1G has no impact on performance. The higher memory latency is caused by Command Rate 2T as we have 2 dual rank modules.

I also tested Kingston KVR400X72C3A/1G on more boards using Turion 64 ML-34:

• Asus K8N-E (nForce 3) - boots, in BIOS there is only one setting - Master ECC Enable. No detailed settings like Gigabyte has.
• MSI K8T Neo V (VIA K8T800) - does not boot, no beeps. This board's BIOS doesn't support any ECC memory.

I looked into BIOS of Gigabyte GA-K8NS (nForce 3) and it has ECC settings in it (just like Gigabyte GA-K8NE). I no longer have the motherboard so I couldn't test it.

It is clear it is mainly a matter of BIOS whether ECC memory works or not.

If you can buy this memory for 5€ like I did then it is not a bad choice at all. It is only outperformed by high-performance sticks like Kingston HyperX, OCZ Platinum, Corsair.

Gigabyte GA-K8NE worked with 3GB RAM at DDR 333.

I managed to get hold of 2x Micron registered ECC DDR 333 1GB ( MT18VDDF12872G-335D3 ) for 4€ each. Chips are labelled as "4PD11 D9BXK", The sold item had Hynix pictures so I thought I would get Hynix but Micron arrived with the same specs.

I tested it on the motherboards I have using Turion 64 ML-34 / MT-40:

• Asus K8N-E (nForce 3) - does not boot, no beeps
• MSI K8T Neo V (VIA K8T800) - does not boot, no beeps
• Gigabyte GA-K8NE (nForce 4) - boots only with 1 registered ECC stick (1st slot). 2nd stick causes one long beep. It also leads to CMOS reset (fallback). It doesn't matter what DDR speed was selected in BIOS, whether ECC was enabled or disabled. One stick boots immediately without any problems, regardless if the board previously had non ECC UDIMM or ECC UDIMM. No special tricks are needed to boot. ECC BIOS options get unlocked and they work. Combining the registered stick with unbuffered ECC stick doesn't help. With 1 stick Memtest86 passes and the system successfully boots into Windows XP.

Given vastly different behavior with Turion 64, registered ECC memory support is clearly a question of BIOS support. Gigabyte GA-K8NE BIOS has an issue in that it only supports one registered stick. Probably a bug that got never fixed as it never intended to support registered memory. This means having 4-6 GB memory (using 2GB sticks) on socket 754 is likely impossible.

It is a pity as I managed to find a cheap source of registered ECC DDR400, 2GB in Europe for 7€.

Since I could use only 1 stick, Command Rate 1T worked. Micron stick had no problems with running at DDR 400 with 2.5-3-2-7. It would not boot with CAS 2. However, due to the register, we get memory latency as if it was Command Rate 2T, see picture - 68ns. Just very slightly worse than 2x Kingston UDIMMs at CR2. To fix the latency problem, we have to OC the stick like crazy. At 240Mhz (DDR 480) we get down to 62ns and respectable 3700MB/s read and write speed. I didn't put in much effort to stabilize it at DDR500 as increasing just base frequency would lead to CPU running at 2480Mhz which I'm not comfortable with.

With 2x non ECC UDIMM CR1 I get down to 57.5ns. The registered DIMM has to be OCed to at least DDR500 to be competitive (very slightly higher latency may be acceptable if bandwidth is much higher).

Running 1x 2GB registered ECC memory stick at DDR 400 provides write memory speed boost at slight cost of latency (can be fixed with a small OC) while running it at DDR 480 provides a big boost in read/write speed and much better latency 62ns. Due to very limited benefits, consider this route only if you manage to get the stick very cheap.

Attaching picture of Micron registered ECC DDR 333 1GB ( MT18VDDF12872G-335D3 )

This one is from ebay, mine looks the same except for the HP sticker and slightly different D9 revision.

It has BGA chips, which is probably why it clocks so high. It uses DDR2 technology in DDR1 format.

11 years ago, some people on vogons tested 8GB DDR 400 on s939 8GB of DDR1 in a socket 939 system . It requires using 2GB DDR400 sticks which only come in registered ECC form.

Unfortunately, 2GB sticks typically cost 20€ each on ebay. Fortunately, there still exist sellers in the EU who sell them for a fraction of that price. The cheapest I found was Qimonda memory with HP sticker (for HP servers). It has two rows of bga chips on each side. Chips are HYB250512400CF-5 . The seller doesn't speak English and doesn't normally sell abroad. They seem to have multiple part numbers, with about 140+ sticks each, in total probably about 300 of these sticks. Imagine having that many 2GB sticks!

I ordered 4 of them for binning purposes. I do not have a s939 system and do not intend to buy it. Otherwise I would have bought more.

My board accepts just 1 stick, same as with Micron 1GB registered ECC DDR333 sticks which was expected. Full 2GB RAM is recognized. More sticks cause a long beep.

I started testing what are the limits of individual sticks:

• stick 1 worked at DDR400 when CPU was at 2.2Ghz. When the CPU is OCed to 2.4Ghz, the stick stops working. Probably an issue of signal quality and IMC being affected by higher CPU clock.
• stick 2 worked at DDR400 when CPU was at 2.4Ghz. It didn't like Command Rate 1T though, only 2T worked.
• stick 3 worked at DDR400, when CPU was at 2.4Ghz and Command Rate 1T. It also worked at DDR440 (220Mhz), but not at DDR480 (240Mhz).
• stick 4 worked at DDR400, when CPU was at 2.4Ghz, Command Rate 1T and DDR480 (240Mhz). Higher frequency was not tested as it would require pushing CPU higher. Lower memory divisor than 10 is not practical.

Only default DDR voltage was used, I'm not interested in overvolting memory or IMC of a mobile CPU.

I may have been more lucky with Micron, clearly the official rating is not relevant and you can also try DDR333 for binning. 1 stick out of 4 did OC well. This means if you would like s939 with 2 sticks for OC, you need to buy 8 of these and if you want 4 sticks, you need to buy 16 of them! There is nothing unexpected or wrong here, ECC sticks were not binned by manufacturers for OCing, they have lot of chips on them so one poor chip will ruin the stick. You will need to do a serious binning here! Do not buy these sticks from sellers who have just 2-4 sticks as these may be the worst parts. It also means you need to buy them really cheap.

Screenshots from Aida64 with memory timings and benchmark results. I achieved slightly lower latency than with Micron due to spending more time with fine-tuning timings. Micron may be capable of the same. We got latency down to 60.2ns. Less than that may be possible but it will be tough to beat unregistered sticks which can have about 57.5ns.

The benchmark was run with ECC mode off, but as testing with unbuffered ECC memory revealed there is no performance impact when DRAM ECC feature control, ECC MCE enable and ECC Redirection are enabled. Scrubbing causes major impact and Chip-Kill probably only makes sense with multiple sticks in a server.

tRAS = tCL + tRCD + tRP (or sometimes tCL + tRCD + 2)
tRC = tRAS + tRP
tRFC = 14 cycles = 58ns (14 cycles * 1000 / 240 or cycles * tCK). In data sheet tRFC is 65ns.
tREF = 0.0000156 (15.6us) * 200000000 (200mhz) = 3120 cycles (how long we can use memory before refresh is triggered). Note that since the memory runs at 240Mhz (BIOS has setting for 200Mhz), refresh every 3120 cycles means we have real refresh period 13us, not 15.6us. In data sheet tREFI is 7.8us.
tCK = 4.16ns at 240Mhz (1/240000000)

You can find the data sheet for HYB250512400CF-5 at https://www.alldatasheet.com/datasheet-pdf/vi … 512400CF-5.html . On page 28 you will find supported timings.

3d mark results at 1600x1200 with maximum quality.

In 3d mark 2000 and 2001 we lose to Turion 64 clocked at 2.4Ghz using 2x unbuffered 1GB sticks at DDR400 (CR1) due to slightly higher latency. In 3d mark 2003 and 2005 we win though.

Look at Re: Battle of the platforms: socket 754! for comparison with Turion 64 at 2.4Ghz, 2x unbuffered DDR 400 sticks, CR1

We win in pcmark 2004 but lose in pcmark 2005. We get lower HDD score in 2005 for some reason, I didn't rerun it.

The results are very close and probably only the memory score is reliable.

Look at Re: Battle of the platforms: socket 754! for comparison with Turion 64 at 2.4Ghz, 2x unbuffered DDR 400 sticks, CR1

In cinebench 2003 the results are about the same except for OpenGL HW-L which is clearly lower than on Turion 64 2.4Ghz with unbuffered sticks. Probably higher latency hurts.

So far the results have been unconvincing.

Far cry benchmark

Look at Re: Battle of the platforms: socket 754! for comparison with Turion 64 at 2.4Ghz, 2x unbuffered DDR400 sticks, CR1

Quake 4 benchmark

FEAR built-in benchmark. All details set to maximum except for soft shadows which nd22 disabled. FSAA 4x, Anisotropic 16x. Enabled HW audio mixing and EAX 2.0 since we have Audigy 2 ZS.

• 1600x1200 - min 46, avg 107, max 282, 100% above 40 fps

Crysis built-in 32bit benchmark. All details set to HIGH except for anti-aliasing quality which was set to 4x. First run is ignored (warmup), the remaining 3 are averaged.

• 1600x1200 - min 8.8, avg 29.9, max 45.9

Serious Sam 2 (2005) benchmark with Turion 64 at 2400Mhz and GTX 275:

The game needs to be patched to 2.070. Benchmarked using Serious Sam 2 Benchmark tool, 1st benchmark.

We get comfortable 100+ fps.

FEAR Perseus Mandate (2007), version 1.0. It falls into Windows Vista era (2007-2009).

Maximum details, FSAA 4x, Anisotropic 16x, SS off. Enabled HW audio mixing and EAX 2.0 since we have Audigy 2 ZS.

Prey (2006) benchmark with Turion 64 at 2400Mhz and GTX 275:

The game needs to be patched to 1.4.0. Benchmarked using Prey Benchmark tool.

We get comfortable 100+ fps.

Splinter Cell Chaos Theory (2005) benchmark with Turion 64 at 2400Mhz and GTX 275:

The game needs to be patched to 1.0.5. Benchmarked using Splinter Cell Chaos Theory Benchmark tool.

We get comfortable 130+ fps. Very easy for s754 to handle.