Yea I know fine tuning takes time and patience that's why I'm still learning :D
But just sometimes quite a bit annoying when I was easily get lost track with the settings and confused :p:
Printable View
So your chip seems to like low Vtt. I'd just try all the combinations of GTL Refs you can leaving the Vtt at 1.2v to start with then. Also you should be adjusting all 4 of the GTL Refs as you have a quad.
Try for example:
GTL Ref 0 -30mv
GTL Ref 1 -70mv
GTL Ref 2 -30mv
GTL Ref 3 -70mv
or
GTL Ref 0 -20mv
GTL Ref 1 -60mv
GTL Ref 2 -20mv
GTL Ref 3 -60mv
or
GTL Ref 0 -10mv
GTL Ref 1 -50mv
GTL Ref 2 -10mv
GTL Ref 3 -50mv
or then try having the address bus slightly higher proportionally:
GTL Ref 0 -5mv
GTL Ref 1 -40mv
GTL Ref 2 -5mv
GTL Ref 3 -40mv
or
GTL Ref 0 +10mv
GTL Ref 1 -25mv
GTL Ref 2 +10mv
GTL Ref 3 -25mv
You get the idea anyway. There are lots of combinations I didn't write there, but just keep trying you'll get it. Also you should try raising Vtt to 1.25 - 1.30v and using negative GTL Refs like the first couple of sets I posted above.
Write down what you have tried and what Vtt you used, and just work through it bit by bit. You're doing well so far :up:
You should see my notebooks with scribble all over from taking note of minor changes i make and whether they work or not :up: You just need to make one or two small changes at a time, make notes of what you changed and whether ti was better or worse so you can refer back to it later. It helps alot :)
It tooks me months of patience and testing to get my current completely bulletproof 481MHz FSB as it is now. Also few sets of memory sticks and other things!
If there is one thing you have it is time, so take advantage of that and don't fluster yourself for nothing. I personally use both OC profiles on my Rampage, Profile 1 is for Stable OC thats tested and proven, Profile 2 is for testing new settings. That way I can just save my current testing settings to spare profile, and go back to stable anytime I want. Then when my new set of testing settings prove completely stable and bulletproof I'll save them to first profile and start working on new ones in profile 2. I've reached the limits of my board with its bios though. So my current settings are the best I'll be able to get them with this CPU and ram and I'm extremely happy with that. Took a few months of long testing and trial but hey it's why enthusiast products to me make me feel so enthusiastic to play with :up:
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.
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. :shrug:
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.
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.
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?
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.
That makes perfect sense. thanks.
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 ?
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
if i increase VTT
gtl value (ex. -5mV) remain the same ?
why 0/2 are different 1/3 ?
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
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.
If I have a 90nm cpu, should I use like 0.7?
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.
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?
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.
For those who want to know more about GTL Reference Voltage: Understanding GTL Reference Voltage
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
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 ^^
Jesus Christ i HATE f-ing GTL! :D
Is it even necessary to look to much in to GTL values at sub 500FSB?
I'm thinking on a quad core system.... YES! I can't break the 445FSB on my x3360
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?
omg this is very helpful thanks for the information i hope i will setup the right values
Big Thanks to Cryptik for starting this thread & Mike for his detailed analysis :up: (had to read some of it twice!! ... uh well maybe three times!!;)) I've had a ton of fun with my RE & E8600 but was rather dissappointed that I couldn't reach the magical 600fsb that I had seen posted all over this and other sites, AUTO settings at that!! I'd gazed at this thread a few times and then it a fit of desperation @ 4 in the morning decided it was time to play with the GTL's. Well, booted in 2nd try @ 9 x 600 PL 8 after doing the math!!:D Didn't think it was necessary with the E8600, thought I would read the thread when I put my quad in but WOW!! Been busy the last few days and had problems getting into Xtremesystems for the last week but now that I'm back on just had to say a BIG THANKS.. I'm sure this will really benefit me when I go for the QX9650!! Here is where I finished off the other night....
Holy crap 1.72V, Phase? ^^
I'm afraid I'm going to have to bump my earlier question seeing as I'm afraid it fell behind :/
Quote:
Originally Posted by BUMP
Sorry haven't been in here in awhile. That description of the 0.63x data and 0.667x address makes perfect sense, however does the same situation exist when you factor in increased vcore and very large FSB/clock frequency increases? Is the data bus as resistant to ringback and is the address bus as resistant to jitter under the completely different circumstances created by overclocking? I found with my system that the data bus is the most sensitive, perhaps the ringback starts to needs compensating for at higher BUS/clock speeds, and responds to (is stabilized by) increased Vref much more than the address bus, which can almost be left at 0.667x with a slightly raised Vtt even up to ~534 FSB.
I have not had much luck setting the vRef for the data bus the same as the NB Vref. My boards NB default multi is 0.640x whilst the default data bus multi is 0.635x. To be completely stable, my NB GTL Ref is -40mv, and the data bus GTL Ref is +60mv, my NB will not tolerate 0.64x + GTL Refs and the cpu will not tolerate less than 0.635x on the data bus when at high speeds (4GHz+). This may be a function of the changes occurring due to overclocking and the requirements of both the CPU and NB under these conditions. It seems at least with my system, that at elevated speeds the NB and CPU need to be tuned separately to maintain valid data transfer between source and destination.
The use of clock skews is imperative to achieve stability, especially it seems with quads. However each system appears to exhibit unique behaviour, some preferring a delay of 100 - 200ps on the NB with the cpu left at normal, and others prefer a 100 - 200ps delay on the CPU with the NB left at normal. This may be either due to the CPU used, or variations in components on the board, or other factors. To a very limited extent you can overpower the need for NB skews with increased NB voltage but in a lot of cases a decrease in NB voltage can be achieved with correctly set NB skew.
500 FSB on a quad is not something we see often, perhaps as much due to people not wanting to push the chip that hard as opposed to the same speed achievable on a higher multi as a lack of boards to support it. The only quads ive seen doing 500 FSB with reasonable volts are the occasional 65nm and the occasional low VID 9650 on a suitable P45. The A3 revision P45 chipset seems much more capable in terms of quad overclocking, and although only possessing a 6 phase analogue PWM, the Gigabyte UD3P is handling them very well, with 4500 MHz and 500 FSB 24/7 stable able to be achieved. The Max II Formula, which has the same 16 phase PWM as the Rampage Extreme, seems to be able to handle it too but not many of the guys with one have chips that are 500 FSB capable at volts they are comfortable using. Also the M2F seems quite capable at 4500 MHz on duals, with no CPU/NB clock skewing or ram skewing necessary for complete stability. Choice of board is very important when intending to push the limits of your hardware.
There's no hard and fast rule to this, You can feel free to experiment with every combination of the GTL Refs. For example I set +20mv for all my GTL Refs the other night doing some testing, you are not going to hurt anything unless you have a very high Vtt and the Vref goes over 1.10v.
You can try for example, +50/+10/+50/+10 or +50/+20+/+50/+20 or +50/auto/+50/auto or +40/-5/+40/-5 would give you your ~46mv difference if you find that to work better.
The default multipliers for GTL Refs 0/2 are 0.635x and the default multiplier for GTL Refs 1/3 are 0.667x, so to get the same Vref when multiplied by the Vtt you need different modifiers for 0/2 and 1/3, ie: 50/10/50/10.
I guess the way to tune GTL Refs differes person to person. To roughly tune them, I prefer to make sure ram/NB is stable, manually set Vtt, and, using a vcore that is slightly too low for the given speed, use either orthos small FFT or Intel Burn Test to see what GTL Refs give me the longest fail time or least errors, respectively. You must be certain the rest of your system is stable though or you will be wasting your time. You can also somewhat fine tune the GTL's by also examining the Gflops output with IBT, they should be very similar to each other, and correct adjustment of the GTL's can achieve this.
You're not the only person with a 9550 that requires high GTL's. Just use whatever works for you best, GTL settings dont port over from other peoples systems. You may need more Vtt, vcore, vPLL etc as GTL's can't make up for a lack of vcore etc.
Cheers I'm glad this thread has turned out to be useful. Mikey's fantastic explanations have also been a very valuable contribution.
That's a great result, congratulations! Glad this thread helped, and yes dual cores are also effected by GTL's not just quads. Any particular reason why you are buying a QX9650? From what I've seen from other peoples results the Q9650 E0's clock much better than the QX chips, and the RE seems to be able to handle 470 - 480 FSB so 4.23 GHz should be achievable on much lower vcore than on a QX with your RE.
Clock jitter gets worse with increased frequencies and voltages. Not much you can do about it really besides make compensation adjustments. Each board and its components will vary the effects of it as nothing is perfect, traces, capacitors, resistors, chips, everything has a part in it. Gigabyte UD3 from my understanding behaves so nicely mostly due to the increased thickness of copper between PCB layers which helps to minimize trace leak and interference. Probably why it can get away with a smaller VRM and be more consistent. All that Asus have done with adding more phases to VR is offset against the trace losses and interference that the PCB design incurs, and jitter produced when driving the clocks internally as phase timing for Vcc gets gradually worse and more inconsistent.
I understand that's the case anyhow, though GB's approach of shielding from signal interference and minimizing transit loss over traces is the correct way to handle the problem. What Asus does by improving VR capacity and output stability by adding more phases to the design is no different than a PSU manufacturer like ThermalTake who jacks up Rail Current Output and keeps introducing models with more and more W to sidestep electrical design flaws and weaknesses instead of releasing a unit that is much more efficient and can do the same job with 500W less capacity. Sidestepping a problem only makes it happen later on, handling it and managing it correctly is difficult and costly, but eventually it saves more than it costs. Problem is with Asus method is that all they are doing is band-aiding the CPU, while other devices on the board still have same poor behaviour that only gets worse and eventually cripple the system before the potential of the 16-phase VR can be reached. Designs like this aren't meant for everyday at high frequency, only stable benchmarking. Gigabytes designs are meant for everyday stability, I applaud that and wish Asus would take a leaf from their book. No point being able to run 600mhz fsb if my sound card is so crackly I can't hear the actual audio, or my HD speeds are so abismal that it's faster reading and writing off floppy drives, OR my NIC drops out so frequently I might as well switch to wireless. heh.
And for your entertainment, heres a HD Tune screenshot taken of my 4x320gb Raid 0 running off ICH9R on my Rampage Formula at 476Mhz FSB.
It looks more like a seismograph's output during an Earthquake :rofl: Asus should be proud of their engineering brilliance, turning my raid array into what appears to be an earthquake :D
That's a good point about the added copper layers in the Gigabyte boards, I wasn't aware they reduced trace leakage and cross talk/signal interference. Hopefully other manufacturers follow suit. I was saying to someone about a week ago how I didn't think the 16 phase PWM on Asus boards was the bottleneck with their performance, and that other components/design limitations were what was the limiting factor. Under load with quads though the UD3P's are emitting a high pitch squealing which indicates things are getting towards the limits of the design, and when you consider the amount of current a quad at 4 GHz+ is pulling and the fact it has only 6 phase then its no wonder. There's one guy running 4.4GHz 24/7 on a 9650 so if he keeps that up it should be a good test of the boards longevity under that kind of pressure.
The M2F seems to be a bit hit and miss, some guys (like me thankfully) got solid boards that are predictable and perform well, other guys seem to luck out, one thing ive noticed is no two boards behave alike, even guys that have had 3 using the same exact hardware had markedly different experiences with each board. The new gigabytes seem quite consistent from what i can see from the thread. My board is running flawlessly at 4.3 GHz (478 x 9, DDR2-1147, PL8), no crackles in the sound, no NIC dropouts, nothing at all, it's rock solid. It's hardly an extreme clock for 24/7 but it's well out of spec, however things may change if it was at 600+ FSB.
@ bobly .....yup, SS Unit from Little Devil.
@ Cryptik ......Thanks for the reply and I've had the QX since they first came out. It sits right now in my main system @ 4.2 Ghz, 1.4V on air. I was very leary to try any higher as blowing up 900 euros would REALLY hurt!! Now that I've got the phase and a little more experience I was going to put it "under the cold" to see if I could improve my 3D Mark scores. You are right about the NB GTL's. Many combinations seem to work but stabilty for me means I have to set the NB GTL -30 to -40 lower. Thanks again guys!!:up:
Ok Guys so I might need your help Currently Running this E8600 @ 4.5ghz on water chip is great runs fast with low vcore im loving it now I want to try some bench runs on water and with the Rampage extreme it seems to be finnicky like one dash of anything will cause it not to boot lowering voltages makes it more stable most of the time and once its stable its steel but you need to get there first so here is the question
is my math correct
VTT of FSB voltage = 1.43
1.43x0.667 + Y = VTT x 0.635
0.95381 + Y = 0.89535
Y = 0.89535 - 0.95381
Y = -0.05846
Y= -58mv and round it to -60mv
so I would set core 0 and core 1 gtl ref to -60mv ?
Im currently not using the GTL ref (auto) because its been stable rock solid at these settings but when I want to do some benching these values become more important at higher speeds.
mikeyakame,
thanks a ton on that insight how actually Gigabyte is achieving that. I have had my gripes about ASUS recently, frankly. And I might change over to Gigabyte next time, per chance when I am getting a Socket 1366 system. Gigabyte seems to spend more professional thoughts into board design, while ASUS may become the victim of their own 'coolness'. 16 phase power looks stupid to me.
I am not so much concerned about the high GTL ref. of 0.69 on myboard. I only discovered today that my system is running stably at setting NB and both CPU GTL references to 0.63, which somehow did not work for me initially.
What I don't get is:
I had a Maximus Formula board before which only had one BIOS setting for all CPU GTL references. The next generation ASUS P45 boards introduced that split up of data and adress GTL references. And since I can only run my Q9550 at NB and CPU GTL references set to the same values, this likely means for a well part of the P5Q/P5Q3 users that ASUS' approach on keeping the references apart failed. Or it introduces more setbacks than gains, whatever they are.
I just wish I could hook up a good oscilloscope to the onboard traces and really SEE what's going on, to see the effects of my BIOS settings on the actual signals.
I wonder what awaits us on the QPI bus! Perhaps nothing fancy for a while, until that new bus getsto its limits in several years future :p:
Ah ok no problem then, its should go pretty nicely with cold, it's already doing well for that type of cpu, better than some 9650 E0's, so it looks like you got a good one.
0.635 x 1.43v = 0.90805v
0.667 x 1.43v = 0.95381v
0.95381v - 0.90805v = 0.04576v (rounds to 46mv)
So for example you could set:
GTL Ref 0 = +10mv
GTL Ref 1 = -35mv
GTL Ref 2 = +10mv
GTL Ref 3 = -35mv
or
GTL Ref 0 = Auto
GTL Ref 1 = -45mv
GTL Ref 2 = Auto
GTL Ref 3 = -45mv
However there is no harm in setting the GTL refs to only 40mv or less apart, so play around and see what works best for your system. My cpu seems to like the data bus Vref raised but raising the address bus Vref doesnt seem to make much difference.
(*)I tested my CPU on prime95 small fft's on 3.6GHz 1.42v 9x multi at 1600FSB and passes 8 hours.
Ram at stock, memtest 8h pass. Still get freezing on blend.
I have been at this for a year now, only thing left is gtl refs.
Raised voltage to sensible levels but still higher than needed.
I've tried from +50/+10/+50/+10 to +90/+50/+90/+50
tried minus too +30/-20/+30/-20
core 0/3 from 2/4 always 40 difference. If I'm out of the calculated result i get instabilities even sooner.
But I always leave the NB at +50 (+46 needed,calculated).
I need to know this:
if I get bsod and restart means is the CPU gtls(*)?
If I get freezing is it the NB gtl?
Also should I decrease or increase the NB gtl? VTT is at 1.49v, NB is at 1.5v
Trying +80mv now, all the way from +50mv are unstable for me. Strange, they take almost the same amount of time to freeze or gimme the the BSOD then freeze.
I don't recommend actually calculating NB GTL Ref. You need to find through trial and error what gives the most stable results. Leave it auto to begin with, and see how you go. I tested my NB GTL Ref from -100mv to +100mv and found my sweet spot at 445 FSB on 5:6 divider was -60mv, and at 478 FSB on 5:6 divider was -40mv. Other guys with the same board as me require different NB GTL Ref settings for stability, some cant even boot on my settings.
It's important you experiment with your board and find exactly what it likes at a given FSB/clock/memory speed etc.
There is no specific rule that defines what causes what kind of error, it could be anything, ram timings, vcore, Vtt, vdimm, vNB etc. Try to isolate specific items like cpu, ram, NB and try to stress each one to find the problem.
The fact you pass 8hours of small FFT's but fail blend to me indicates a ram/NB instability. Try playing with NB GTL's as I suggested above, and also adjust your ram timings/vdimm. You may also need to experiment with clock skews on ram if you have them.
When I said calculated I meant (VTT x 0.667) - (VTT x 0.635) = 0.046 for me to use on my CPU.
Isn't the NB the same? Anyway used -46 on NB for now (I'm guessing I should go lower, upper means more unstable) and testing CPU again small fft. Ram is fine because I tested it a few days ago, its running on stock frequency, volts and timings.
Its hard to believe the cpu has been stable at 3.8 with 1.54v at 1800 fsb small fft's (q6600 G0, 1.26vid) but blend has been unstable even at 2.4(stock)/2.8/3.0/3.2/3.6 GHz
New question: Is something done different on the Asus Striker 2 Extreme?
People post GTL settings that look similar to this:
GTL ref 0: +50mv
GTL ref 1: +10mv
GTL ref 2: +50mv
GTL ref 3: +10mv
Except on my S2E, 0 and 3 have the same options (going from +14 to +224, and then negatives) while 1 and 2 have different options (going from +13 to 208, and then negatives). Does that mean I should be setting mine like so:
GTL ref 0: +50mv
GTL ref 1: +10mv
GTL ref 2: +10mv
GTL ref 3: +50mV
?
Edit: Arf this is crazy, I'm nearly stable, primed for 18h without errors and IBT works too (with GTLs on auto) but sometimes I randomly get system freezes, I've noticed they happen more often when I'm transferring a lot of info from one hard drive to another (either SATA to USB or SATA to eSATA) or when playing Assassin's Creed. It's weird but while all other games will work fine and sometimes system freeze every 24-48h, Assassin's Creed will system freeze within 15 minutes >.< Everest reported VTT of 1.28V so I've set it to that in the BIOS for now...
Edit Edit: Worklog
X means pass, a fail will be indicated by the symptom of failure. First X means it posted, second means it booted into Vista, third means it passed 5 passes of IBT (not a real test, but it gives me a rough idea of if I'm on the right track or not, fourth one involves general use, usually crashes within 30 minutes on Assassin's Creed if incorrect).Code:S2E w/ Q9550 REF0 REF1 REF2 REF3 POST BOOT IBT STABLE
FSB 1866 42 0 0 42 X FAIL
Multi 8.5 14 39 39 14 X X FAIL
Memory 1600 -7 26 26 -7 X X BSOD
CPU-Z V 1.36V -14 26 26 -14 X X X FREEZE
PLL Auto 28 65 65 28 X FAIL
VTT 1.28V -21 26 26 -21 X X X FREEZE
Memory 1.9V -21 13 13 -21 X X X
NB 1.5V
SB 1.5V
My Vdimm (memory voltage right?) is set to manufacturer specs which are 1.9V 1600MHz, 7-7-7-20, it should be stable at those settings. On a smaller overclock I had the Vdimm set to 1.86V while still remaining stable, I only put it back up to 1.9V to stay within specs.
What's the rule of thumb/a good voltage to start with for nb gtl? Should I then raise it higher or lower? Is there a maximum one shouldn't go over?
I'm noticing that negative GTL References seem to fail less than positive ones, could thing mean something else? Maybe my VTT is too high?Code:S2E w/ Q9550 REF0 REF1 REF2 REF3 POST BOOT IBT STABLE
FSB 1866 Auto Auto Auto Auto X X X FREEZE
Multi 8.5 -29 13 13 -29 X X X Testing
Memory 1600 -21 13 13 -21 X X X FREEZE
CPU-Z V 1.36V -21 26 26 -21 X X X FREEZE
PLL Auto -14 26 26 -14 X X X FREEZE
VTT 1.28V -7 26 26 -7 X X BSOD
Memory 1.9V 14 39 39 14 X X FAIL
NB 1.5V 28 65 65 28 X FAIL
SB 1.5V 42 0 0 42 X FAIL
What did you test the ram with? Bootable memtest or HCI memtest? Blend is harder on the ram that bootable memtest in my experience.
If it is failing at completely stock speeds, timings, voltages for cpu, ram and NB something is not right at all.
Yes it looks like your striker bios is a little different. Probably using 0.635/0/667x/0.667x/0.635x from top to bottom by the looks of what you posted.
If you are getting lock ups when accessing HDD's perhaps your southbridge needs more voltage. Try increasing it a little and see if it helps.
Okay well I'm currently on -21/13/13/-21 and it seems to be doing okay, Assassin's Creed ran for over an hour without a freeze, though I've ran into the slight problem of having spent all morning playing it and needing a break :P I'm going to do some hard drive sorting though, swap a couple hundred GB around, see if that freezes it.
Before fiddling with the GTL refs I tried upping SB to 1.6V but that still didn't help, only made the NB get a little more toasty :P
Edit: Yup copying files did it XD Gonna bump the SB up a bit.
Edit Edit: First reboot with 1.6Vsb BSOD'd however I think that might have just been a freak accident due to the system freeze that happened during multiple file transfers just before. Since it's not crashed yet, I'll keep moving things around, have a go on assassin's creed again later, but hopefully it will be slightly more stable now :) Then I can prime overnight.
EditEditEdit: :( system freeze again... My computer hates moving files >.<
Memtest and yeah blend is much harder.
1: Loadline Calibration doesn't make a difference, but if I want to go over 1.5 vcore I enable it.
2: On full system load vdimm drops so I need even more voltage on ram at stock freqs and timings.
3: When I booted with memtest on stock fsb, I could get 4883MB/s. When I raised the fsb from 1066 to 1600, without changing anything (P1 & P2 are on Auto and when I double checked they are disabled) the ram did 5861MB/s. That is another reason I need 1.94v instead of 1.9 :shrug:
I definitely made some progress on gtl refs on CPU.
I used to think the same, that's why I have been clocking for a year with no success, until yesterday. When overclocking the first thing that's holding you back is the values you say you will keep untouched.
It seems that raising the fsb above cpu designed makes your northbridge run faster of course, so it demands more of your memory. If you are not raising the pci express busses or MCH SPP freqs, the maximum you want to keep your SB would be on 1.6 unless u go over 500 FSB (2000).
The thing with Vista is when you copy files to an external storage such as usb, requires a lot of memory, its the thing about vdimm.
See my previous post for details.
Hum I'll give it a go, see if it helps. You also mention disabling loadline calibration, would that not also mean having to raise CPU Voltages? Because it's already set to 1.4V in BIOS (1.36V in CPU-Z) and I can't really afford to raise it any higher for 24/7 use :/ (Water cooled but can reach mid 60s under load).
I have been following this guide http://www.anandtech.com/mb/showdoc.aspx?i=3283&p=1 quite helpful in my opinion.
My latest discovery is if you are sure you have you cpu 100% stable (prime95 small fft's at least 4 hours) then run your ram one notch higher than stock (vdimm) then test with prime95 blend, if it freezes, increase NB voltage, mine runs fine at 1800FSB on 1.6 actual. and 1900FSB with 1.65 actual.
Auto on all GTL refs seems the easiest and most stable option to me.
Bear in mind anandtech applied ceramic paste on NB and SB, they found that over the suggested it gets really hot and leads to instability. Even with liquid cooling, I wouldn't go over 1.7 actual.
PLL would be fine at 1.58v til 1900FSB at least with q6600 VID 1.26.
On LLC, I see what you mean; I was thinking the same thing not long ago.
If you hit a wall though, you still freeze and you have more than enough voltage on NB and ram then you might consider disabling it, or just check with everest or something similar for NB temps. If you suspect the ram is getting hot, touch it with the back of your hand or your finger (but not with palm skin, its denser there and you might think the temp is fine) and if you can hold with it there for 10 seconds that means is fine. If you can't hold it then consider some airflow on them.
Watercooled cpu get 60 degrees? What paste did you use? I have mine on 1.55 v ceramic paste air cooled with IFX-14 and the max I get is 66 celcius.
Once I am sure my whole system's stable I use these methods to lower vDimm and vNB:
Running blend with memtest for windows at the same time shows if ram's unstable
Vga torture test plus blend again to see how long it will last for the sake of adjusting vNB (usually crashes within an hour)
If you need any help considering MB just let me know. :up:
One more thing, on ram timings make sure P1 and P2 are on auto, visit corsair's forum for your ram and see what is the default bank (tRC) and tRFC. For instance, (mine) OCZ recommends for maximum capability to set tRC to 50 and tRFC to 110. If you can't find any info on these advanced timings, what you can do is run everything at stock, preferably on auto except vdimm (at 1.9v) and timings (excluding advanced) and NB at (1.44v) and see what the MB set for your ram, then whatever is on auto set it yourself. I think you might get stable timings like that, though on mine it tightens them just a bit.
All the suggestions I mentioned make huge performance gains and huge instabilities. All of them require more voltage on ram but P1 and P2 requires more vNB. I wouldn't worry about them now though, you can play with them later as long as you make sure you have the most stable settings.
People, having Loadline Calibration Enabled (or any other vdroop reducer or eliminator) reduces CPU life, CPU needs more voltage and strains system, in my case causes instability in overclocking. Though I had to enable it because I was going over 1.5v.
Full report here http://www.anandtech.com/cpuchipsets...spx?i=3184&p=6
Having a higher voltage on non cpu use will not raise your temperatures, on load though lets say 1.42 LLC Disabled does less heat from 1.42 LLC Enabled.
Yes but isn't the idea that because of vdroop, with LCC Enabled you can have it set lower than with it disabled?
Enabled: CPU Volts set to 1.4V in Bios, 1.36V in CPU-Z
Disabled: CPU Volts set to 1.4V in Bios, could dip beneath 1.36V under load and therefore unstable?
That was my understanding of it.Cibic thanks for the awesome reply, hopefully tomorrow evening I'll get some spare time, read over it properly, take some notes and start some intensive testing ^^
Asus Striker II Extreme with LLC Disabled has a vdroop of 0.05v so if you want your cpu at 1.36 on full load you really want it at 1.41.
By the way, ram at high speeds are most likely to perform at design specs with dual cores. On quad cores you should relax timings and increase voltage to sustain operation, or relax timings just a bit, increase voltage a notch or two and downclock it. Either way, it should be about the same performance. Nvidia chipsets get the most performance with 1:2(or 1:1 with ddr2) ratio, 1900FSB linked and synced with my ram, so I can't decrease ram frequency.
Wish I had someone to help me when I got this MB, lets hope I save you some frustration.
Has anyone tried using linpack to tune NB GTL and skews. I tried the following and wonder if it is a valid method and whether the results are repeatable.
Stable at 450Mhz FSB on Q9300 (specs below)
CPU GTL tuned as here - http://67.90.82.13/forums/showpost.p...&postcount=425
CPU skew / NB skew / NB GTL - 3 linpack Gflops (vista x64 max memory - about 3070MB)
A/A/+40 - 46.4 46.9 46.8
A/A/+20 - 47.3 47.5 47.4
A/A/A - 47.2 47.5 47.4
A/A/-20 - 46.4 46.9 46.7
A/A/-40 - 46.8 46.9 46.8
So opted for NB GTL + 20
-100/N/+20 - 47.2 47.5 47.4
N/-100/+20 - 47.3 47.4 47.3
-200/-100/+20 - 47.2 47.4 47.3
-400/-300/+20 - 47.4 47.5 47.4
So opted for -400/-300.
Just finished a 12h OCCT RAM (Large) run and it is stable.
Any thoughts? Are there any other combos of skews you would try?
Andy
Cryptik,
Bought myself a DFI LT-X48 T2R as a spare board while my Rampage is getting unbroken and thought what the hell I'd have a play with it.
I'm in love here :D Taken me 3 days of a bit of playing around and finally got 400mhz FSB stable heh. GTL adjustment is simply awesome though. Printed myself out a copy of the VTT/GTL value map tables DFI put together for reference because god knows I could ever remember which value means what at which Vtt.
Fine tuning is pretty damn amazing though. 0.008v GTL fine adjustment values mapped all the way from 1.06v Vtt to 1.60 or 1.70v Vtt. The tables themselves cover roughly 0.533x to 0.780x if I recall, don't have the desire to rip out a calculator to confirm that heh.
http://dfics.dfi.com.tw/dfi_cs/LTX48/X38X48_vtt.xls
If you're interesting in dropping your jaw take a look at that excel spreadsheet. It's definitely jaw crashing to the floor worthy :up:
Also explains what the hell all the numbers mean I always wondered myself, now it's perfectly clear to me. And the adjustment is flawless in all aspects. CPU 0/3 and 1/2 are paired which is fine, and NB is on its own on the LT X48 I got.
Nice, I think I'm getting a DK-T2RSB Plus to have a play with. Been tossing the idea around for a couple of months, just have to make the final decision.
DK lacks the adjustability of the LT, I compared both and went for the LT. The price difference was only $30aud or so, it wasn't very much. The LT I found to be the much better buy, as it also has a 8 phase digital volterra VR and a pretty cool northbridge cooler made by thermalright. You can attach an 80mm fan to the back of it vertically. The UT model had a silly heatpipe joined cooling assembly and probably not worth the extra cost.
Yeah the LT does have 8 phase, but the DK has a better clockgen, it uses the same one as one the Rampage Extreme (ICS 9LPRS918JKLF) which is the reason the DK can hit higher FSB than either the UT or the LT (DFI actually said that). The DK still has 6 phase digital PWM with 18 fets so its not too much worse in that department.
I do wish they just modified the LT to have the same clockgen as the DK. It would be good if you had a nice E0 wolfdale to test the LT with.
EDIT - the DK (when 'advanced' BIOS mode is selected) has a large amount of options, at least all the ones Ive seen you mention the LT has. Perhaps the LT has more though, I haven't seen bios SS's from it, nor do I own one.
The hysteria over loadline is nothing but that..hysteria. It IS true that vdroop is there for a reason, but this is supposed to be for cpus running at *STOCK* voltages and speeds. Yes, Intel knows we overclock; heck they're even overclocking now (and as everyone knows they have taken a more overclock friendly approach than the hardline approach from years ago; witness the extreme editions--who would want an unlocked multiplier EXCEPT overclockers? It's completely absolutely USELESS for a normal consumer).
While it is true that droop is supposed to prevent voltage spikes on load/idle changes, there is still absolutely zero proof anywhere that cpus have been damaged by it. The only warnings have occured from loadline causing -overvolting- at load instead of matching the BIOS settings. There was a huge recent thread about this, which turned out to be nothing but a bunch of hot air and flaming. Oh and keep in mind that vdroop only existed starting with the pentium 4 line. There was no noticable vdroop (at least nothing of this magnitude) on the pentium 3 chips; and those chips used -higher- vcores (2.0 for old P3; 1.75v for coppermines) than what we have now.
I will also tell you this--from personal experience. High voltage does cause degradation, far more so than heat, although each chip responds differently. And it is MORE dangerous to set a higher idle voltage without loadline or vdroop mod, than it is to set a lower voltage and using loadline/vdroop mod, as long as your load voltage doesn't go higher than idle. Voltage is the #1 cause for degradation followed by temps. I had degradation *just* from high idle voltages on a P4 northwood by putting 1.7v idle into it and leaving the computer on idle constantly. Load voltage was 1.62v, a lot lower. And it wasn't the load voltage that caused GNDS here, it was the idle voltage. If there had been a non soldering vdroop mod back then (at least that I had known about and been able to use), my chip would have lasted alot longer without reducing in clocks so sharply.
My X6800 also reduced in clocks (tho not as much as the P4's) by needing 1.55v for 3.7 ghz-which required 1.625v set in BIOS for idle. It was the high idle voltage that hurt the chip; it lost about 100 mhz; needed about 0.05v more. 1.55v idle would have been a LOT easier on the chip. I would have much rather taken the chance with random spikes, than having this happen! And even 1.55v idle was too high; would have been best to have the vcore at 1.5v max (idle) on air.
Subzero completely changes the game.
BTW I didn't know anything about vdroop mods when I had the X6800 either, but my P5W is now vdroop modded and my QX chip hasn't been damaged anywhere near what the X6800 without mod was; there has been very light degradation (something along the lines of 0.01v more needed) but that's it, and I don't keep it at 4 ghz unless I need it anyway.
This is something that I have been wondering about for a while. Wouldn't voltage spikes become MORE dangerous while overclocking, in theory? Im just wondering weither a higer voltage is more dangerous at idle while the chip is drawing very few amps or if its more dangerous to have a slightly higher voltage while the chip is under load while drawing much more amperage. Then I am hearing reports of loadline overvolting while on full load when tested with a DMM on Asus 16 phase boards. If you combine that with voltage spikes from overshoot (Im not sure if Im using the appropriate term here) it sounds a little more dangerous to me, but vdroop is also huge on my board 0.05 vcc from idle to load with cpu-z.
Hello,
after having wondered about if I can manage to run my Q9550 E0 and the P45 NB at the stock GTL values after all after such a long time (Bought my CPU in October), I tried out what powellandy did, also after having read something along the lines from mikeyakame.
And, I was successful. I just felt that a narrow range of 0.66-0.69x for stability on all GTLs was not looking like the system felt overly well. Here are my results, old first:
Mainboard: ASUS P5Q3 Deluxe Wifi@n
FSB Clock: 450 MHz (x8.5=3825)
CPU VCore: 1.275V
DDR3 RAM Clock: 1350MHz (4x1 GB Corsair 1600 modules)
NB Volt: 1.4V-1.44V
FSB Term Volt: 1.36V
CPU GTL Ref (0/2): 0.66x-0.69x, using 0.68x
CPU GTL Ref (1/3): 0.66x-0.69x, using 0.68x
NB GTL Ref.: 0.66x-0.69x, using 0.68x
LLC: Enabled
CPU Clock Skew: AUTO
NB clock Sew: AUTO
New:
Mainboard: ASUS P5Q3 Deluxe Wifi@n
FSB Clock: 450 MHz (x8.5=3825)
DDR3 RAM Clock: 1350MHz (4x1 GB Corsair 1600 modules)
CPU VCore: 1.275V
NB Volt: 1.4V-1.44V
FSB Term Volt: 1.36V
CPU GTL Ref (0/2): 0.63x-0.70x, using 0.63x or 0.65x
CPU GTL Ref (1/3): 0.63x-0.70x, using 0.67x or 0.68x
NB GTL Ref.: 0.63x-0.70x, using 0.63x or 0.65x
LLC: Enabled
CPU Clock Skew: 500 ps delay
NB clock Sew: 400 ps delay
400/300 works, too, less than that tends to instability. Once again it shows that automatic settings aren't really good...
I am currently using 0.65/0.68 to not be on the razor's edge. These settings also take into account that ASUS is trying to keep the GTL references 0/2 and 1/3 apart...on top of this, the stable way higher GTL reference range indicates that this is a lot more of a stable setting than previously. However the previous settings without skews were tested 11 hours prime stable, too.
The best way of stabilizing a 45 nm quadcore above FSB430 appears to be to try and compensate with the clock skews first and leave GTL Ref. lines at defaults (not AUTO!), and then test the upper and lower limit of stable GTL settings. Then use a value that's in the middle, to be as far away from the limits as possible.
Translated into more analogue terms, this means the smaller the stable range of GTL references is, the closer the signal overshoot and undershoot are getting to the reference line. With it, the probability of one of them crossing the reference line increases drastically,and with it certainly the chance of having data corruption on the processor bus.
If you've got any questions or need my full Ai Tweaker settings, let me know.
:rolleyes:
This thread is a joke, I can overclock more with all gtl refs left on auto :P
That's a very good question but I'm not sure. The loadline overvolting thing seems to be on Asus' newest boards with new bioses; apparently they didnt get overvolting on older bios (this on a core i7 board; I don't know about the p45 or x58). But if Pencil/hardware mods work properly, then people may do that instead if Asus broke loadline.
Anyway if loadline/vdroop mod is working as it should, it's much better to use it than to not use it, since otherwise you have to raise the idle vcore significantly to compensate for vdroop, and high idle voltage *can* (not saying will, but *can*) degrade a CPU. It's far better to have temporary spikes to what that idle voltage would be, without a vdroop mod, when using a mod/proper loadline, and lower idle voltage, since the CPU is exposed to less constant higher voltage. example: 1.35v idle/1.35v load with spikes to 1.41 is a lot safer than 1.41v idle/1.35v load, since the cpu is idle a LOT more than load (unless you fold 24/7 or are one of those rare people that always have a game running). Someone on ocforums posted a very clear graph explanation of this not that long ago (you can find it in a search there).
I ended up using loadline on my board because my vdroop is HUGE with my Yorkfield. It's something like 0.08 (prime load) and 0.09 (IBT load). Oddly it was half that with my wolfdale. At that point I was much better of with it enabled. I figure the 16 phase power distro for the cpu on my board should help minimize any spikes.
IMO I didn't found any clue that enabling LLC would degrade a CPU. I was playing with Asus Rampage Extreme these 3 months and I always have LLC enabled to prevent significant vdroop.
Yesterday I was accidentally have LLC disabled (E8500 @1.2v, 500x8)
Then when I tried to IBT it the vCore droop from 1.177~1.194 (By MB sensor, never trust CPU-Z) to around 1.134, of course wierd behaviour appeared / unstable / random reboot due to insufficient vCore....:shrug:
I read this thread all the way through and still cant see what determines a positive or negative GTL. I'm not an Algebraic person so that's probably my loss.
My current vTT is 1.378. I have all the references set to +50 only because I seen someones exact set-up as mine. My vNB is 1.56 and set to +40GTL.
I have Asus RE & q9650 on H2O. Thanks for help and yes I'm new here and yes this is my first build. Thanks! -keith
I'm an enabler.
FSB frequency and clock strength/timing/skewing determine positive or negative GTL. You need varying values depending on a lot of things. Sometimes you need higher, some times lower. Only way to calculate a base is to try values and see how they go. It just takes a fair whack of time to get it right. You'll get a feel after a while how the system and board responds to changes and different values, too high or too low or even just right.
Use windows boot up as a gauge.
I honestly use Windows Sidebar/Gadgets to take rough guess' on GTL references and clock skews :)
If they pop up with scroll bars something is screwed. If they take a while to load up something isnt right. Etc.
If system is running smoothly all my 5 gadgets pop up nearly same time ;) The ones that require internet connectivy, ie ISP traffic stats and weather might take a touch longer because of ethernet adapter initializing.
Also I use Everest load up time to gauge as well. I run Everest with task scheduler at user login. If it takes aw hile to scan pci devices and load drivers something isn't right I can tell immediately. It should load up very fast with minimal delay ;)
Another little hit I find is the timing of the Windows Startup Sound in relation to the login screen, if one happens before the other depending on how far apart they are tells me skewing or GTLs aren't right. It's up to me to figure out which one is causing it. Thats the fun of it. Nothing can tell you exactly the problem and how to fix it, only hinting at where it lies and it's up to you to use those hints to guide your adjustments :)
I'll give you a good piece of advice. The key to success lies in observation :)
Thank you for your insight. I was able to get this far, actually farther but I decided on my below settings for a 24/7. Your right, OC'ing takes time
and for me taking notes was very helpful. Still lost on the +/- thing. I will research. Thanks again. -keith
mikeyakame,i do something very similar to what you describe.after i make adjustemts to my OC i open prime95,then start blend,then i quickly click the test button and if the popup window is slow to appear or lags in any way,im pretty sure that somethings wrong and ill just stop the test and reboot and make my adjustments.but now that you mention the windows startup logon screen in relationship with the sound,i think you may have just saved me an extra step.thanks
THink of this way.
GTL References are calculated off Vtt. GTL Reference is a ratio or multiplier of Vtt.
So with offset voltages, you have a base GTL Reference multiplier for each GTLREF adjustment. NB is usually 0.63x, CPU 0/3 are usually 0.63x, CPU 1/2 are usually 0.67x.
What ever that multiplier * Vtt gives you in a voltage value is your set GTL Reference voltage for each.
All -/+ offset voltages are is that reference you calculated from the base + or - n[mV].
So say +50mV, with 1.30v Vtt, and NB base of 0.63x.
0.63 * 1.30 = 0.819V or 819mV
819mV + 50mV = 869mV
0.869 / 1.30 = 0.668
Therefore +50mV with 1.30Vtt and 0.63x base, changes the GTL Reference multiplier to 0.668x.
Simple as that :)
Thanks gentlemen. Very insightful. I'm actually thinking "leave well enough alone" where I'm at, which is basically my sig settings below.
vCore =1.356
pLL = 1.590
vTT = 1.378
vNB = 1.55
vdram=1.90 (kingston 2x2 hyper X 1600MHz @1350MHz 7-7-7-21
GTL ref. +50/+50/+50/+50 with NB ref. +40
LLC=enabled
These settings pass an Intel Burn @max load for 10 rounds with the cores reaching upper 60's Celsius.
My current 3DMarkVantage:
http://www.pbase.com/keithallenlaw/i...1/original.jpg
Maybe I need to offset cores 1 and 3 from 0 and 2.
My max stable on this build was 460x9 but I wasn't comfortable with the high voltages and upper 70's Celsius core temps with IBT.
But that test is rigid and doesn't apply to gaming. I truly expected a better bench and 3D score on H2O. I gave up and settled on a
24/7 set-up.
Thanks guys! -keith
You certainly don't need an offset. IBT is good but you can pass even unstable. There's nothing like prime95 blend for at least 4h. If that passes and for utmost stability try prime95 blend among with GPU Caps Viewer> Fur Rendering at 1920x1200. If it crashes try setting NB gtl on auto and raise NB a notch. You need to run that for atleast an hour :up:
One more note. I get tearing when I do the 3DMark test with the performance test because my monitor is
a 2560x1600 and most of the rendering test are at a much lower rez. I believe 3DMark test are 1280x1024.
Thats not even near a 16:10 ratio. You say Prime @ 1920x1200? At least that is 16:10 and the same as my
ratio. I read that trying to render at a different aspect ratio than your native actually lowers your score. Dunno...
CryptiK, with the Maximus II Formula and P5Q-Deluxe
you used to do the same GTL over on your e8400?
How would you tune in a dual core? Are the cores 0/2, 1/3, 1/2, 0/1 on a e8600 running a vtt of 1.35?
-_-
From the reading, I would have thought it would be a -45, being a 45nm. I came up with 45 too.
Would that be 45 across all 4 settings or the sum of 45 on 2 settings? Like -35/-10/-35/-10 etc..
I'll try prime blend also.
does any one know how the gtls on the dfi=ut-p35-t2r operate?is it percentages or mv?
Depending on my fsb voltage, I'm having luck with -40's or -45's straight across. And +50 on the nb.
Motherboards know best
Only did relatively brief stability testing on the P5Q-Deluxe as I just bench on it and run the M2F 24/7, but I was around the same Vref on both boards.
I run +60/+20/+60/+20 on the M2F and 0.680x 0/2 & 1/3 on the P5Q-Deluxe, both with a Vtt of 1.25v giving a vref of 0.85v on both boards.
No idea, theres a table somewhere you can DL that explains them IIRC. I'm pretty sure mikeyakame DL'd it for his DFI although its an X48 maybe give him a pm and see.
Wafer thickness in nm is not what to set your GTL Refs to. 65nm and 45nm do behave differently, but whatever works best for you.
Motherboard makers were waiting for you to tell them how tune GTL refs
newbie here in xs, but not in oc'ing.. =) i have been reading this thread from page 1 to eternity and i tried to dig in to the equations and computations to get the applicable gtl ref for my system... problem is, i've tried using the formula .8 / vtt/fsbterm value = gtl ref from 1.3vtt - 1.4vtt with the vnb set @ 1.4 (to rule out nb getting choke coz of hi fsb) and the cpu pll @ 1.52
tested stable setup (see sig) is 450x9 @ 1.26vcore, 470x9 1.28vcore, 500x8 1.28vcore. tried 533x7.5 but i cant get it stable even if i set the vnb to 1.42, i know the p5q-d is capable of running 1600fsb so i think it doesnt need too much vnb to go around 2000fsb... when i try to add around 10fsb to either one of the stable settings posted, it wont stable, even if i bump the cpu pll to 1.58, vnb to 1.44, vcore to 1.35 (bios) 1.32 (cpu-z)
settings are pl=10 no pullin enabled, 333 strap 1:1, pcie clock @ 101. as far as i can see those settings should be good anough for, let's say 4.2~4.3ghz... but i cant... only the 470x9 1.28vcore is stable but when i go to 480x9, my system goes quack quack (as occt says lol!) everytime i run occt 2hr medium set..
any inputs on where i should start checking for the right gtl? any inputs also on my settings?
math hater here, my nose bled so much while i was trying to understand the other formulas that's why i ended using the easiest one, the .8 / vtt/fsbterm = gtlref
help... =(
i was able to make 510x8 stable... i used the gtl calculator from seban (nice work dude!), set my vtt/fsbterm to 1.3 and set the gtls to 635/675, however, the vnb that was computed was 1.46 and i set the nb gtl to .620 following .9 / 1.46 = .620... temp rised on the nb, have no home for my system right now lol! nb temps reached 45 max temp during 2 hours occt custom medium test
still working on the 533x7.5... anyone tried putting a fan on their p5q-d's nb? like a 40mm fan? or how's like antec spotcool for my nb?
thanks for all the guys who shared their knowledge about gtls and stuff... even though my nose bled non stop while i was reading some of the "more mathematical" approach... lol! thanks! will post screenies once i got some stable settings around 520fsb++...
hey cryptik, could you post your settings for your e8400 e0? i'll try to check out some settings that can boost my e8400 e0 =) i know this baby can do more than just 4ghz =)
Hello everyone!
I'm trying to get my Q6600 (G0) stable, and I'm working on the GTLs now!
I had an E8400 before, and it was quite "easy" to tune it with the GTLs, because I changed both 0/2 and 1/3 in the same way.
Now I will have to change them seperatly, right???
I d/loaded Seban's calculator, but how does it help me?
I have an Asus P5Q-E, so I enter the GTL-REF in "0.670"-values...
So, how do I do this now?? The BIOS say "0.630" is default vor 0/2 and "0.670" is default for 1/3...so, where to start now?? I'm aiming for 3800-4000MHz, so a FSB of about 445MHz max. if possible...
Thanks in advance for your help!!
Is GPU caps viewer safe to run at extended times, since Furmark will burn your card.. more likely the VRMs..
I really doubt that, but anyhow software that torture vga's accomplish what is needed within a hour IMO.
Sorry for replying so late.
DFI GTLs aren't either. They are mapped values against Vtt voltage points vs 160 steps from roughly 0.523xVtt to 0.83xVtt.
each value between 0-160 is roughly equivalent to 0.0015v - 0.0020v.
For example 1.06v Vtt GTL table:
CPU GTL 1/2, 0 = 0.556v, 160 = 0.816v
CPU GTL 0/3, 0 = 0.545v, 160 = 0.843v
NB GTL, 0 = 0.586v, 160 = 0.861v
1.50v Vtt GTL Table:
CPU GTL 1/2, 0 = 0.783v, 160 = 1.046v
CPU GTL 0/3, 0 = 0.773v, 160 = 1.069v
NB GTL, 0 = 0.824v, 160 = 1.102v
To correctly calculate them and roughly extrapolate between 2 Vtt voltage maps, you'll need to print the Vtt mapping tables out that DFI have hidden away on their website and have a calculator handy for figuring out the rough voltage u need for your Vtt, then find its numerical equivalent in the tables, and if Vtt is inbetween 2 points just roughly calculate what inbetween value you need.
I have the VTT GTL tables printed out and stored in a folder so I can refer to them when making changes. You have so much precision in GTL voltage adjustment it's mind blowing. It's worth spending the little bit of extra time to calculate what values you should need based on guesstimation.
I find I can run really low Vtt voltage if I spend the extra time, and I haven't had a GTL related Prime95 or Linpack failure that I couldn't completely eliminate yet. As long as Vtt is set reasonably with respect to FSB frequency and CPU you can get it stable with fine adjustments to GTLs, that no other board will ever do.
http://dfics.dfi.com.tw/dfi_cs/LTX48/X38X48_vtt.xls
Here you go. Have fun with it ;)
thanks for the info mikey!