Printable View
Would it be possible to make it flash Green to White to Green to White... when running? Green to Lighter Green is hard to spot when glancing up. And maybe Red to White to Red... when an error occurs?Quote:
Originally Posted by Dua|ist
Thanks for the GUI, Dual', it's been essential for getting my Q6600 Folding@Home stable. :up: :clap:
Nooooo!
Please, if more modifications are going to be done to the loading bar, stick to blue or green, FORGET THE RED!!!!
just did a quick test of the new 0.49 version.Quote:
Originally Posted by Dua|ist
despite the test completing successfully(numbers matching), LinX says it stopped because of an error when using the "Play sound on error" option.
if i don't use the audio option, it tells me "Linpack has terminated unexpectedly..."
Sweet interface. Good job Dullist
Pyr0 and those with the same problem, please try the attached exe from this post. Just overwrite the exe in LinX directory.
Once again I proved to be a lame programmer as I'm still unsure what causes this (can't reproduce this on my rig). :(
thanks Dua|ist, this version seems to work :up: :)
i ran a quick 128mb, 3 loop test with and without the sound notification option and both say "Finished without errors in 9 seconds"
[edit] i'm testing in xp x64 atm. if that makes any diff :shrug:
Thanks for this program. I am, however, unsure about how to use it. You dial in a problem size, but what does this represent? And how long should you leave this program running to ensure maximum stability? So far, it has made my rig reboot twice so I am typing this message in a hurry :-)
You may enter Problem Size or the amount of memory you wish to use (they correspond to each other). I'd start with something like 5000-6000 problem sizes (20-30 runs). For full stability checking use the Max mem option or just anything above 10000 problem size for 25-100 times (the more the better :)).Quote:
Originally Posted by DildePer
Thank you very much for the quick answer. Even when using 25 runs of 5000 sizes it still reboots my comp, where I could run ORTHOS for about an hour!
Although it seems that Orthos generates more heat? Was getting 48-50 load temps with ORTHOS and 44-45 with LinX?
Very effective, thanks again!
As you've probably read in post's title this new LinX has AMD support (it's so pretty stupid to say that in Intel thread :D).
But, it was done not by me but by forums.overclockers.ru member Right, so all credit goes to him. :clap:
I just added this to LinX with his permission and wish to thank him for that once more. Intel users, there's no performance difference from previous versions, so don't worry. If you still want to stick with Intel-only files you can use those from previous versions or download them here (but there's really no difference in performance/error finding efficiency as well as in heat generation :)).
Other changes include slightly redesigned UI and the ability to resize program window horizontally in Detailed log mode. Bug reported by Pyro (thanks to him!) was also fixed.
Attachment 86591
Download link : LinX 0.4.9.1
It's kinda weird you're getting lower temps with Linpack than with Orthos. This is normally just the opposite. And BTW have you managed to make it pass LinX or it still reboots?Quote:
Originally Posted by DildePer
Dualist
Why did you remove the blue frames from the bottom? (where it says 13/15, Maximum Performance, Minimal Time etc).
Not that I dont like it, but was that an issue or personal preference?
Also, nice job for this one. You are using 1.7 IBT now I suppose ;)
One bug I found, not serious. When Im in short log mode, I try to increase the size of the window horizontally, the left column makes the window move, not increase the size and the right column doesnt do anything in terms of increasing the size.
The frames are gone, there's a statusbar instead. I thought it'd be a more correct way of displaying that info in a statusbar rather than in 3 separate Edit boxes. :)Quote:
Originally Posted by slim142
The files do have something in common with IBT's new ones as Right reported but they're still different (no plagiarism here).
The "bug" you found belongs to Delphi and I'm afraid I can't fix it. (You'll have to get used to it ;))
Is ok, I dont mind if there are frames or notQuote:
Originally Posted by Dua|ist
About the bug, well I can live with it, is not that it affects the function of the program :up:
Again, thanks for the great interface, really like it.
But on the most recent version, I cant see all of it. It is stretched out as far as will go (enlarging box with mouse), but I cant see residual norm. I just noticed this on more recent versions. Maybe because I am using 120 dpi?, I am at 1600x1200 if that helps. Any chance of making it so I can stretch it bigger to see residual norms.
Who'd have thought that making a window resizeable will cause such problems?.. Here, please try this one, it's all I managed to do about the dpi stuff. If something's still wrong, please let me know.Quote:
Originally Posted by rge
Thanks that is much better!
Awesome! Thanks a lot for this great interface, I like it much better than the other one. =]
:rocker:
Upgrade over and I'm back with a new version: LinX 0.5.0 :)
Attachment 87082
Changes:
- added Everest support. LinX can now display CPU temperature from Everest. The displayed temperature is the temperature of the hottest core; if a CPU doesn't have core sensors then a temperature from an external sensor is displayed. For this to work you'll need to have Everest running in background with "Enable shared memory" option checked (in Everest "File -> Preferences -> External Applications"; you might also want to set update frequency to 1 sec for external applications and adjust Tjmax value)
- added an option to stop testing if CPU temp exceeds the desired temp (see above)
- LinX now correctly reads (well, actually skips ;) ) values from damaged lininput file
- and saves most of its settings on exit
Dual, random question but what theme are you using on your Windows install? I liked the blue version you used previously, but this new black version looks amazing!
Thank you for the new version of LinX. This tool has invaluable with my overclocking recently! Also good for draining laptop batteries for a full discharge! :D
Dua|ist
Good work, mate:) Russian programmers rock :)
Thank you for your warm words. If the monitoring will work ok, I'll try to implement some temperature/fan/voltage graphs later (optional, of course).
It's the Watercolor Emico series, all of them can be found on this page (search the gallery there a little): http://gelosea.deviantart.com/.Quote:
Originally Posted by kup
After playing with new rig I decided to make some Linpack error interpretations, which might be helpful for those unfamiliar with Linpack. Note that these are based upon my observations and can't be 100% true. You are welcome to share your experience.
Basically if you get an error you would have x same (correct) results and 1 different (an error):
- if the incorrect result differs slightly from the rest (numbers very close, same powers in Residual & Residual (norm)) it is most likely that there's not enough vcore. In this case only a small vcore bump is usually needed to stabilize the system (alternatively, Vtt & GTL tweaking can sometimes fix this too)
- if the wrong result differs much from the others (different power or even positive power in Residual or Residual (norm)) it might be 1) insufficient vcore (the error would happen at the very first runs then) or 2) some memory / NB instability (when it worked for say 10 minutes ok and then produced a different result)
Now more serious errors:
- a BSOD during testing (at the very first runs) is often caused by too low vcore
- if the system hangs and remains hung it is almost 100% not a CPU but memory or possibly NB issue
- if the system reboots (with no hang prior to reboot and no BSOD) - a CPU issue, but not vcore related (insufficient PLL or Vtt I guess)
- if it hangs for a short while and then BSODs - once again NB or memory problem (but might be wrong Vtt / GTL setting as well)
- if it hangs and then just reboots - wrong Vtt (too low or too high) or GTL settings
P.S. Despite being probably the most stressful stability checking program for CPU Linpack is not that good at finding memory errors, so checking memory with tools like Memtest, OCCT & Prime Blend will be a better idea.
P.P.S. Please correct me if I'm wrong. :)
Another update for LinX.
Good news is:
- LinX can now create, display and save as PNG graphs for CPU temp, CPU fan speed, vcore and +12V voltage based on Everest data. Graphs are shown in separate windows, can be resized and made semi-transparent
- the green status field now flashes in all time modes (elapsed, remaining & finish time)
- you can now make screenshot of LinX's window by pressing the F5 key. The screenshot will be saved as LinX.png in program's folder. Pressing F5 in graph windows will save the corresponding graph (not the whole window) as PNG image
http://img227.imageshack.us/img227/7...aphsta1.th.jpghttp://img227.imageshack.us/images/thpix.gif
Bad news is the exe (compressed and archived) no more fits in 200KB, so only Rapidshare from now on. :(
Link : LinX 0.5.1
many thanks. really useful program. :up:
Just in case someone's having problems with graphs & temperatures taken from Everest. This update will most likely fix them. Thanks go to forums.overclockers.ru members for notifiying me of these issues. Link: LinX 0.5.1.4
Your bug reports and suggestions are also always welcome. :)
Thanks a lot for the interface man....I like it a lot and it helped me to finally (I think) get my system stable....thanks for the tips on the errors too.
Don't really know if a fix can be done as you probably don't have the operating system. I was lucky enough to have a Windows 7 disk sent to me. Running LinX there are 2 issues. The memory defaults to 1024Mb and the number of runs to 3. Selecting a different value in the drop-down lists will not change these two values.
Hey thanks for this, i love the interface!
Quote:
Originally Posted by Dua|ist
For users with 4GB or higher ram, this or memtest is the only option since orthos and prime is still limited to 32bit memory addressing.
Demo, thanks. I'm glad you like LinX. :)
Thanks for that. Once I finally managed (or so I hope :rolleyes:) to fix most Vista-related issues there's yet another new OS. :) It's so irritating when something works flawlessly in XP but doesn't in Vista. Or Windows 7.Quote:
Originally Posted by Praz
I'm currently making another version which will have a good old ini-file to store settings in, so editing it might be a temporary workaround for you.
Sorry for a probably stupid question, but have you tried keying the numbers in instead of selecting from drop-down menu? What happens then? This might help me to find and fix that bug. Thanks in advance.
Just tried LinX in Windows 7. Keying in the numbers for mem ammount and number of loops works :up:
also tried running it as an admin and tried compatibility mode for vista rtm, but neither method fixed the drop down selection
Awesome work here Dua|list :up:
ooh, linpack for both Intel and AMD! Can't believe I haven't seen this before, great!
edit - it's been running for almost 4 minutes now and there's nothing in the display yet. Is it just because of the slow CPU or is stuff supposed to show up by now? It does load at 100% so it certainly is working.. On something.. wherever.. :p
edit2 - i realised it's because i selected 'max' in the memory section. I don't have the patience for that, ha..
Thanks, this sounds reassuring. At least this way it works. Once I get Win7, I'll try to fix it.Quote:
Originally Posted by Pyr0
Zucker2k, you're welcome.
High problem sizes take up to a couple of minutes to calculate on my rig in sig. But 10000 and above is usually good enough for stability testing.Quote:
Originally Posted by bowman
P.S. An AMD user in Intel thread, so unusual ;)
Well I have AMD but I'm not hysterical :p: Besides, the Bloomfield 920 is on its way so I wander in all the areas nowadays. Want to compare the Bloomfield at 4GHz, wondering what sort of GFLOPS that one will do in Linpack :DQuote:
Originally Posted by Dua|ist
The testing of an ES 965 by DeDaL has shown that Bloomfield performance in Linpack (or Linpack performance on Bloomfield?) was very inconsistent due to OS (or Linpack) switching the load from one core to another, including the virtual SMT cores. This is hopefully fixed in new Linpack 10.1, which I'll include in the newer version of LinX. Should you encounter something like that or just want to tell us about Bloomfield performance, you can share your results here. :)Quote:
Originally Posted by bowman
Same here. Manually inputting the values works fine.Quote:
Originally Posted by Pyr0
Like it ? Who says i like it ???Quote:
Originally Posted by Dua|ist
I LOVE IT !!!
BTW, Whats the recommended problem size if i want to test the CPU only for stability ?
I got 24.8GFLOPS which is slightly more than a Q6600, thought something was weird. I guess that explains it!Quote:
Originally Posted by Dua|ist
Demo: Linpack does test only CPU anyway. It stresses memory and NB only a little. And the effectiveness of CPU testing depends only on Problem Size/Amount of memory. The more the better error finding capability, higher temps and higher flops. I'd start with something like 5-7K for initial OC (to avoid fatal errors like hangs, BSODs, etc) and for actual stability testing anything above 10000 (~1GB) is good. But the more the better.
bowman: Maybe it does. Check this thread out in a couple of days, I'll probably upload a new version by that time with new Linpack 10.1, which was released by Intel shortly after Bloomfields, so it should fix this issue I guess.
Oh i thought it was a combined memory and CPU test, so anyway ill use max mem always.
Linpack isn't that bad at memory testing, it will find most memory errors, it'll just need way more time for that when compared to Orthos/Prime and especially Memtest.Quote:
Originally Posted by Demo
Great Job, Nice.
Works perfect for me, OC stable weeeeee!!
Thanks.
Dualist, do you think you can give us an ETA for LinX 1.0? :D
Is there something in the 0.5.x series that doesn't suit you? Except the version number? ;)Quote:
Originally Posted by slim142
Seriously, I don't know. There are still many ideas to implement and there's a lot to be fixed, made more fool-proof, stable, etc.
But sooner or later... we'll eventually come to 1.0, just a matter of time. :)
Here it is finally: LinX 0.5.2
List of changes:
- Linpack executables updated to version 10.1 (for Intel CPUs only; for AMD users there's still Linpack 10.0 with no CPU restrictions, just rename and replace the linpack_xeon32.exe_amd and linpack_xeon64.exe_amd). Happy Corei7 owners might want to try this one and report their performance
- added Speedfan support. LinX can now import such data as CPU temperature, vcore, fan speed and +12V voltage from Speedfan. Fill in the values in the Speedfan.ini file in LinX' folder for this to work (see readme for more details)
- some interface enhancements/fixes
- consumed memory calculation is slightly improved
- LinX now uses ini-files (LinX.ini and Speedfan.ini) to store its settings in. Those who like tweaking things may now override default values for the amount of memory to leave for OS in Max mem mode and maximum Problem size for Linpack32
- The Leading Dimensions value is now adjusted for maximum performance instead of being equal to Problem Size value. This can be disabled via the UseOptimizedLeadingDimensions=0 key in the LinX.ini
Attachment 89490
P.S. Ever tried disabling a page file in Vista with 2GB of RAM? It's a bad idea, trust me. Spent over 2 hours trying to determine why LinX no more works with high Problem Sizes because of that. :D
Still not Nehalem/HT compatible.
http://www.isarapix.org/pix81/1227451535.png
Also temps are 60-65C whereas actual 100% stress would bring it up to nearly 90C (Prime95 and WCG do this)
Then it means we are to expect another Linpack update soon. I wonder what would happen if you disable SMT?Quote:
Originally Posted by bowman
No bro! I love this program! :DQuote:
Originally Posted by Dua|ist
and I also love to see updates :D
I find the prog REALLY usable in it's current form.Quote:
Originally Posted by Dua|ist
I'd just like to be able to get max memory without having to choose it from a dropdown menu every time. Say a checkbox that's remembered so that it sets the memory to max automatically when it loads.
I like the idea, thanks. :yepp: I'll see what i can do about this.Quote:
Originally Posted by davidk21770
Ok, good news for all Linpack fans and advocates of true stability :) : LinX 0.5.3 with some new cool features:
- the temporary log file is no more created during testing, expect a little GFlops increase
- The v10.1 Linpack executables are now AMD compatible too. The older v10.0 are still inside the archive, just in case (rename and replace the files ending with "_v100")
- log interface redesigned
- All mem ("All") button added as requested. When in pressed state LinX will always use the current maximum available memory
- localization support via the "local.lng" file added
This is how the interface looks now:
http://img509.imageshack.us/img509/3179/linxef6.th.png
Looks much better to me than previous one, but I need to know your opinion too. :yepp:
Localization support was done mainly to ease the development of 2 (english and russian) versions of LinX. But since XS is quite international maybe someone would like to translate it to some other language. ;) The "local.lng" contains all original english strings.
P.S. The 10.1 version of 32-bit Linpack doesn't seem to be working with Problem sizes higher than 15080 (~1750 MiB), the 10.0 has the upper limit of 16120 (~2000 MiB). Both x64 versions don't have this restriction.
Thanks man. Looks better and better. Keep up the good work. :up:
Yep, thanks for the improvement (and the ability to remember to use max memory ;)).
But I miss the log file. When I spontaneously reboot, I edit it to see how far it got -- for relative performance comparisons when I'm just starting to tune-in and am still very unstable.
But there is no log file anymore, since everything is being written to memory instead of disk to improve performance. I thought without that log it would be only better... Seems that I was wrong. :confused:Quote:
Originally Posted by davidk21770
What about using lower problem size numbers for initial tuning? From my experience they often cause just errors while larger values at same settings cause reboots/BSODs.
But I'll see if I can somehow make the output to memory optional (via the ini-file switch maybe).
You're right that your new approach is much cleaner. You're writing so little to the disk that I wouldn't expect it to make a significant difference in execution time -- but a switch to enable it sounds like a great feature ;).Quote:
Originally Posted by Dua|ist
Hey guys, does anybody else have my problem? When I run LinX on my new core i7 965, the cpu load only gets to 50% and temperatures run lower than Prime95.
It seems to be much less stressful than Prime95 on Nehalem cpus, while it was more stressful than Prime on Core 2 cpus. Can anyone confirm this?
Linpack is not multi-threaded. You can turn hyperthreading off in bios and then it will run 100% on all 4 cores. With enabled load will only be 50%, and will bounce back and forth between two threads on each core (I have loadtesting program courtesy of unclewebb that shows this).
Perhaps later releases of linpack will become multithreaded. Until then you can run prime in background to fully load all 8 threads, and cause full vdroop so you can check stability, and then run linx at same time. This is no harder on your cpu than running either prime full load itself, or running linx itself with hyperthreading off. It takes linx longer to run, but that way you still get increased efficiency of linx.
For example at 2 notches below stable, prime v25.8 latest, takes about 2-3 hours to error or reboot. With prime running, then running linx, linx will error within 3-5 runs, much faster. But like you have noticed, since linx/linpack will only load 50%, it does not cause full vdroop, and hence I can run linx all day by itself at 2 notches below stable because vcore is much higher from lack of vdroop of full load.
Hopefully intel will come out with multithreaded version as some point.
Thanks so much for this. Very easy. I this alongside orthos to fully stress the cores.....thanks again!
Thanks for the detailed explanation! I tried disabling multithreading and passed the Linpack test with full load. Does this mean I'm stable, or is the Prime+LinX method better?Quote:
Originally Posted by rge
With hyperthreading enabled you will need more vcore to be stable than with it off...so if want to run with hyperthreading enabled, need to run some other stress program to maintain 100% load and max vdroop like prime, then linx if you want to use shorter runs of linx.Quote:
Originally Posted by Cooperdale
Question is why wouldnt you use HT? it shows a 20% performance increase in most apps!Quote:
Originally Posted by rge
I do use hyperthreading. I am not really sure why you are implying I dont, unless you only read the last post without reading any others.Quote:
Originally Posted by btdvox
gurusan, you're welcome.
Well, thanks to rge's detailed explanation :up: all questions are already answered... :) Yes, current Linpack releases don't support Hyper-Threading, at least on Nehalem CPUs (PIVs with HT are ok AFAIK). But the fact that the executables in v10.1 started requiring external libraries makes me hope it is some sort of temporary move, and we'll get a newer version (hopefully with i7 support) soon.
Actually Linx works with core i7, just have to run two instances with each HALF max memory. On mine max memory was 2000 so ran each with 1000. Not only do you get full vdroop, full 100% load, but a single pass gives you two runs, twice the speed. Each program will document two runs, after only 1 pass. But need to test how effective this is vs 1 with max memory. May be better to run one near max, other small size but 200 runs so small size keeps running until large size is finished (to achieve full load)
rge, you're great :clap: (as usual :)). I would've never thought of running 2 instances of Linpack simultaneously. If this method causes 100% load on all cores then a limitation of Linpack is obvious: it doesn't support more than 4 cores (threads) I guess. With SMT off, it tests all 4 cores but the load is far from maximum as half of FUs are idling. With SMT on, it (or rather the OS) keeps reassigning the load between all 8 visible "cores" - once again far from 100% load.
And it seems to me that using half of the available mem for each instance is a better idea, but you definitely know better, which method is preferable. ;)
P.S. The two runs documented after one pass in each window don't look good to me (I must admit I'm surprised that all this works at all :rolleyes: ). rge, couldn't you sometime try the most recent 0.5.3 version, just tried running two instances of it, results aren't being doubled in different windows (my english is far from perfect here but I hope you'll understand).
found the most recent and used it.... results are not being doubled on this one.
It works fine on corei7 running two instances (pic1, 100% load via unclewebbs loadtester), gives the same residual norm as running one instance (pic 2, 50%). Running 2 instances may not work well on cpus other than core i7's with hyperthreading, but works great with these.
The Gflops will be halved and time doubled with 2 instances, but that is to be expected. If running for Gflops, run one, but if stress testing run two.
Pic 1 is using mem 1000mb each, running 2 instances, each pass gives 1 result, this is 2nd pass finished.
Pic 2 is using mem 1000mb x1 so you can see residual error is same, but only 50% load.
Pic 3 is using mem near max 1700 on one, mem 512 on another (max free was 2300 so still not exceeding max free), this may work the best. Kind of neat as you get a fast test and slow more effective test all at same time. The residual norms for 1700 run should all be same, and 512 all same, but of course 512 residual norms will be different than 1700 residual norms as they should be since different problem size. For 20 run 1700mb would need to run ~200 runs of 512, since 512 mem runs much faster...but can see still get 100% load, 100% Vdroop, and near max mem testing effectiveness. Just have to make sure you dont exceed free memory.
Guys is this stable enough? :D
http://bildr.no/thumb/302195.jpeg
rge, thanks. Informative as always. :up: Very useful info for Core i7 owners.
:eek: :shocked: 21 hours of 7GB testing in x64 mode! Seems stable enough for me.:DQuote:
Originally Posted by Betroz
Well, i love your tool ... i think i'm pretty stable here :
http://img177.imageshack.us/img177/6...packur7.th.jpg
I would like to suggest a feature (if you could include it).
It would be great to be able to set an affinity on each core (then we must launch one process on each core) or to show which core produce an error (dunno if could know it).
This feature could really help us for tweaking GTL Ref (without using SP2004 as i had to do) and then to find the best settings.
koda, 1 hour and 13 minutes isn't hardcore stable enough ;)
Hehe, now that you say it. I had read his posting a few hours ago, but didn't have the time to take a look at the pic. I assumed that it was in excess of 20 hours of stability testing, like some other guys here. :DQuote:
Originally Posted by Betroz
I agree 100%, that 1 h of stability testing is nothing.
And BTW, the program really is great! I used it the last weeks to test stability for a buddy's Xeon X3210 based system. Helps to find stable overclocking points way faster than prime alone. I love this GUI for Linpack. Very well done and good support through updates, too!
For sure, but seems quite stable for this FSB ... and reveals cpu & mobo 's power ;)Quote:
Originally Posted by Betroz
Thank you guys for your support.
Bad news is, I don't have enough time right now to continue coding (it's really getting hard here in my university at the end of term). :(
But good news is that I've found a way to set the number of threads for Linpack to use. That's something like what koda has suggested. :) I'm not sure if I can make the affinity to be set from within LinX, but right now it is possible to make Linpack use less threads than the number of cores of a CPU (running it in just one thread works well on my rig). When running only on one core the affinity can be set from within Task Manager I think.
Higher values can be set too, but on my dual-core E8500 I haven't found any difference in performance or whatever with number of threads set to anything higher than 2, so not sure about this. It will be interesting to try and set this value to 8 for a Core i7 system though. It just can't be that easy to force Linpack load all 8 cores in one instance, but who knows? Maybe it is. ;) I'll upload this version as soon as I have some time to finish it and "polish" some things. You'll have to be patient. :)
You do the great work, Alex :up:
Keep doing your job and good luck with your term exams ;)
You're great mate !
Well, i'm not sure you can set affinity on each core but :
If you click on start with an option limited to one thread ... we will have a new process ... something like linpack32_xeon32.exe (can't remember the exact name) ... then just set affinity to it.
Then do the same again for a second LinX with his linpack process and affinity to another core ... and so on ;)
When one crash ... just look each core in task manager ;)
Take your time ... you tool is great ... we will be patient !
Quote:
Originally Posted by Dua|ist
Thank you all for your patience, here it is: LinX 0.5.4
Changes in this version:
- HyperThreading support added. This is done not in a best way probably, as two instances of Linpack are launched at the same time (their performance is then summed up). This was tested on a P4 and an Atom and worked ok in both cases
- Thread control added. You can now set the number of threads Linpack will create and thus control the number of physical cores that will be stressed. This setting is located in the Settings window (who'd have thought? :D )
- Settings window with all existing and a couple of new settings added. No need to edit the ini-file manually now
- Main menu redesigned
- Lots of minor bugs found and fixed (and who knows how much new are added? :rolleyes: )
- Performance optimized a little bit more
- Graphs have now customizable top and bottom limits
- And changed the icon a bit :cool:
Your comments are welcome as usual. I'm eager to hear how it performs on Nehalems now. :)
P.S. Screenshots and updated first post tomorrow, no time right now.
Dualist, could not get to work on my core i7. Default was set to 4 threads and HT box was checked. When ran, realtemp, loadtester, speedfan all say no load or 1% load. Checked taksmanager and says cpu idle 99%. I changed to 8 threads, and same. see pic. Any ideas? What is weird is that with it running, system seem very slow...like it is running...something is weird.
Great Work mate :up: it became one of my preferred tools for testing stabilityQuote:
Originally Posted by Dua|ist
Cheers
Sergio
Well, I haven't tested it with Core i7, and this was somehow expected. If you uncheck the HT box, it'll (it should) run just like before, only on 4 cores.Quote:
Originally Posted by rge
Could you please check whether 2 linpack_xeon32.exe processes are running with HT box checked or not? But if it says idle 99% - obviously nothing is running at all. :(
Edit: I'm an idiot. :) We're trying to start two linpacks at the same time, each with maximum memory. That must be the problem. If it is (I sincerely hope so) then with lower memory (say, half from max) values it should work.
:eek: I was the idiot for running it that way...that would explain the BSOD/linx crashing when I clicked on it first time.:rofl:Quote:
Originally Posted by Dua|ist
Yep, works fine using 1/2 memory, load is 99.9%:up:
this version will not run the 64bit test for me even when I set x64=1 in the ini file. 5.3 worked fine.Quote:
Originally Posted by Dua|ist
rge, thanks for testing the HT stuff. Here's the updated version, which should take the HT checkbox into account and use only half of all available memory as maximum with it checked.
I also fixed a bug when 0.5.4 wouldn't run on a machine with 8GB+ RAM.
LinX 0.5.4.1
Uhm, I don't remember myself changing anything x64-related. Could you please provide more details? The x64 box is disabled?Quote:
Originally Posted by safan80
Thank's for update.
Btw,any another link,as many of us are not Premium user on RS.
Uncleweb and me using fileden.com with direct download.
I'm not a premium member of RS, I only had to wait 27 secs to download it. What's the beef with having to wait only a few seconds? :down:Quote:
Originally Posted by stasio
the box is disabled in 5.4. and I can't get it to enable even when I change the ini.Quote:
Originally Posted by Dua|ist
downloading 5.4.1 now will update when it's done
works great now!!! thank you!
Thanks for that, I don't like Rapidshare either. Just registered at fileden, here's the direct link: LinX 0.5.4.1Quote:
Originally Posted by stasio
Thank's:clap:
Dualist, Im impressed :clap:
I will finally get to test my 4Gbs of RAM now that Im on Windows XP Pro x64
New one is working well on i7, using max memory sets it to one half each for 2 instances, and it max loads all 8 threads:up:
rge, that is simply great! So glad to hear that it WORKS! :D
Thanks, you can always share your results here. ;)Quote:
Originally Posted by slim142
I've encountered a problem with LinX 5.4.1 and the 25,000 test. whenever it's about to finish it's run it errors out right as it's about to finish the last run. I've had it at stock too. the amount of tests do not matter it's almost as if it has trouble unloading when it is done. here's example with just 3 tests.
edit: I hope somebody can repeat this or else it might be the bios I'm using.
I had the same problem with my setup, ran 199 out of 200 iterations and then suddenly stopped before the last one.Quote:
Originally Posted by safan80
http://img243.imageshack.us/img243/8721/oc38002lf4.jpg
Yep same here. Funny on short runs 3-5 runs all the way through...but on 25 run, it ran 24 than said unexpectedly stopped before getting to 25, always does it on last run on longer runs.
That's it, my noobness and no Nehalems around to test on. I think I know why this happens, but can't reproduce that on Atom.
I should have somehow said that HT support is... sort of beta. But since the version number is starting with 0 anyway, I hope you can forgive me that.
Here you go, LinX 0.5.4.2, hopefully fixed.
You do the great work, keep it up :up: :clap:
I just love LinX, itīs so easy to use :yepp:, great interface. :yepp:
Itīs my number one tool for check CPU stability, it stress the living daylight out of the my CPUs.
This :cool:Quote:
Originally Posted by Ghostleader
0542 fixed the stopping before last one on mine:up: