9GB is where it works. Above 9GB we have severe GFlop dropoff. Do 10240MB size and you'll see ~50gflops instead of 80+.Quote:
Originally Posted by donmarkoni
Printable View
9GB is where it works. Above 9GB we have severe GFlop dropoff. Do 10240MB size and you'll see ~50gflops instead of 80+.Quote:
Originally Posted by donmarkoni
OK. First I have to make my black and green PCB Hypers work together. If not, I'll swap my Kingstons with friend's Patriots. As you can see on AIDA64 OSD, there is only 5x2GB.Quote:
Originally Posted by zoson
Hmm... Just realized that I made over 20.15 ratio for Hi Perf. Club. Just need to make it stable. :D
BTW, I hope this is not off-topic. It is related to LinX (linpack).
Im using the new Phanteks in my sig, its slightly better than the silver arrow :)Quote:
Originally Posted by LennyRhys
The H2O 620 was a complete fail with this CPU.
Regarding the pins, I have an R3E which has two 8 pin CPU ATX connectors, but my PSU only has one 8 pin and one 4 pin.
So atm its using 12 pins powered, with the akasa cable it would have all 16 pins powered.
bhavv: phanteks's fans are worse though then thermalright's TY-140 performance/noise wise.
Yes, you need to change the fans, or add a third:Quote:
Originally Posted by churchy
http://www.vortez.net/articles_pages...review,14.html
I have 3 fans on mine so it should be performing as good as air cooling can get.
My PC has been solid and stable for gaming the last few days, so the instability in Linx must be due to temeratures.
I tried reducing the CPU PLL to 1.25v, but it still froze after a few linx loops when the CPU reached 86 degrees. If I get any problems in games, I'll just put the BCLK back to 180.
Is this pure madness?
http://img856.imageshack.us/img856/1385/44289286.png
o.O
Yes, that's far too hot lol especially on air cooling. I'd pull it back considerably or at least try to get some cold air on it - I cooled my 970 with 13C outside air and I was scared when it went to 84C, and that was only 1.45v.
The Phanteks cooler is supposed to "scale" in performance as it gets hotter... looks like the only thing that scales is the temperature LOL! :D What's the ambient temp of your room?
Will be comparing this with my Venomous X and 260CFM San Ace fan as soon as I get it all rigged up later this week. :up:
Yea its not running that high, it wouldnt even complete 3D mark. Its back to 4.66 Ghz, even 188 BCLK @ 4.7 Ghz wasnt stable.
The room temerature started at 16 degrees .... now its baking lol.
4.66 Ghz is still stable, it hasnt crashed in anything yet:
http://3dmark.com/3dm11/2300377
Haha yes it will warm up the room :D Have you tried using the turbo multi of x26? I used the turbo for x25 on my 970 and that's what got me the best OCs. :up:
Might not be able to get that for a while, the CPU wasn't Prime stable so you're probably right about needing more tweaking. Primed @4.875GHz over the weekend so I'll stick with that.Quote:
Originally Posted by R37ribution
No, due to the ram overclock 26x would OC it too high. Its running at 186 x 25 for 1866 Mhz ram too. On the next ram multiplier up it needs 155 BCLK for 1866 Mhz, and that only allows up to 4030 Mhz on the CPU with x26.Quote:
Originally Posted by LennyRhys
Theres no point using my ram at 1600 Mhz Cas 6 on this CPU because I can go up to just under 1900 Mhz @ Cas 7 and it has a high enough multiplier not to need 200 Bclk.
Ah I see - you're wanting a specific RAM frequency. I abandoned that idea a long time ago, seeing that RAM speed makes virtually no difference whatsoever to performance. I have 2000 C8 Dominators which I run daily at 1528MHz C7 which is plenty for me, and when benching I can push them over 2100 if I want. My problem with high RAM frequency is that it puts extra strain on the IMC and requires very high uncore voltage which in turn makes the CPU run hotter... all for nothing, other than high Gflops in LinX. No thanks!
Working with my 980X - revised submission below.
Your GFlops are much lower than a tweaked uncore will fix.Quote:
Originally Posted by LennyRhys
Looks like your linpack binaries are not up to date.
As I've stated many times, 1.5x uncore vs 2x uncore difference is only 2-3GFlops, and you should have >80GFlops at 4.5GHz HT on.
How very annoying. I updated LinX from the first page just 2 days ago (when I got the 980X) and I have SP1 so AVX should be working, but it's clearly not. Ergo, there's nothing else I can do. If I change memory to 1800 and Uncore to 3600, I get 75 GFlops exactly the same as bhavv... but that's not >80 like some of you guys are getting. Suggestions welcome.
EDIT: OK it's sorted: fresh install of Windows 7 + SP1 did the trick, which is fine because it was long overdue anyways - seems that my 970 runs were all affected too. Oh well... there are tons of submissions with 40-45 GFlops which I now understand are definitely not being stressed as hard as others. I'm not running in diagnostic mode (yet); just wanted to do a quick test and I got an increase of 10 GFlops with exactly the same settings. Will test properly for stability when I move my PC back to the "cold room," and next week I'll see if I can be the first to submit an air-cooled 4600 / 12 threads.
http://img840.imageshack.us/img840/8654/77flops.png
I don't think I'm going to be able to beat this with air cooling, unfortunately, so I'll make this my 980X submission for now.
From what I can tell, this is the only "properly" stressed 12-thread submission with air cooling.
BIOS values:
CPU: 1.4v
QPI: 1.35v
RAM: 1.64v
LennyRhys | i7 980X [6C 12T] @ 4500MHz | 1.392v | Asus P6X58D-E | Air | 3036C128
http://img705.imageshack.us/img705/7...00mhz6c12t.png
I really wanted to get 4.6GHz with HT on but I just can't get GFlops to scale at all :shakes: I was under the impression that low GFlops meant that QPI/Uncore are not stable, but taking vQPI up didn't fix anything. This is how GFlops looked with different QPI voltages, all with 1.45v on the CPU at 184x25:
1.35v 75 GFlops
1.375v 81 GFlops
1.3875v 84 GFlops
1.4v 74 GFlops WTF :shrug:
Increasing vCPU to 1.475 didn't change the weird QPI behaviour:
1.425v 77 GFlops
1.4375v 85 GFlops :shocked:
1.44375v 76 GFlops LOOOOL
1.45v 73 GFlops (I gave up at this point)
One thing I since noticed which I have not yet tried is LOWER vQPI with high vCPU - I'll try that tomorrow. I see all these amazing submissions by zoson and others where vQPI is at only 1.35v with insanely high mem frequencies and 90 GFlops... and the trend there is that vCPU is very high.
I had hoped my 980X vcore would scale well from 4.5GHz to 4.6GHz but it looks like 12 threads of an extra 100MHz needs at least 750mV. Will try again tomorrow as the air is very cold and the best I can do with the very high vcore is approx 80C over ambient with the Copper TRUE and 6000 rpm San Ace, lol. :D
@LennyRhys and everybody looking for HIGH GFLOPS:
It does not depend only on this or only on that.
Your system must be tested bit by bit. Start only with CPU, find optimum speed/GFlops ratio while taking into account impact made by different voltage.
Then take your time with UnCore, again looking for increase in Gflops, while trying different voltages.
Then the RAM testing must be done with extreme caution, as it's most sensitive part, stability wise, especially when fine tuning latencies.
One advice: always try higher voltages when you think you have found stability. ;)
Thanks for the advice donmarkoni. The frustrating thing about LinX is that anybody can easily compete 20 passes with different degrees of stability, from very weak to very strong, and I now see why zoson wanted GFlops included in every submission because with AVX it is a completely different kettle of fish. This has become more like Core2 overclocking and I love it - it's much harder to achieve "optimal" stability and there's much more tweaking required.
I made a little more progress with 4.6GHz 12 threads by pushing CPU to 1.5v with QPI at 1.35v, but it's still very finnicky.
And, annoyingly, my 4.5GHz run above with the exact same settings and voltages now gives me 75 GFlops even after being very stable for an hour... lol. At least I got it once, lol... LinX is actually a pain in the a$$. :yepp:
You can eliminate the fluctuations by using diagnostic mode. The reason is because diagnostic mode prevents all services from starting, except those that are required for the system to work.Quote:
Originally Posted by LennyRhys
Many services are on a delayed start, and will only start after the system has been idle. So you can do a LinX and get high GFlops, but then if you let your computer sit for a few minutes, and test again... You will have low GFlops because a bunch of services have started and are now using your resources. I always test in diagnostic mode for best results.
I want to test HT off, but I've been so busy with work. :( I also need to take apart my machine to dust the radiators... It's been several months and i'm positive they're covered in dust now. That's like an 8+ hour job. :(
Cool thanks for the tip - I'll keep it in diagnostic mode from now on and see if I make better progress.
I've been trying to reproduce the exact same 4.5GHz run that I did above (180x25 with 1800 7-8-7-24-82-IT and 3200 Uncore) but for some reason LinX keeps flagging up errors after 3-4 passes even with the exact same voltages. One thing I have ascertained is that GFlops peak with 1.4 vcore and 1.35 QPI (not a shred above or below), averaging out at 83.5-84, so I've been tweaking IOH and have seen interesting results - anything above 1.24 IOH causes GFlops to drop, yet my run above was done with 1.3v IOH rofl.
I have a strong hunch that my motherboard just isn't of the right caliber for this level of overclocking - CPU PLL can't go any lower than 1.8v, chipset/ram voltage increments are too big for fine tuning, and I'm not convinced the VRM is doing a good job of regulating these very precise voltages (which might exlpain the inconsistency/instability in my results).:shrug:
OK solved some big problems but still some remain. I was a total idiot and forgot that I had left PCI-E frequency at 102MHz, so putting that back to 100MHz solved the random LinX stops. Another big oversight of mine was using the "All" memory option on LinX instead of 5120 MiB... so correcting that has given my tests consistency that they lacked before.
The GFlops fluctuation problem persists, however :mad: I managed to get over 84 GFlops (very consistently) by raising vcore to 1.4125... raising it further resulted in a drop in GFlops. I then tested some different memory timings, to no avail, and when I returned to the same settings as my 84 GFlops run (several restarts later), it's gone back to 80 GFlops! ARGH! All my memory subtimings are auto; the only ones I've set are primaries and tRFC, which is at 82 (72 sucked, as did 88). Could that be causing fluctuations?
Running in diagnostic mode did something WEIRD... my GFlops went to 53 when I ran in diagnostic mode, and I could tell something was wrong because at "100% load" temps were 50C lol :shrug:
Will go back to it tomorrow... determined to break into 85 GFlop territory but it's looking like I might have to use my memory at its rated 2000 8-9-8 for that.
Lenny - youre seeing your optimum qpi to vcore ratio dude. When you hit your max in qpi and it dips again raise vcore to match it and it should bring gflops back in to line.
The low load you saw was a core (or more) dropping out - caused by either low qpi or a completely wrong qpi:vcore ratio at high core mhz.
I think I may have borked my windows installation already - diagnostic mode plays funny with restarting. When I open up msconfig and select diagnostic mode, it takes about 30 seconds to actually get there, and the "Msconfig: Not Responding" is displayed at the top in the meantime. After restarting my system, it powers down before POST then up again as if there has been a fault, but it keeps trundling along happily and when in windows it sometimes detects a really random amount of memory, like 3.7GB, and I must have inadvertently run the test with about 3GB, hence the low GFlops. I've since managed to get diagnostic mode working properly/seeing all memory, but it's very temperamental... :shakes:
Regarding GFlops: my main problem is that GFlops are going up and down with no change to voltage whatsoever... it's really annoying. Today I did two runs (at different times, with several restarts in between) with the exact same voltages of 1.4125 vcore/1.35 QPI, but I mysteriously lost 4GFlops somewhere along the line. Every single setting in BIOS was unchanged. :shrug:
Thanks for chipping in pilsy. :up:
I'm coming for your crown, don. ;)Quote:
Originally Posted by donmarkoni
So far i'm 8 loops stable 100GFlops at 4536MHz core, 4067MHz uclk, and 2190MHz mem.
Memory dropping out like that is usually a result of not enough QPI voltage.Quote:
Originally Posted by LennyRhys
Every IMC has a 'drift' associated with it, and the motherboard checks your tWR latency, and then sets an 'estimate' for your tRL latencies. Each memory channel has its own tRL, and it's normal for your dimm slots that are physically further away from your cpu to need higher latency, as the signals take longer to go back and fourth due to the increased physical distance.
tRL can and will CHANGE with every boot, unless you set it manually, and is one of the reasons why there are fluctuations in GFlops. This is because the internal resistance of your transistors will change depending on gate voltage and temperature.
This is why you will have a session where everything seems ok, then you have an error, and it never seems to work again. Your chip hit a temperature that increased the internal resistance of your transistors. This is usually temporary, and can be fixed with a full power down and power cutoff via the psu switch. Leave the machine off for a good 5 minutes to allow the cpu to discharge and cool off. Keep in mind, the same things can apply to the power delivery system of the motherboard itself!
Increasing QPI voltage can help mitigate the drift within an IMC, but it will not eliminate it. Make sure your cpu is nice and cool, and don't go overboard on the voltages for an extended period of time!
I highly suggest you manually set your ram timings, and try to figure out the sweet spot for tWR.
The 'power down' thing you described is actually a 'memory recheck' feature that most x58 boards have now. It's directly related to a memory channel dropout on post, and the motherboard resets and loosens tRL latencies in an attempt to compensate.