Originally Posted by
mikeyakame
Few things I've learnt so far from my adventures with this board.
Spread spectrum clocking on either pci-e or cpu at above 400FSB will create crosstalk on the Southbridge at certain PLL voltages, and at worst cause display freeze. Disable these.
If you are using a silly high VTT, more than 0.05V above VCC (CPU) to get stability you are more than likely doing something wrong. Raise VNB one or two steps and adjust CPU/NB_GTL_REF ratios up / down, also adjust CPU_PLL raising / reducing 0.02 in steps and keep track of its real voltage in Hardware monitor section in bios. As you adjust this try adjusting VTT other way by 0.02 steps. As you adjust VTT you will need to compensate GTL_REF voltages for either NB/CPU or both. Play with ratios up / down alternatively and pay attention to system response or failure timeframe. If its failed in shorter time you are going wrong way. As you change VTT or VCC, GTL_REF for both CPU/NB will require more frequent adjustment as you go above 450FSB to eliminate power/ground bounce, crosstalk or electrical noise in range of V(IL) and V(IH) from GTL+ reference voltage. Adjusting VTT changes GTL+ reference voltage by ratio of GTL_REF and gives more voltage high or voltage low input headroom for both CPU and FSB clock signal swing between -/+ for rise/fall. Sometimes you may need to adjust DDR_CONTROLLER_REF by 10-20mV higher, and apply 10mv lower value on CHA/CHB, or just leave on auto for self tracking.
SB_PLL (1.5V) tracks CPU_PLL so leave it on auto, crosstalk is a b**** to diagnose.
Patience is a virtue with this board, but it gives nice as hell results when you get things right. Find base values that at least post, note these all down in a book as your base values for that FSB/DRAM freq. Now make minor changes to each value one or two at a time, write down what you changed and whether it was better / worse and do this progressively as you improve results. If you find certain settings to be performing fairly well, use the OC Profile feature and save the OC profile. This way if you go too far off track with adjustments, you can load the OC profile from the point you were going the right direction.
If you adjust DRAM frequency more than 40-50MHz from point you calculated your manually set CLK_SKEWs, they will probably need minor adjustment. I've found that Channel B on mine will need +250PS at 400FSB, and only +50PS at 500FSB, strangely CHA is happy with a delay of 50PS no matter what clocks, must be due to minimal interference on traces.
With 2GB ram sticks, if they are 8 bank then you need to adjust a few memory timing values to create optimal windows for recovery / delay times. Most notably is tRFC (refresh cycle), needs at least a 150% window of the same tRFC with 4 bank dimms (512mb/some 1gb). I find 45-55 tRFC is good for 4 bank dimms, 8 bank needs at least 65-70 for the same cycle.
ALL_PRE_TO_ACT and ALL_PRE_TO_REF timings are auto set for 4 bank, these need to be loosened by 2t, ie 5t -> 7t. This is so the window is large enough for either all read data to be burst off the data bus to the MCH, or write recovery window to be open long enough to write all data to same / diff ranks or banks of each dimm.
Precharge timings should be at least min value of tRP, tRTP should be tRP + 2 (2 is number of clocks delayed before read burst starts)
AI Clock Twister is a fancy pants name Asus uses for what is basically how aggressive or passive the handshake parameters are for data strobes (setup / hold time) between MCH and all DIMM slots. From what I can tell when I adjust CHA/CHB skew -+50PS, Everest shows a non linear change in Dimm 1 - 4 Fine Clock adjustment which sets delay more aggressive in relation to each of the others with strong / stronger. I have read somewhere an Asus engineer did mention in an interview for a magazine it has somewhat of this purpose. Internal MCH / DRAM controller params to minimize or increase idle times / window sizes / strobe duration / strobe skew adjustment. This is probably why there is much more noticed increase in Memory BW when using with Transaction booster.
Transaction booster seems like a programmed intelligent DRAM scheduling for memory transactions between MCH & DRAM controller. Less time spent in idle clocks means more data is throughput as you can increase the amount of successive data strobes for bursting read / writes in the same amount of time it takes for a Row or Refresh cycle. It could also adjust BL (burst latency) between 4 or 8 depending on whether there are successive Reads or combination of Read or Writes.
BL of 4 decreases the amount of clocks required to wait to begin a read burst, but no writes can occur during the same Data strobe with this value. BL of 8 allows for concurrent read / write burst in same strobe at the expense of waiting more clocks to begin the read/write burst and smaller chance of conflict between burst windows for different banks/ranks. Traffic conflicts on the bus inflict the penalty of upto worst case scenario where window becomes too small to complete the transaction in, so timings need to be loosened to allow for the collisions due to commands being issued too early / late or other sub timings being too tight (insufficient window to allow recovery / burst delay) or too loose (overlap where row cycle / ref cycle hasnt completed and successive ones become delayed to the point where transactions cause a traffic jam on the bus and potential conflicts between WE or RD to ranks of memory either completed previously, other rank on same bank may need to be written to while previous rank still being accessed, etc)
I'll add more to this as I find time to document or understand why something happens I cant explain but know how to fix.
