Printable View
I'm not done pushing things yet, but this is in my Shuttle SP35P2...10 passes giving IntelBurnTest access to just short of 3GB of memory, nice and quick test that I'm gonna be promoting every change I get.
http://img98.imageshack.us/img98/579...9ghzys0.th.jpg
1.12v under load and 1.168v idle ain't too bad I figure, curious to see how far I can go with full stability with these higher temps.
2AgentGOD: can 32bit apps handle /3GB key in 32 OS? Is it possible to do that by setting flag IMAGE_FILE_LARGE_ADDRESS_AWARE = 0020h?
Why the 32bit app cannot determine the maximum available RAM to test (by selecting "1.") if there more physical RAM available that virtual - i.e. that app can handle.
Use
I suspect you use only dwAvailPhys not the minimum of this.Code:GlobalMemoryStatus, then minimum of MEMORYSTATUS.dwAvailPhys and MEMORYSTATUS.dwAvailVirtual
Before any VirtualAlloc for maximum memory actually available (virtual+physical at the same time if lots of RAM) to app.
The memory limitation for 32-bit was actually introduced by Intel themselves into the 32-bit Linpack binary, and not me. So adding that switch won't do anything.
Ok, i saw it in both binaries' headers. Characteristics - 0x10F. It's no harm to fix both headers to 0x12F and fix Checksum in PE header after.Quote:
Originally Posted by AgentGOD
So what about memory allocation trouble? Is it done by linpack? Or you passes already allocated buffer to it? If you what about the rest of my post above? /it's not related to /3gb key. it's because only physical memory available is taken into account not virtual which can be less./
Linpack is compiled with all optimizations and what not by Intel and supplied as a binary for single processors. I don't think there is any way any of us could ever optimize it that good if we had the source. The 32-bit version isn't very optimized as it is a broader version for all x86 chips. The 64-bit binary is highly optimized for EM64T processors with SSE4.0 and above. That is the main difference between the two. 45Nm chips will work a little harder than their 65Nm counterparts in this test due to having SSE4.1.
Even if you changed the binary with a hex editor setting LMA aware flag, the binary was never compiled with more than 2GB addressing. This may or may not be a problem, but would introducing possible buffer overflows for the sake of using another 1GB memory be a wise thing to do on such a precision application? Without knowing whether Intel's source used signed long long int's or unsigned long long int's you may or may not introduce problems. If all long long int pointers are unsigned you should be fine. But I wouldn't use unsigned long long int's if I only needed to address and work with a value that a signed long long could contain, because sometimes the flexibility of negative values is necessary.
2mikeyakame, only hope that they are good coders in intel) and use x86/x64-independant sign appropriate types like *_PTR, size_t, TCHAR etc. not just "int" for everything). Since there are lots of useful defines it's quite easy to define what you want simply defyning PU[type]_PTR and no multy word definitions - hope intel programmers do alike.
That is true unless the source base is coded as universal for both *nix and Windows. There isn't too much differences between compiling for either *nix or Windows in my experience and can usually be managed with Makefiles and headers alone. Would require a lot of #if preprocessing statements throughout the headers to use both Microsoft typedefs and *nix typedefs. Makes more sense to keep things simple and stick to type definitions defined by ANSI C standards rather than OS specific. That is just my personal opinion anyway...without seeing the actual source base all I have is conclusions based on experience/simplicity, hardly credible none the less!
Edit:
Never mind the *nix bit I thought I'd read that it was also for Linux in the Intel docs. My bad.
Linpack is written in C though, not C++, so question is do all those Microsoft C++ typedefs apply to C also or are they only applicable to use under C++? I generally write code in C for *nix, and C++ for Windows. I've never really written anything in C to work in Windows so I am at a disadvantage there it seems.
They are C-compliant because they are based on define & typedef macroses and basic types + "bool" since later c compilers recognize bool type. Also maybe long long as __int64, other larger __types for SSEx also must be supported by compilers.
take a look at basetsd.h, ntdef.h from MS for short& useful definitions of common types.
[edit]
Just MS Win kernel all in plain C. And they provide headers for C cuz all drivers for Win are written in C.
Thanks for that info! I should probably look more into it when I have the time. I've never bothered using C in Windows cause I've never had the time to sit down and figure out what is applicable and what isn't. I suppose as long as the library functions ones is accessing through the code doesn't require object orientated functionality there is no real difference between C or C++ besides the code to write it, spare the few differences in internal functions that exist between different C libraries.
Fantastic program :up: , really beats the :banana::banana::banana::banana: out of my Q9450. Quick question, sometimes, Prime95 fails when IBT passed me (10x pass). Which should I believe?
10 passes is not enough.Quote:
Originally Posted by Singh400
It is like saying that Prime passed 4 hours (but fails at 4Hr 10min)
When I had 2 x 2GB ram, I was running 10 passes until it was stable at the CPU speed I wanted. Then I would run for 20 passes adjusting VCore again. Final test was 400 passes with NO errors.
Using 4 x 2GB instead of 2 x 2GB Ram made a big difference.
Running 2 x 2GB I could set the FSB on my Asus P5E WS-Pro (Q6600 G0) to 365 and run 400 passes with no errors and no increase in NB volts.
Putting those extra 2 x 2GB Ram, I had to raise the NB to 1.55 and it still got errors within 60 passes.
With a FSB of 346 and NB of 1.31, it can pass 80 passes (10 hrs) with no errors.
This also meant the VCore could be lowered and thus lower temps.
(Vista Ultimate 64bit)
You could go on testing indefinitely by that logic... nothing is ever ENOUGH per se, but this is closer.
lame I ran this using almost 8gig of ram I think 25 times, passed. Also have run prime95 in all modes while playing games etc for 36+hrs.
Comp still freakin crashes! Never buying another MSI board. Anyone else having compatibilty isues with a HD4850 + P45 + maybe 8gigs of ram?
Yup, then you get into the debate on whether or not anything can every be truly 100% stable, or just extremely close.Quote:
Originally Posted by Loser777
What is stable ? 10-100-1000 passes, retesting it each week ?
Stable to me is that my Pc does everything I want it too when I want it too... it can pass linpack, yet fail on prime, or a 3dmark,... or crash in a game,...
I told this numerous times before, only a mix of programs is the better tester and daily usage is the best test. There's no definite bulletproof testing program...but with this program you don't have to wait for hours to see if something is wrong...
And guys plz stop doing 100 plus loops, what a waste of cycles and total ridicilous hardware punishment...
Hi,
I am using a Q9300 processor at 3.2 Ghz and was wondering why I am only getting a performance of roughly 21 GFlops as floatingpoint performance, while I should have roughly twice that much? this looks like the program was only using two CPUs instead of all fours despite detecting four threads and four CPU cores.
I am running the 64 bit version of Intelburntest, on Windows Server 2003 x64.
Any ideas?
This is weird,I have an ASUS Striker II Formula and when i test my E8500 with Supertalent ( Super*Talent T800UX2GC4
)DDR2 800 MHz memory it tests stable 1 time then the next it doesn't! I changed to Transcend DDR2 800 and it's Perfect everytime but the ST ram has been checked and is not Defective!I'm running both in dual channel mode,yet the ST will be perfect everytime in single channel mode! Any idea's why?
BTW,Thanks AgentGOD,exellent Stability tester!
E8500@ 3.82 Ghz,Asus Striker ll Formula 0902,2 x WD 320 GB,EVGA 9800 GTX,2 GB ST RAM,SB X-FI EXTREME Music SC,PC P&C 750 Quad P/S,2 LG DVDRW’s,Zalman9700 CNPS Cooler,Antec 1200
Increase the boards chipset voltage.
I completely agree.Quote:
Originally Posted by Leeghoofd
Please note that linpack minimally stresses the NB, even with the largest amount of memory selected (option 1).
In my PC the NB at idle is at 58°, with linpack32, option 1, at 60°, with OCCT and S&M memory test, I am at 65°.
Thanks Stealth,I was wondering if maybe i needed a little more! Appreciate your Prompt reply!
3D stability differs from ram/cpu because it stresses different parts of the nb (and the CPU to a lesser extent).Quote:
Originally Posted by Peen
IMO 10 should be done to see if you are far awary from stability
if passed, do 20, then 40 then 60 to see if you are getting there
Finally 100 to make sure...
Hello,
I am pasting my test results here, as additional data. Does anybody have a clue why I am only getting a performance of roughly 23 GFlops on a Q9300 quadcore, while a Q9550 user is getting roughly 45 GFlops? It's not like two of my CPUs were idle or so, all four are under full load.
Could it possibly be that the Q9x50 processors are coming with 12 MB L2 cache instead of my Q9300's 6 MB?
Enter the number of times to run the test (5 or more recommended)> 10
----------------------------------------------------
Executing Intel(R) Linpack 64-bit mode...
----------------------------------------------------
Intel(R) LINPACK data
Current date/time: Tue Sep 16 23:16:05 2008
CPU frequency: 3.450 GHz
Number of CPUs: 4
Number of threads: 4
Parameters are set to:
Number of tests : 1
Number of equations to solve (problem size) : 18534
Leading dimension of array : 18534
Number of trials to run : 10
Data alignment value (in Kbytes) : 4
Maximum memory requested that can be used = 2748448024, at the size = 18534
============= Timing linear equation system solver =================
Size LDA Align. Time(s) GFlops Residual Residual(norm)
18534 18534 4 190.305 22.3067 3.386492e-010 3.495055e-002
18534 18534 4 183.210 23.1706 3.386492e-010 3.495055e-002
18534 18534 4 183.008 23.1962 3.386492e-010 3.495055e-002
18534 18534 4 199.026 21.3293 3.386492e-010 3.495055e-002
The GFLOPs rating by Intel has to do with how much RAM was tested, as well as the time it took to run the tests.
Just in-case you guys are curious, here is my system's current status:
http://i34.tinypic.com/2zgcl08.jpg
I wanted to lower the vcore two notches (from previously known IntelBurnTest stable configuration), and it resulted in a BSOD after the first iteration (MACHINE_CHECK_EXCEPTION).
Even after lowering the vcore two notches, it was still hot. I turned off ThermalThrottling (CPU TM) in the BIOS for the most accurate testing.
Guess this Xigmatek is getting dusty.
P.S.: I only look at the maximum CPU temperature, not averaging them. I'm using RealTemp v2.77, and it uses 100*C Tjunction value.