LinX - A simple Linpack interface

[slim142]

Is there something in the 0.5.x series that doesn't suit you? Except the version number?
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.

No bro! I love this program!
and I also love to see updates

[davidk21770]

Is there something in the 0.5.x series that doesn't suit you? Except the version number?
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.

I find the prog REALLY usable in it's current form.
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.

[Dua|ist]

I find the prog REALLY usable in it's current form.
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. I'll see what i can do about this.

[Dua|ist]

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:

Looks much better to me than previous one, but I need to know your opinion too.

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.

[burebista]

Thanks man. Looks better and better. Keep up the good work.

[davidk21770]

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.

[Dua|ist]

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.

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).

[davidk21770]

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.

What about using lower 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 .

[Cooperdale]

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?

[rge]

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.

[gurusan]

Thanks so much for this. Very easy. I this alongside orthos to fully stress the cores.....thanks again!

[Cooperdale]

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 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?

[rge]

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?

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.

[btdvox]

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.

Question is why wouldnt you use HT? it shows a 20% performance increase in most apps!

[rge]

Question is why wouldnt you use HT? it shows a 20% performance increase in most apps!

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.

[Dua|ist]

gurusan, you're welcome.

Well, thanks to rge's detailed explanation 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.

[rge]

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)

[Dua|ist]

rge, you're great (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 ). 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).

[rge]

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.

[Betroz]

Guys is this stable enough?

[Dua|ist]

rge, thanks. Informative as always. Very useful info for Core i7 owners.

Guys is this stable enough?

21 hours of 7GB testing in x64 mode! Seems stable enough for me.

[koda]

Well, i love your tool ... i think i'm pretty stable here :



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.

[Betroz]

koda, 1 hour and 13 minutes isn't hardcore stable enough

[celemine1Gig]

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.
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!

[koda]

koda, 1 hour and 13 minutes isn't hardcore stable enough

For sure, but seems quite stable for this FSB ... and reveals cpu & mobo 's power