no noobness here... we know it's beta. I like to beta test ;)Quote:
Originally Posted by Dua|ist
btw it works!
I have one request though: could you put the version number in the titlebar in your next release?
Printable View
no noobness here... we know it's beta. I like to beta test ;)Quote:
Originally Posted by Dua|ist
btw it works!
I have one request though: could you put the version number in the titlebar in your next release?
This is not an easy task. But I'll do it. :DQuote:
Originally Posted by safan80
BTW, Happy New Year everybody!
Dualist
I dont know if you would like this or not, but a .txt file with the changelog of the program since it first came out would be great.
Yep, this should have been done from the very beginning. Luckily, I have a full changelog in russian. Looks like I'll have a nice time translating it. :)Quote:
Originally Posted by slim142
hi folks, is there a link for this superb tool that is continuously updated (for the new versions) so i can link this onto my board?
Forget those 2 instances. There IS a way to force Linpack use more threads than number of physical cores in a system from within a single process. :up: If only I discovered this earlier...
Intel suggests using only physical cores probably because of P4 Hyperthreading which does perform worse in Linpack (not only there :) ) when turned on. Why is Intel so secretive anyway? :confused: There is no mention about threading control in Linpack's documentation. Google is a real life-saver.
Currently there is no permanent link. I'm not sure if Fileden supports it. I think if I always keep the same filename and update the archive, link should remain the same. We'll see how it goes since next version.Quote:
Originally Posted by KURTZ
At least with earlier systems, especially socket A, the Vcore being too low causes a BSOD with "STOP: 0x0000009C MACHINE_CHECK_EXCEPTION" or "0x0000000A IRQL_NOT_LESS_OR_EQUAL" and sometimes "0x00000050 PAGE_FAULT_IN_NON_PAGED_AREA" (0x00000050 is the least common of the three, because "PAGE_FAULT_IN_NON_PAGED_AREA" is 99 percent RAM-related)Quote:
Originally Posted by Dua|ist
thanks mate, this is real usefully for us :)Quote:
Originally Posted by Dua|ist
Dualist, the cpu detection is not correctly working in xp x64 sp2. The 2 instances HT Cpu buttom is grayed. I can turn this buttom active editing myself the cpu.cfg, but the program goes wrong anyway for testing HT...
Yes, I'm aware of that. This is because of the fact that WMI section containing the number of physical cores is present only in Vista and XP SP3. And LinX needs to know the number of physical cores to determine whether CPU has Hyperthreading or not.Quote:
Originally Posted by vega22
Good news is that I've finally found a way to override the number of threads Linpack creates, so there's is gonna be no need to run two Linpack processes and thus no need to query WMI at all. By default number of threads (and cores stressed) will already be set to maximum (you can lower it if you want via Number of threads field though). Since next version everything should be OK, please wait a little.
RJARRRPCGP, thanks, the IRQL_NOT_LESS_OR_EQUAL BSOD is the one I see most when there's insufficient vcore. As for the MACHINE_CHECK_EXCEPTION BSOD - it seems weird to me. Every time I've seen it, it was very consistent, while usually BSODs differ slightly from time to time (in case of CPU instability). That led me to think it was some sort of MoBo problem maybe. But I may be wrong.
I used to see IRQL_NOT_LESS_OR_EQUAL a lot when I was testing overclocks on my old AMD dual. It was always memory instability. I haven't seen it with the Intel quad that I have now.Quote:
Originally Posted by Dua|ist
thank you very much, master :up:Quote:
Yes, I'm aware of that. This is because of the fact that WMI section containing the number of physical cores is present only in Vista and XP SP3. And LinX needs to know the number of physical cores to determine whether CPU has Hyperthreading or not.
Good news is that I've finally found a way to override the number of threads Linpack creates, so there's is gonna be no need to run two Linpack processes and thus no need to query WMI at all. By default number of threads (and cores stressed) will already be set to maximum (you can lower it if you want via Number of threads field though). Since next version everything should be OK, please wait a little.
here's a LinX 5.4.2 run that finished nicely
a link to the loaded version is here
http://www.xtremesystems.org/forums/...postcount=1197
Not too shabby. Really like the interface and how if you select over the available amount of ram, it auto selects it right down to the last mb.
Good work :)
My T-Bird 900 at 1050 Mhz would have "IRQL_NOT_LESS_OR_EQUAL" (and I couldn't get it stable no matter what! at least on the Soyo SY-K7VTA-B and Chaintech CT7AJA2E boards, which I had at the time, in 2002) (I first OC'ed that processor in 2001)Quote:
Originally Posted by Dua|ist
I was a n00b in 2001 and 2002, anyways, because I hoped it would be stable, because I could run a Sega Genesis game with Gens with the intro looping for hours without crashing LOL!
while my T'bred 2000+ AIUCB at 2055 Mhz would give me "MACHINE_CHECK_EXCEPTION" when playing GoldenEye 007 with the 1964 0.9.9 Nintendo 64 emulator or Project64 Nintendo 64 emulator LOL! (at 1.82V and the Asus A7V8X-X, which it was one, wouldn't let me go higher than 1.82V!) So I was forced to lower the core frequencies for both systems.
Maynard can U repeat that with 11GB ram usage? I think not :D
Here you go, only one Linpack process for all cores/threads: LinX 0.5.5
Tested only on P4 and Atom, so please, i7 owners, if you're not yet tired beta-testing, try this one and check, whether all cores are loaded or not.
KURTZ and everybody who wants to link to LinX (sounds funny :)), I think (almost sure) this link will remain the same for newer versions.
No WMI calls now, should detect everything correct on all OSes. :up:
Quote from changelog (yes, there's even a changelog now! :cool:):
LinX 0.5.5
- improved threading control. 2 Linpack processes are created no more to load all "cores" on HT processors
- added tray icon option. When enabled, LinX will be minimized to tray
- small interface fixes
Quote:
Originally Posted by Dua|ist
it's not loading my system all the way. cpu is only at 26% and memory is at 54%
here's a loaded picture of 5.4.2 if you need that
http://www.xtremesystems.org/forums/...postcount=1252
:up:Nice release and link(for my system)
Damn. Number of threads is set to 8 and still no go?Quote:
Originally Posted by safan80
I'm on a 32b OS, using 3gb. Should I care if I can run 12gb? no.Quote:
Originally Posted by jcool
Nice clocks though... aren't they? :rolleyes:
with threads set to 8(it defaults to 4 didn't see that lol) it maxes the cpu usage out. I have to use a larger problem size to get close to the same memory usage though.Quote:
Originally Posted by Dua|ist
sounds good mate :) thanks ;)Quote:
Originally Posted by Dua|ist
It loaded mine 99.9%, all 8 threads, but there is some memory bug. Refuses to run sometimes with stopped unexpectedly, error not enough memory. If I try to run with 256 mb, very small, it tells me not enough memory and kicks it up to 1748. It will only let me run at 1748, no less, and half the time when I pick 1748, it tells me not enough memory, though I have 2748 free. (I know there is 1748 limit with xp 32 bit).
But once that bug gets fixed, pretty sweet being able to load all 8 cores with one instance at max memory:up::up:
Dua|ist, I believe to get around the 2 GB per-process limit is to have 2 Linpack processes! Sorry. :(Quote:
Originally Posted by burebista
At least it works on all cores. Here's the fixed version : LinX 0.5.5.1Quote:
Originally Posted by rge
Question is, whether we need to get around that limit at all? Most systems with 4GB of RAM and more have a 64-bit OS, and x64 version of Linpack has no such limit. There are of course 32-bit OSes with 4 GB of RAM and ~3.5 GB of useable memory, but that 2 processes idea was just a temporary fix to load all cores when HT is on. Now that it can be done in a much better way via Linpack itself I don't see any reason to keep this option. The current ~1750 MB limit for 32-bit Linpack is enough to adequately stress-test any CPU, while RAM testing is not Linpack's goal anyway. If you still want to test all your memory, just run 2 instances of LinX. :)Quote:
Originally Posted by RJARRRPCGP
Dualist, Linx 0.5.5.1 worked perfect..that was a fast fix:up:
Here is pic with max memory 1748 on XP 32 bit, loading 99.9% avg all cores.
I also tried it at 2 notches of vcore below stable at 4.2Ghz, where prime reboots around the 2 to 3 hour mark, linx rebooted at 4th run on 1748 mem, then 3rd run on second try, so linx is back in business with 1 instance:up:.
Unfortunately on core i7's, I cant take screen pics of prime errors or linx errors as almost all OC failures on my core i7 are reboots or crashes.
I can only load the next lowest settings that you have rge before I get the "not enough memory" message. I find that after I get that message, I have to close and re-open linx. I did get it to run at around 2.3gb of ram and all cores loaded for a 20 run.Quote:
Originally Posted by rge
Where did you get that i7 core load app? Is it part of realtemp?
loadtester is unclewebbs program (author or realtemp), but not part of realtemp, he sent it to me to beta test load programming on realtemp.
Great program!
Heats up my CPU to 78+C, that's at 4.1ghz/1.4v water cooled... 'only' 55+C at stock speeds, though.
I seem to have a problem to get the 'residuals' to match up...
I'm running i7 965EE on a Asus P6T deluxe, triple channel 3x2gb G.skill, Vista 64.
It behaves the same way regardless if I O/C or not - fails at 2nd run when I select 'all mem'.
In fact, anything over 1.8gb fails (in 64bit setting).
Anyone else with a P6T, 6gb & Vista64 that could try?
i seem to be having the same problem here with the new version.
stock or oc'd it always fails the 2nd loop with all mem selected :(
Yeah me too. Settings 64bit/all mem/optimal leading dimensions checked/number of threads 8/data allingment 4/memory to leave for os 5mb on vista64/6gb ram always fail on second loop.
Same here. Gigabyte EX58-Extreme and Vista x64 with all memory selected fails on 2nd loop.Quote:
Originally Posted by Pyr0
Clicked on one of the links for this program and there is a virus! The HTML_DLOADER.NQZ virus appeared and was detected by trend micro before the software was loaded. The actual link is http://rs524.rapidshare.com/files/160909159/LinX.7z and I think it was on page 5.
Is thisa actually a virus or a false alarm?
nusihb, Pyr0, SetteUltras, burningrave101,
seems like it is only a 64-bit Linpack issue, when forced to run in 8 threads. I heard of that problem before but I don't think I can do anything about it. Reverting back to 2 Linpack processes doesn't seem a good idea to me. For now I can only suggest you to disable the Stop on error option and see whether all other results (starting from the 2nd one) are the same. If they are - it is definitely that Linpack glitch I heard about (the 1st result differing from the rest). I don't think I can do anything about it till the newer version of Linpack will possibly fix this issue. But if all the forthcoming results are same, I can just add a feature to skip the very 1st test.
tomb18, there are no viruses in LinX, must be a false positive. The exe is packed though - this is the only explanation I have that might have caused the detection of a virus.
Up until today LinX has only stopped once with an error. When it has a problem it usually crashes Windows. Here's the second time that I've gotten an error:
Attachment 92645
This is the first time that I've used LinX 0.5.5.1. I didn't see if it loaded my 965.
Note: After posting this message I started LinX again and it did load my 965 100%.
Hi Dua|ist,Quote:
Originally Posted by Dua|ist
yes, thats exactly whats happening. i just disabled the Stop on error option and apart from the 1st set, the rest all match
LinX 0.5.5 runs Linpack in 8 threads now on Core i7, this must be a reason. Your case is definitely not the worst (see posts above). ;)Quote:
Originally Posted by msgclb
This might be some non-CPU problem as Residual values differ much from each other. Could be RAM or NB.
Pyr0, thank you. That is what I was afraid of. There must be some way to fix it without any workarounds in LinX. I'll see what I can do. For now you can consider it stable if all results after the 1st one match.
Dualist
Is the lastest version 0.5.5.1 safe to use on Core 2 cpus? No problems reported regarding memory issues, thread issues or residual not matching?
I wish I could test this and not bother you asking you this, but my system is on the brink of melting so I cannot really test it (not even 1 min).
Yes, for Core 2 everything remains as usual. No problems reported. The oddities affect only Core i7 systems (and only x64 Linpack as it seems). But thanks for your willingness to help. :up:Quote:
Originally Posted by slim142
None of the residues match for me.
But, it seems to work OK if I turn of the HT... so maybe it's the x64 linpack that's not ready for i7 yet.
Nevertheless, it's a great & easy way to determine your O/C limit on i7 with this tool.
Mine runs for hours at 4.1, but just raising it to 4.2 and it reboots after 2-3 'laps'.
Yeah I'm having the same problem. I'm running Vista x64 on my i7 920 and I can't get the residuals to match up for nothing. Like two in a row will match now and then but that's it. I even backed my overclock back down to 3.6Ghz with 1.4V vCore and adjusted most all of the voltages up high and back down to see if that helps but it doesn't seem to be. It keeps running though and doesn't BSOD or anything. The residuals are just all different and that's not including the first run since it's of course failing due to me setting all memory on Vista x64.Quote:
Originally Posted by nusihb
i just tested 10 loops at stock speeds with HT and memory set to all.
all of the residuals and norms matched except #3
I am using v 0.5.5 on i7 with HT and in x64 mode, all residuals and norms match or it is unstable (freeze/BSOD). Finally got BCLK 213 20 runs linpack stable, what a PITA that was.. my CPU sucks :down:
could you select all memory and run it again please?
No time now.. but I did run 5 passes with 3Gb ram, and it worked. VTT requierements for stability are insane past 210 BCLK... I can run 211 stable at around 1,46V but I need close to 1,6 to get 213 stable.
Good night guys!
Ok, I'm running stock settings here with all the voltages in the BIOS set to auto and Turbo mode even disabled and the residuals are NOT matching up. So unless my hardware is bad and can't run stock speeds there is something up. And like I said this is under Vista x64 with HT enabled on an i7 920 and 3x2GB of memory. I did notice that several of you other guys are only running 3-4 gigs of memory.
I've been running Prime95 Blend and Small FFTs and I'm not getting any errors there. I also ran Windows Memtest to try and test my memory but I don't know how effective it is because even with four instances it only loads the cores 50% due to HyperThreading.
http://img404.imageshack.us/img404/9...xerrorspg2.jpg
http://img404.imageshack.us/img404/l...pg/1/w1920.png
Sorry for OT but burningrave101 use latest beta RealTemp, it's heavily modified for Nehalem.
Changed some of Linpack settings, this most likely won't fix anything, but still worth a try I think. Anyone experiencing differing Residuals with Core i7 and 64-bit Linpack is invited to try this one. (But don't hope too much)
Also corrected (lowered) the upper limit for 32-bit Linpack for Vista and Win7. Thanks to SetteUltras for that.
Link: LinX 0.5.5.2. Hopefully I didn't screw anything up this time.
Seems to be working after quick testing.
Good job m8!
Thanks Dua|ist :)
Well done m8, the new version works much better
I've just run a quick 10 loops in Win7 x64 (at default speeds 2660+turbo, 1066 mem) with all memory and stop on error selected and it finished without errors :up:
All the residuals and norms match and the CPU was fully loaded :clap:
Thanks for the heads up! I didn't even notice the beta link when I grabbed Real Temp the other day to test my temps. And I started out on the stock Intel cooler and my temps were pushing close to 88-89C at times since I was running 3.8Ghz+ with more voltage so I guess I really was cooking that thing for a little while. The beta shows me at about 2-5C higher than the 2.70 version.Quote:
Originally Posted by burebista
Well I got an instant reboot as soon as I started your new version :D
Something is off I fear...
does the same thing happen at stock speeds?
Using windows 7, 64 bit, linx worked perfect on mine. Except I had to increase vcore 1 notch to be stable at max memory on mine (have 3x1gb at moment).
Using 32 bit linx, once I had prime small ffts/blend stable 12+ hrs, 32 linx was always stable at 100 runs. And a 10 run linx would get me within a notch or two of prime 12 hrs stable.
Using 64 bit, looks like it may be other way around, once I get linx stable, prime may already be stable (vcore wise anyways). Dualist always said 64 bit is much harsher test, seems that is true. At 4.2 stable settings (linx 32 100 run stable and prime small ffts and blend 12+hrs stable), linx 64 (max memory) rebooted on 6 pass, tried again rebooted on 2nd pass. Increased vcore 1 notch, made it 10 runs.
Seems to work now for me, too.
Good work, thanks!
With my new CPU, the latest LinX works a treat.
http://database.he-computer.de/Bilde...23x_4.4Ghz.jpg
And no I won't run higher memsize at that speed ;) I can run 1Gb but that's about it.. any higher and I'd have to increase Vcore, which makes no sense because prime, games and esp. BOINC is running perfectly stable. So at this point, I would just add unneccesary heat.
Thank you guys once again for testing! Seems like LinX is so far the only Linpack app capable of loading all cores on Core i7 CPUs. :cool: :up:
http://database.he-computer.de/Bilder/temp/linxb.jpg
I guess it's stable :ROTF:
Max mem run on a 12GB system, used 2x 5270mb and loaded the CPU 100% as you can see. Even though its an older version, which one it is I can't recall (pre-5.5.0 tho)
No man, thank you. :up:This is the perfect app for people who need a quick stability test and the way you set it up is imo perfect.Quote:
Originally Posted by Dua|ist
Cheers.
Erm, 0.5.5.2 with HT on doesn't seem to go beyond 51% on my rig.Quote:
Originally Posted by Dua|ist
http://i173.photobucket.com/albums/w...58GA-UD4P_.png
Erm, Number of threads is set to 8 in Settings?Quote:
Originally Posted by MacClipper
That's funny, it works great for me.Quote:
Originally Posted by MacClipper
Hi guys. New to running this app, before I ran Intel Burn Test.
When running this, how much memory should I choose and how many loops?
I'm running a 12 gig system.
Thanks in advance.
The more memory to use is better to determine if your system is stable.
20 runs is OK for initial stability check.
If the system is unstable it will crash after about 1-2 runs, at least for me.
Almost stable will probably get an error (won't crash) after 5-6 runs.
Oops, thanks for that pointer! Had been swapping mobos around the last few days and forgot about that. :)Quote:
Originally Posted by Dua|ist
Hey Dua|ist, is it alright if I put LinX into a regular .zip file and rehost it for some people to download? Full credit and links to this thread, of course!
But of course it is alright. :yepp:Quote:
Originally Posted by zlojack
Used it to clock my old AMD Athlon x2 4000+ 2,1ghz again and it found errors within 10-20 minutes, compared to Orthos where i have to do stability tests for hours.
Got it stable at 3,0ghz @ 1.41v running LinX 17 hours.
Very nice application and I am in love with it :) Keep up the good work!
Thanks :up:Quote:
Originally Posted by Dua|ist
Hey, I downloaded this http://rapidshare.com/files/169890378/LinX.7z how do I open a .7z file? Or is there some where else I can down load LinX. Also I've seen where people say you can't use intel burn test with HT on, but I was able to down load the program and save it to 2 different folders, then execute it from each folder, selecting option #2, by doing it this way it does stress all 8 at 100%. This method may work with LinX also????
The new linx stresses all 8 threads (HT on) at max load with one instance, which allows you to run at max memory, which is a more efficient stress test than running 2 instances at half max memory.
Get 7 zip, it is a free program, will unzip virtually anything.
http://www.7-zip.org/
Google .7z
gvansly1, the link you mentioned is pretty old. You should download the newer version (see 1st post for that). 7z archive can be opened with either 7-Zip archiver or with any recent version of WinRAR.Quote:
Originally Posted by gvansly1
I thought the newest was 0.5.5.2 which is posted later in the thread?Quote:
Originally Posted by Dua|ist
Yes, but the same link is in the 1st post too.
is there a way to run a problem size of 10000 but using the least amount of memory, as to only test the cpu itself. Like what prime95 does when you run small ftt's in which it doesn't use ram just stresses cpu? When i set the problem to 10000 the ram used is 775mbs
I'm afraid not. Linpack solves a system of linear equations (a matrix with dimensions Problem Size x Leading Dimensions, 10000 x 10008 in your case) where every operand requires a fixed amount of memory (8 bytes). 99% of memory consumed by Linpack is used just to store that matrix. So problem size and memory are bound together.Quote:
Originally Posted by yomny
Good news for you is that Linpack is pretty light on memory stressing. Minor memory instabilities usually don't cause errors in Linpack.
No, that should be impossible on principle. Higher problem size means higher ram requirements, because linpack can only run its tests in system memory.
Edit: NVM.. more technical explanation above ^^
is not really a draw back , the applications runs pretty good and it is way faster than any other program in detecting errors, just wondering though since i often test the ram or NB stability (not OC'ing the cpu) then i run a test stressing the cpu only to see if its ok. But since since linx is so quick at detecting errors it makes up for it.
so, whats the idea behind using a big amount of memory during linx/linpack tests? if memory is not stressed too much and therefor linpack does not tell us that much on memory instabilities, wouldn't it be better to focus mainly on testing cpu stability and use as little memory as possible?Quote:
Originally Posted by Dua|ist
i have to run memtest anyway to verify memory stability (or if someone prefers online testing: occt or prime)!
That's yet another Linpack peculiarity. The more memory it consumes, the harsher it stresses the CPU. This is because Linpack seems to have some sort of different "phases" during each run, where the most stressful one is in the very middle, while there are also some time-fixed phases when it does almost nothing, judging by temps: at least two, in the beginning and at the end of each test run (my guess is they're caused by memory load/save operations with huge amounts of data; in the middle mostly cache is accessed). With higher problem sizes/memory amounts that "real stress" phase takes significantly more time, at least percent-wise.Quote:
Originally Posted by fgw
At low problem sizes there's very little continuous load, but even then Linpack does detect instability, it just needs much more time for that (the chance of getting a BSOD is also lower though).
Dualist explained why need for increased memory, but just to give a real world example on difference of testing memory at different sizes.
I need 1.41vcore bios setting (LLC on) for 4.2ghz prime stable 12+hrs (small and blend). To get linpack 64bit run of 20 stable at 2200 mem (problem size 17000) or larger i need to increase vcore 1 notch higher. I am then also stable at 60 runs, and still stable using more memory/higher problem size. But if I use only 1000 mem (11500 problem size) I can drop vcore ~3 notches below stable and make it 20 runs no problem, though would fail eventually I assume. If using less than 1000 mem, I can drop vcore even lower 4-5 notches below prime stable and still make a 20 run. That is using linpack 64 bit. Using 32 bit, the same is true except, I might need an extra notch of vcore to be prime stable after getting linpack32 to run 20 stable.
Using linpack 64 bit, from now on a 20-30 run linpack at 2200 mem and higher, I will assume is prime 12 hrs stable (cpu wise, it works on all my stable points). I can quickly get all my stable points using that short test, then run a final confirmatory test with 12hr prime (which also checks other issues other than cpu).
ok folks, i see:
so its always a good idea to run this test on max mem to get worst case scenario!
but this is still stressing the cpu! to get overall system stability there is the need of running some other tests too, like prime, occt, orthos and of course memtest to nail down memory issues!
guess i got i now.
regarding the memory load/unload at the beginning and end of each pass. always wondered why linx/linpack had this drop in cpuload and of course core temps at the beginning of each pass, compared to prime or even coredamage where load socks up to 100% and does never get down until the test is stopped.
that makes sense now ...
You said it wouldn't catch on :rofl: Welcome to the Darkside :up:Quote:
Originally Posted by ReverendMaynard
Im running problem size of 10000 and adding one notch up in vcore gets me through one or two more problems solved then fails. Is it going to stop.. or the more problems i run the m ore vcore is going to need?
If i underclock my cpu and only run a high FSB, as to test chipset and memory stability, can i still run linX and get a good indication, or does linx only test CPU
My experience on my I7 and previous cpus E8600/E8400, once I get to about 2300mem or 17000 problem size, I quit needing more vcore as I go up further in problem size to get it stable, but others may vary.Quote:
Originally Posted by yomny
But running mem of 1000 (or equiv problem size of ~10000) I need a couple notches more vcore going up to 2200 mem. In fact now, I only test at problem size around 17000, it is faster at crashing unstable OC's.
On core i7, once I am linpack stable, I am prime blend stable without adjusting anything else, but it has integrated mem controller....and of course I am running my mem at stock...so it is no worry.
I you are using FSB, ie core duo/quad then you may or may not be stable with mem/FSB,NB if pass linx. Personally I would run prime or OCCT once I got cpu stable, to double check rest.
yeah makes sense, i run prime blend to test some NB, mem stability and ususally after test two or so it detects errors.. but yeah i managed to pass 10 problems of 10000 with no errors so i guess that equals to like 12 hours of prime small ftts. as before i ran small ftts in prime for hours with no errors and 3 passes of 10000 got me errors. Im guessing if i pass 10 without problems im good.
I'm an old timer with overclocking, all this new software is blowing my mind, so quick question, if I can pass 20 runs @ 10K and 20 runs @ 9K back to back, does it mean my system is fairly stable?
I realize this only tests the CPU, and not memory, so I'll use P95 for that, but from a CPU aspect... it's okay?
Thanks!
yes that means that is stable. I was able to run 10 passes of 10k stable and this translates to almost 10 hours or so stable in prime95 small ftts.
LinX 0.5.6 is here:
- interface fixes and enhancements, Linpack mode (x32/x64) and number of threads are now displayed in statusbar
- CPU name is now displayed in statusbar
- Linpack mode is now mentioned in text log too
Maybe someday we'll see clocks right after that CPU name... ;)
There's also a mini-mode now. I have no clue who might want to use it, but it looks nice with glass in Vista and Win7. If you're interested look in the ini for EnableMiniMode, once enabled you'll be able to switch between 2 modes via Settings menu and right-mouse button menu in full and mini-mode respectively. And note that it might be buggy like every new thing I do. :)
Attachment 93713 (looks so very cyan on Win7 :) )
Well, 20 runs are usually a good enough indication of stability, but you should consider running, say, 50 runs and with more memory to be completely sure that it's stable. Linpack is just like Prime, the more the better.Quote:
Originally Posted by GRAFiZ
Works great!
Quote:
Originally Posted by yomny
Awesome! Thanks for the help! :up:Quote:
Originally Posted by Dua|ist
Also, such a fantastic utility, really well done, thank you!
another LinX run bites the dust... this one is only 20 runs instead of my normal 25.
What about this - >
http://img25.imageshack.us/my.php?im...tableliez0.jpg
Stable or not?
Quote:
Originally Posted by spoof
With linx 32 bit, once I am prime stable, I have been linx stable. With linx 64 bit, as you are using, it is a little harsher than prime on mine, I had to raise vcore 2 notches to be linx 64 bit stable...(when using large problems sizes which stress cpu the most, like you are doing.)
What do you guys think about a spartan interface with all checkboxes moved to the Settings window like this:
Attachment 94644
I just have a feeling that nobody uses them anyway, or at least not too frequently. Not sure only about the x64 option, but again on 32-bit systems it's absolutely useless, while on 64-bit systems, which usually have 4+ GB of RAM, who'd want to run 32-bit Linpack with its memory limitations?
Or simply leave it all the way it is now? :shrug:
I use the "stop on error" switch a lot and also the # of threads.. when I am testing the GFX card simultaneously to get an idea of the system's total heat production for instance, I need to leave 1 core/thread free or LinX will grab it all :D