How to set up GTL Ref Values for 45nm & 65nm

[CryptiK]

Heh that's exactly what I do, I have about half of a 300 page notebook filled with numbers and testing parameters and notes about changes I made. My girlfriend found it one day and the look on her face was priceless.

I also have my rock solid 24/7 settings saved to profile 1, and 2 is for current testing setups. I wish there were more profile spaces actually, 5 would be nice.

[ci2kla]

Seems time to move on to other strap...
200Mhz Strap is too stressful for NB that need at least 1.59v for 471FSB.
Anyone experianced cases that IBT Pass but ORTHOS Failure? After yesterday further testing still gave nothing valuable to me...with 1.2v VTT, 471x8 @1.2v vCore, The system was hard locked after ORTHOS run for 4 hrs 30 mins...more likely VTT is the problem.

EDIT: Oh, by the way, Tried both -70 -30 -70 -30 and +80 +40 +80 + 40 GTL combinations. Positive one got reboot after minutes of ORTHOS run. While negative combinations, ORTHOS Large FFTs failed in 2 minutes, will try different strap and find out if I really need to up vCore.

[mikeyakame]

Seems time to move on to other strap...
200Mhz Strap is too stressful for NB that need at least 1.59v for 471FSB.
Anyone experianced cases that IBT Pass but ORTHOS Failure? After yesterday further testing still gave nothing valuable to me...with 1.2v VTT, 471x8 @1.2v vCore, The system was hard locked after ORTHOS run for 4 hrs 30 mins...more likely VTT is the problem.

EDIT: Oh, by the way, Tried both -70 -30 -70 -30 and +80 +40 +80 + 40 GTL combinations. Positive one got reboot after minutes of ORTHOS run. While negative combinations, ORTHOS Large FFTs failed in 2 minutes, will try different strap and find out if I really need to up vCore.

use 333 or 400 strap and see how they go. 200/266 strap are way too low for high fsb.

[ci2kla]

use 333 or 400 strap and see how they go. 200/266 strap are way too low for high fsb.

But they allows tighter tRD that's why I love 200Mhz Strap

[mikeyakame]

Tighter tRD is only relevant to a given strap. PL7 on 333mhz strap with 12:10 div is equivalent to PL5/PL4 on 200mhz strap with 2:1 divider which is equiv to 5:4 on 400mhz strap PL6.

Edit:

Some linpack results from new build.

Link for new binaries Linpack MKL 10.1 build SP v10.1.1.022 compiled 23/12/2008.

http://www.fileqube.com/file/voPwnk167379

If it complains about missing dll, go into either ia32/bin or em64t/bin and copy the DLL I included to either System32 or Linpack dir. I have Maths Kernel Library installed so it works fine for me but if you don't it might refuse to start without the dynamically linked intel library its compiled against.

See release notes included inside for changelog. I7 performance should be improved respectably from previous build.

[lochabar]

Having a particular issue with GTL Ref volt settings. I have a P5K premium, and am noticing that when I screw up an OC with a GTL Ref volt adjustment, it's a CMOS reset for sure. Nothing else makes that a given. Anyone else have this happen? Or know why it might be?

[mikeyakame]

Well believe it or not if GTL reference voltage is set to a value where the logical swings don't meet minimum criteria, some bad things can and probably do happen within moments of running them. Forcing CMOS reset is probably a safeguard put in place to minimize mass corruption to bios or cmos.

[lochabar]

That makes perfect sense. thanks.

[KanGaXx]

someone can help me ?

i have an e8600 and a rampage extreme that have gtl rappresentation on mV.

i tryed your method but i cannot understand...

i use 1,25vtt and seems good but how can i get 0,63X on cpu ??

i must always vtt*0,667+Y=vtt*0,63X ? because 0,667X is default ??

gtl 0 ,1,2,3 have the same value ?

[CryptiK]

If you want as close to 0.630x as you can get on each GTL Ref channel using 1.25 Vtt, set:

GTL Ref 0 = -5mv
GTL Ref 1 = -45mv
GTL Ref 2 = -5mv
GTL Ref 3 = -45mv

[KanGaXx]

if i increase VTT

gtl value (ex. -5mV) remain the same ?

why 0/2 are different 1/3 ?

[CryptiK]

It remains the same up to ~1.38 Vtt, then you need to set -50mv for 1/3 if you set -5mv for 0/2, as the difference between them becomes 45mv rather than 40mv.

0/2 have the default multiplier of 0.635x
1/3 have the default multiplier of 0.667x

[mikeyakame]

Cryptik,

Tonight I had to read more Intel datasheets on something unrelated and I debunked my own theories on Asus' differing GTLs. I actually have an explanation now that isn't based on hunches! It seems if I had read thoroughly over all the FSB pin definitions I would have caught it straight away!

Address strobes are common clock source synchronous. Data strobes are differential clock source synchronous.

So why do Asus use 0.635 for data and 0.667 for address.

Address being common clock source synchronous means that the strobe is setup across multiple clock domains during the same clock edge, and synchronized to source of strobe.

Data being differential clock source synchronous means the strobe is set up at the target destination on the next falling edge of either differential clock, so the actual clock domain of source and target never actually come into contact with each other, and just synchronizes the data strobe based on when the source set it up, and accessed at the target on the following falling edge on the host bus not the source.

Now I see why Data is lower than address.

Ringback on low and high swing has potential to wreak havoc when it leaks into two clock domains have an open strobe on the same clock, and would otherwise never cross talk even if their frequency oscillates similarly to another on a different domain. Cross talking from ringback can only occur when a common clock is used for a strobe, it's otherwise harmless on differential clocks. Jitter on a common clock is as harmless as ringback on a differential clock. Asus understand that this is true in practice by their decisions on what reference voltage point to use for the associated strobe on the data or address bus. Jitter across differential clocks is bad because it causes skewing and deviation when calculating the following falling clock edge on the inverse clock because if the following clock period actually takes place earlier or later than max stability window determines is acceptable, there is no way to be sure that the target will begin to read the strobe before it begins and contaminate the strobe with something completely different, or after and miss the first bursts of data with result of incomplete data at endpoint. Checking data is complete and valid is optional and upto endpoint device to ensure that what it received is the same as what was sent.

So on a data strobe you want to minimize jitter at the expense of harmless ringback so you set the GTL for data bus strobes at the same value as Host FSB GTL reference to more precisely time when to setup the strobe and how long to hold it to make sure the target can successfully read successive strobes for the completion of the data transaction. The clock domains will never exist on the same clock so any ringback within the valid period window won't do anything other than look cool on an oscilloscope. There is your 0.63x.

On an address strobe different clock domains being exposed to each other on a common clock means you want to eliminate ringback because all the shielding and pulling down on the input voltage you do won't make the slightest difference if both clock domains have clock frequencies that have oscillation and resonance characteristics alike each other, and if they cross talk between device bus' there is no way to know this, as cross talk from source bus to destination bus appears as what should be part of an address strobe transaction even if its actually random data bits from a data strobe on the same falling clock edge for a completely different transaction. Address strobe data is highly critical and random if even minute pollution can completly alter the necessary data for the MCH to determine where a following data strobe needs to be requested to, or even something like changing a bit in the destination address data when decoded ends up initiating a data strobe to a completely unrelated device bus, and completely corrupting a data strobe it is accessing from a different source. Data all looks the same so you rely on the MCH to decode and route it properly and assume responsibility of validity to target, Address is all completely different, and decoding is based on set of hexadecimal identifiers supplied so that you don't need to know where it actually lives or how to get to it, just that it is there and you want to communicate with it. Asus uses 0.67 to eliminate ringback cross talk between clock domains at the expense of more jitter because jitter causes skewing, and skewing is only a problem when timing strobes across differential clocks especially when the low clocks data is inverse to its value, and high clock isn't. A != A on low clock, F != 0 on high clock, mess the timing up and AD0F from low clock is read as AD0F on high instead of 52F0 which is what the source device burst on to the Host FSB bus.


Summary.

0.63 for Data uses ringback resistance from differential clock bus access for source and target to eliminate clock jitter when timing strobe access between source and target. Set to same reference point as Host Bus GTL aka NB_GTLREF because all clocks are reference from host BCLK and what better reference to use than the same point being used to drive the clocks you are timing against clocks driven based on the same source at the destination accessing the strobe on the following clock edge. Chances of clocks skewing and deviating too far are decreased dramatically, that's the critical factor here.

0.67 for Address uses jitters ineffectiveness to raise the reference point as compensation to minimize or eliminate ringback into the valid clock period which has to potential to pollute and disrupt system stability or activity. Higher the sample point for all calculated clock period decreases the risk of address strobe contents being altered from concurrent data strobe on same falling clock edge as address strobe is setup across the bus, and what source sends and target receives isn't checked to minimize cost of transaction and assumed that what target receives is what the source originally sent.

Even with making sense of this, I feel so much more confused about other things. Datasheets are evil, they lure you in with the dream of answers, but in reality just pose more questions that they can't give you answers for!

The above also stipulates my understanding and practical results i've found from using both NB & CPU clock skews together with GTL reference points as it appears they are designed to go hand in hand and to be setup to compliment each others strengths and weaknesses, most importantly when Host BCLK frequency becomes fairly high (though quite a bit lower on quad cores than dual cores) and minimum criteria for operation can no longer be met for 100% of clocks on FSB and corresponding clocks driven on CPU and MCH from the Host FSB BCLK.

GTL reference points are extremely important for calculating highly critical values that correspond to handling data and timing strobes between clocks, and because of this they have a weak ability that can compensate small skew deviations between differential clock provided that the deviation at worst never exceeds the maximum stability criteria determined by the voltage crossing point between low and high swings. Using them solely to do this from what I now realize seems to result in perfectly stable system behaviour at high FSB, until CPU and MCH clock timing becomes critical during heavy bus transactions such as the type Linpack puts in motion and the system will hard lock instantly, sometimes after a minute other times 5-10 but the result is the same. The deviation between the previous voltage crossing point and the following one was greater than 150ps and the previous falling edge data strobe polluted the adjacent rising edge address strobe on the inverse clock. No amount of GTL or Vtt adjustment alone can correct it at this point, as if deviation averages 120-130ps, then all it takes is a bit too much jitter on the valid clock period for a data strobe and the deviation has potential to jump beyond that 150ps maximum tolerance.

NB and CPU clock skews can't fix problems which as a result of poorly setup GTL reference points so changing these to fix this kind of problem is like changing the tyres on a car that won't run because it has a flat battery. Car might have spanking new tyres but this means squat if your battery is still flat since you can't drive it anyway. NB & CPU clock skews what they are designed to do is make static corrections to when the output clock needs to be driven for the MCH and for the CPU with respect to the voltage crossing point which the GTL reference for Host FSB clock (NB GTLREF) is used to determine. If this is set correctly, then correcting skewing that is occuring from all the extra NB voltage we are pumping in to get high FSB stable in the first place (and is actually slowly becoming an obstacle that will halt further potential and heat just amplifies it which is why water cooled NBs give more consistent FSB clocks when put under similar conditions as constant lower temperature acts to reduce onset of symptoms and problems). Setting up the timing for driving CPU & MCH output clocks correctly from Host BCLK reference will correct dynamic compensation GTLs were being utilized incorrectly to handle if you either intentionally or accidentally managed to set them up to do that of course. If the problem lies with the design of the board itself and its VR limitations or additional compensation in circuit components that is designed to only handle so much before even they can't help, then no amount of amount of skew or GTL adjustment will change the results from this point even if the memory and CPU can do it.

Most 8 phase X48 boards will only do near 500Mhz FSB and this is VR and capacitance compensation limitations of their designs. P45 boards even with 16 phases unless the ones in question are priced at the same point as X48 counterparts are crippled by use of cheaper components to save costs of production, and it becomes like winning the lottery some win first try, others never win at all. If you are lucky to get a P45 board that does somehow pull over 500Mhz FSB on a quad core then you are one in very few who actually have achieved it.

Only two boards designed for this task are Asus Rampage Extreme and Foxconn Blackops and both when not crippled by either CPU or DRAM falling flat on their face first can and will achieve some very high extremely stable FSB frequencies as a result of either never exceeding their design or not finding a CPU that is perfect enough to exceed its abilities.

If by correctly setting up both clock skews and GTLs you are still stuck and can't get farther there is a damn good chance that CPU is losing coherency or DRAM timings can not be tight enough as required because of inconsistent IC limitations or ability. Sometimes it can be this, more times than not it is what happens when you become consumed on making one set of values work that just cant work, and if this happens best thing to do is step back for a bit start from the beginning at a different point and make your way back up there with new values. It's being able to cut your losses and start fresh that will be difference some of the time between making a setup work or not at a certain FSB frequency. Not all FSB frequencies are worth using anyway, sometimes 1 or 2Mhz either way is all it takes to get the system running smooth.

[Evil_AnAnAs]

If I have a 90nm cpu, should I use like 0.7?

[moiraesfate]

My god, I went crosseyed reading that. Math is not my strong suit.

What exactly does this do setup do for you and why is it important? My eyes just started skimming over it and didn't absorb what I read.

[Cibic]

Guys, I've been reading but I don't fully understand it. I have never done maths in english.

MB: Asus Striker II Extreme v1104 Bios
CPU: Q6600 at 3.6GHz, 1.46v
VTT: 1.44v (actual 1.46)
NB: 1.55v
PLL: 1.6v
According to Seban's excel file and
from what I gathered:


Doing the maths I get 46mv that means I should set the values and then work my way down or up?
and each time I get a failure but I must keep 1 and 3 40mv below 0 and 2.

eg.
GTL ref 0: +50mv
GTL ref 1: +10mv
GTL ref 2: +50mv
GTL ref 3: +10mv
NB: +50mv

Which way is it correct?
What range should I be and if none of the ranges work, that means I need more volts somewhere?

[mikeyakame]

My god, I went crosseyed reading that. Math is not my strong suit.

What exactly does this do setup do for you and why is it important? My eyes just started skimming over it and didn't absorb what I read.

I don't want to sound rude, but if reading that is too much for you then I don't see why I should bother explaining it again because it'll be as long. Read from Summary down. Thats what you need to know. The top is just an explanation in detail, explaining interactions.

[Alien Grey]

For those who want to know more about GTL Reference Voltage: Understanding GTL Reference Voltage

[dlsolo]

That wasn't a bad read. I've only seen the article for the DFI P35 boards over at http://www.thetechrepository.com/showthread.php?t=228

[Bobly]

Okay there's one thing I'm slightly confused about: This thread explains how to set the GTL Ref voltages, however when looking at examples of what people have set, their are always 2 of the 4 which are higher (~50) and 2 of the 4 that are lower (~10):
Example:
GTL ref 0: +50mv
GTL ref 1: +10mv
GTL ref 2: +50mv
GTL ref 3: +10mv

Is that because 0 is the maximum and 1 the minimum? Should that not be mentioned in the first post?



2/ More importantly, what is the preferred method to find a stable overclock while fiddling with GTL Ref voltages?
When you overclock a CPU it's fairly trouble free, increase FSB, check stability, if stable increase again, if not raise Vcore or Vnb (one at a time) until stable, then resume.
But with GTL Ref voltages I'm in a slightly more troublesome situation...
Should I first start manually setting the VTT and see if I can overclock any higher? Or is manual VTT without manual GTL Ref useless and I need to do both at the same time?
If unstable, should I increase or decrease the GTL Ref voltages to get stable again? Are there any margins one should not go over? (ex: +~100mV?)

Sorry for the noobish questions but this has got to be one of the most confusing aspects of overclocking ^^

[nullface]

Jesus Christ i HATE f-ing GTL!

Is it even necessary to look to much in to GTL values at sub 500FSB?

[dlsolo]

I'm thinking on a quad core system.... YES! I can't break the 445FSB on my x3360

[Zucker2k]

Tighter tRD is only relevant to a given strap. PL7 on 333mhz strap with 12:10 div is equivalent to PL5/PL4 on 200mhz strap with 2:1 divider which is equiv to 5:4 on 400mhz strap PL6.

Mike, is that true for same fsb and ram frequency? Or I'm I missing something? I think he's making a performance argument.

[Amurtigress]

mikeyakame/Cryptik:

Thanks for the long post on the last page. I haven't posted here for quite some time...

It appears that my mainboard hasn't read your posting yet, since my system would only get stable setting all references to 0.69 +-0.2.
Any larger difference in any of those references leads to calculation errors in IBT. If my memories don't fail me, keeping the difference 0.04 between adress and data did not even work on default clocks.

Here a quick summary of my current settings:
CPU: Q9550 E0
FSB clock: 460 MHz (465 and more will cause hangs and BSODs)
FSB term V.: 1.36V
NB Volt: 1.40V
CPU PLL Volt: 1.56V
CPU clock: 3910 MHz
CPU GTL 0/2: 0.69x
CPU GTL 1/3: 0.69x
NB GTL: 0.69x

CPU and NB skew do nothing for me, they only cause instabilities (BSODs, system hang) if not set to AUTO. More than 200 ps even keeps the system from posting.

Does that make any sense in relation to your last post on why ASUS is keeping that 0.04 difference?

[hollaback04]

omg this is very helpful thanks for the information i hope i will setup the right values