What i like to see if possible is the GFLOP's again as that also goes to show what GPU's and system builds can do compared to others, but of course the memory free used will also factor in the score.
Printable View
What i like to see if possible is the GFLOP's again as that also goes to show what GPU's and system builds can do compared to others, but of course the memory free used will also factor in the score.
You can still see the GFLOPs by running IntelBurnTest with error-checking disabled.
Well then why have the error checking in.... :)Quote:
Originally Posted by AgentGOD
I know it is there for those who can't read the numbers to understand if they passed or not.
Cool then we can still see them if error checking is off ... thats good.
Update to my previous post.
After my system being stable after 30 passes, I then ram Prime95 using large FFTs. After 2Hrs and 15 mins, my system crashed.
I have now raised my PLL, FSB Term and NB voltages.
I quickly ran prime for 3Hr and 20 mins with no problems.
Will run it overnight (16 hours ) to test it.
Just goes to show, no one test alone stresses everything.
But, it is still a great stress testing program.
The benefit of this program, besides finding not stable machines, is to do a stress test in a QUICK timeframe, 10-15mins compared to the over 2h required in orthos and occt to find errors.
Besides, I do agree with unclewebb that what matters in the end is stability in YOUR daily use.
I agree, at least on my setup, it would help to quickly find unstable OC's using the max setting. I am not sure if it's from the code or fact that it raises my load temp an additional 10C over prime to 66 from 56. I will still prime/orthos overnight to be sure.
On my previous post with pics, at 2 notches below stability, orthos failed in 3.5 hours versus both runs of 15 intelburntest on max setting failed in 21 mins each.
I just finished testing 1 notch below stability, where orthos 10ffts and prime small ffts has failed at 8 and 10hrs. Intelburntest failed one 30 run at max and passed one. It made 2 errors in first 60 run, and 1 error in second 60 run but not until line 49, so may well pass a 60 run if ran enough times. Odds are also unlikely it would pass 2 60 runs (3 hours total) in a row and odds are it would fail the first run.
But at both one notch and two notches of vcore below stable, this version of linpack was quicker than orthos/prime at finding instability, so it seems useful prior to running prime overnight, for those like me that do so.
I like this software, for sure. It help me to finding errors in my new rig that prime95/OCCT have not found in many dozens of hours of test. For reaching stability in my windows xp x86 i need less volts (for Vcore, NB and Vtt Cpu), two o three notches less, that for reaching stability in my windows x64 (4 hours of test). With x86 i use custom level, 2GB of RAM. With x64 i use level 1 (3.5GB). So, i have a question: It´s strictly necessary to use the bios settings for max stability in x64 if we will only use the x86 version for 24/7?
I will say again: it is highly recommended to use the most memory possible in a 64-bit Windows environment for the most accurate test.
True, I thought better and you have absolutely right.
Great Little program.
I'm still trying out to see how sensible is it.
I'm using Vista Business x64 SP1 with 8GB, Q6600 GO VID 1.3000 @ 3.1GHz.
I can report that using Max I get lower GFlop numbers and much lower CPU stress, CPU Temp (with Real/CoreTemp) report around 55C using custom with 6000-6500MB or mid settings I get 68-69C.
After first fews runs look like prime95 but more stressfull, cpu temps are nearly 10C hotter:
Running low memory high numbers -> Small FFT
Running mid memory high numbers -> Large FFT
Running high memory mid numbers -> Blend.
Sometimes I get a slight different residual in the first round of test (5 test) but nothing in the next 2-3 rounds.
I've tested my new rig without any problem at 3.1GHz 1.2875V 24h prime95 (latest beta), a mix of prime95/3DMark03 for 12h, Othos/OCCT whatever I've throw at it, stable like a rock, after the first round of LinPack in 5 min I've uncover that my CPU is not stable, up the vcore a notch, nearly stable, at vcore=VID=1.3 look stable.
My goal is 3.0Ghz so I've attained it, yes not extreme, but it'll be my main rig and I want absolute stability, without pushing too far.
BTW the q6600 GO are an absolute steal, not as fast as penryn clock-for-clock, but less problem with the board, mature process 65mm, more cheap, the next big things is the tock version of i7 (aka Nehalem) next summers not the penrys
I noticed that this is a really good program to find VTT problems. Prime/Orthos needs really long runs but this does it in minutes. :)
Exactly the point.Quote:
Originally Posted by janolle
cool
Need some help with this program.
I'm trying to get my system stable but aparently it is not even stable when underclocked...
One strange thing I keep noticing is that burn tests always reports my CPU as 3.2 ghz wven when it is underclock to 2.4 ghz.
Can I really trust this program to provide accurate results when the CPU clock is not even reported correctly?
I think it's defaulting to standard multi, but the FSB is correct.
No . . . Hot!Quote:
cool
75 degrees !!! Orthos only gave me 67.
Not good, I knew it was too good to be true when I purchased computer parts and all of them worked without having a single RMA. I Always get a defective part ALWAYS. Now to figure out what is defective is going to take a long long time! :( Whats my best bet to try next in a situation like this?Quote:
Originally Posted by WoZZeR999
edit:
Memory passes in slot 1, and slot 3, but not when using 1 & 3 together. WTH!
i have skimmed through many of the posts but have not read all 9 pages yet. i did it on 32bit, so i'm wondering why 64bit is more accurate, and how much more accurate? temps on this is actually lower than using orthos with small ftts, so this must mean it's not accurate?
64-bit is more accurate because the cpu is workings at full capacity, in 32bit a lot of registers, cache lines, FPU/ALU only working on half of the bits that they're capable to calculate, so hidding some potential instability.Quote:
Originally Posted by WhiteFireDragon
CPUBurn Also passes when running memory in slots 1 & 2 (single channel) but again fails when running dual channel. Does this indicate a problem with the CPU or the Motherboard? I'd assume it indicates a problem with the motherboard?
Well, returned today from holiday and found the 1.4 were out. So i've downloaded it and found that all issues that i had with v1.1 were off. In fact with v1.1, even if the residual(norm) values were identical, my system went crazy, with nb and sb temp going from -64 to 0 and then dying, the lcd poster starting blinking and the usb wireless dongle connecting and disconnecting. Now with v1.4 all these issues are gone, and i found very useful the auto detection of free ram. Great work!
BTW, it seems to me or the v1.4 runs MUCH hotter than the previous one? running a brief 5 passes test, i saw 78°C on the hottest core while a week ago with v1.1 after a 10 passes test i've touched 75°C and the ambient temp were hotter than today...so the question is: does someone have already burnt their CPU running this test? How much longer can i keep the cpu near or over 80°C before it melts down?
Since none of you replied to my other thread...
Try running this and Orthos together. I can run both seperately and not get over 75 degrees with either one. I tried running them together for grins and my temps shot up over 100 degrees and my whole box shut off.
Give it a shot if you wanna test your cooling. I've never seen something quite like it!
if i'm only using a 32bit OS, how can i maximize the usage?
If it's passing with memory or just slot 1, and just slot 3, then you need to play around with your memory timings/voltages and the NB/GTL voltages.Quote:
Originally Posted by Justintoxicated
10°C higher temperatures as with Prime95 Large-FFT after houres. :eek:
http://i38.tinypic.com/307tauc.jpg