Using PC2700 for an A64 system (temporarily)? Do I have the right idea?

:: MEMORY SETTINGS ::​

SETTINGS AS IN THE BIOS: [SETTINGS I USE]
{Explanation of my choice}

MEMCLK MODE:[LIMIT]
This enables us to change the other settings manually i.e more control over other parameters.You can reach ~ 2.45 stable with an AUTO setting. Nothing wrong with it, but not recommended if you want killer Sandra Bandwidth scores .

MEMCLK:CPU [5:3 DDR333]
I find this more stable than the AUTO. As before AUTO works quite O.K. But since the Mem is not forced to operate at 5:3 you may encounter instability in the intermediate multiplier area.Lets see what this means. Remember that the RAM frequency is derived off the CPU frequency (2565MHz in my case). Here I'm setting DDR333 i.e forcing the RAM to operate at a lower frequency. This is where the CPU RAM divider comes in and tries to match our target frequency. The CPU RAM divider has specific programmed values based on the CPU Multiplier. If you have high performance memory (PC3700) or low latency RAM, then I'm sure you can run at 2:1 i.e synchronously with the CPU.

Lets look at this table:

Let us look at my settings and do a sample calculation.
Target DDR333 i.e 166MHz. My CPU Freq= 270MHz (HTT) x 9.5 (Multiplier)=2565MHz. So the corresponding Divider from the chart is 12.0. So my RAM actually runs at 2565/12= 213.75MHz.
Since this RAM is rated to run at 200MHz (DDR400) I'm actually OC'ing my RAM to run at 213.75 MHz. Suppose I pick a setting of DDR400. The corresponding divider is 9.5 and the actual clock speed of my RAM becomes 2565/9.5 = 270MHz (not surprising since this setting ensures RAM in in sync with the HTT)! Surely my RAM can't handle that and so a crash is inevitable.Gautam helpfully pointed out that the half multiplier settings are useless as the A64 does not support half dividers. I could have used 257 x 10 instead of 270 x 9.5 as the divider is the same number 12. This issue is yet unresolved as my rig is stable at 9.5 and fails P95 in 3 min at 12.
Issue miraculously resolved itself! Stable at 257 x 10. Is this an anomaly or is everybody facing the same "problem"?


DRAM [DISABLED]
I'm not sure about this. Will update.

BANK INTERLEAVING [ENABLED]
I think this is necessary if you are running in Dual channel mode, i.e identical sticks in A1 and B1 slots.

NODE INTERLEAVING: [DISABLED]
Not sure about this. I read somewhere that this is useful in a cluster. Single machine users need not bother.

BURST LENGTH: [8 CLK]
Supposed to offer wider bandwidth than the 16 clk setting. I didn't see a big difference in Sandra scores. (Will update with a fresh test and detailed scores).

CAS [2.5 CLK]
The default Column Access Time latency on my stick. You can expect a crash if you go below the rated CAS. My box crashed when I tried 2.0. Stick with the rated CAS.

TRC [9 CLK]
Row Cycle Time. (TRC= Minimum of TRAS+TRP).

TRAS [7 CLK]
Row Active Time. TRAS= TRCD + CAS + 2 CLK. In my case it is 3+ 2.5 + 2 = 6.5 So choose 7. {Testing at 6 Clk..will update}

TRFC [AUTO]
Leave it on auto. I could not boot at 15 Clk!! Strangely, only the AUTO setting works.

TRCD [3 CLK]
RAS to CAS delay.Default is 3 for my chip(s). Prime95 unstable when lowered to 2.0. Use defaults.

TRP [3 CLK]
Row Active Strobe Precharge. Defaults. P95 unstable if lowered.

TWCL [AUTO]
Makes no difference in Sandra scores.

ASYNC LAT [AUTO]
(Still testing)

2T [DISABLED]:
Better memory bandwidth.
From ACE's hardware:

Considering that the FX-53 Socket 940 was able to pull 5.4 GB/s with two DDR400 CAS 2.5 registered modules, something was holding the Socket 939 FX-53 back. I started to scrutinize all the memory BIOS settings, and noticed that the bus turnaround was set to 2 by default. Now that is quite weird, as this is only necessary if you load each channel with two DIMMs.An incredible difference: with a faster bus turnaround, the memory subsystem is able to serve up to 24% more bandwidth, and the latency goes down from 51 (21.25 ns) to 47 cycles (19.6 ns). This results in measurable real world performance gains:
* In 3DS Max 5.1, we gained 3% of performance
* In Medieval War, Comanche we also gained 3%
* In Wolfenstein: Enemy Territory, we gained 5.5%
* In WinRAR and Plasma, the performance advantage was no less than 9%!

Bus turnaround happens because the memory bus is a half duplex bus: it can either write or read. The turnaround is the time required to switch between a read and write cycle (or vice versa), and it is indeed a critical performance factor. With DDR, this is a very important performance parameter (contrary to RDRAM) as the "write" or "read" commands are sent and decoded simultaneously with the addresses. Because of this, you could say that the controller doesn't "know" in advance what's going to happen next. If a write is decoded just before a read has been ordered, the write command will have to be delayed to avoid collisions on the data bus. The data bus can only send signals in one direction. Reading data from and writing data to the DRAM will cause the two signals to collide and corrupt the signals.Turning around the bus takes a number of nanoseconds. During this time, no data traffic is possible as the DRAM does not receive any commands. The higher the clockspeed of the controller, the longer the turnaround will take in terms of clock cycles. In other words, the higher the clock speed, the more critical bus turnaround delays are.

As the Athlon 64 already accesses memory with very low latency, a few cycles saved on bus turnaround can really make a difference. At the same time, it must be said that if you use more than one DIMM per channel (so 4 DIMMs in total, or two DIMMs in the first channel), AMD suggests that you use DDR333 with bus turnaround set to 2. However, we have to confirm that we had no trouble at all running with two DIMMs per channel at DDR400 and "2T" enabled.

To sum it up: if you only limit yourself to one DIMM per channel, you will be able to set this BIOS setting to "1T". If you want to use 4 DIMMs or have bought only one DIMM, you will lose about 2 to 9% performance.

Click to expand...

Tested by me and proven true, low Sandra scores if 2T is invoked.

READ PREAMBLE [AUTO]
Looks like setting this to higher values is better if your rig is unstable. (Still testing)

HYPERTRANSPORT FREQUENCY [1000 MHz]
Scroll up for the Important note #12.
Logically my system is supposed to be unstable because Max Hypertransport frequency is 1000 MHz where as the corresponding LTD x HTT is 5 x 270 = 1350 MHz! My system is stable (primed for >14 hrs). Makes me think its either a dummy or has a high threshold before failing or I'm a lucky dog with a cool MoBo .
{Added Oct. 21, 2004} I tried lowering my Hypertransport frequency from 1000MHz to 800MHz to test the above premise. Guess what? I got crazy boot-up errors which did have what I assume CPU register dumps and exception error codes. I don't know if it was the BIOS or Windows. This means I'm unstable at lower HT Frequencies!! I had PCI:AGP lock to the 74.xx MHz but I don't think that was the problem because I got the same errors when I used 66.66 MHz. Another possibility could be the 1008.002 beta bios I'm using messing up.
Issue resolved. It was the beta BIOS.​