My current pair of 295 cards feels more like a gatling gun, as it just spits them out, of course no uploads...

---

CA HSR built a foundation, is laying Track!
PRR T1 Class 4-4-4-4 #5550 Loco, US's 1st HST

My current pair of 295 cards feels more like a gatling gun, as it just spits them out, of course no uploads...

You want to see mine with shorties, 4 min a WU X 9, just over 2 a min.

There are others that are even faster, its no wonder that the servers can't keep up in a shortie storm:-(

---

Kevin

For the first time I've managed to break 10k RAC. I'm loving it.

I just hoping I can get back to 30+k, but with the new credit system, I've kind of given up hope.

Can you elaborate?

Sorry it took me so long to back to this, but out JOB HUNTING!!!

I had just passed the 31k mark when the new credit policy went into effect. At approx. the same time we had a major outage at the lab. Since that time it has gone steadly down. I'm not really complaining, for the science is worth whatever I get. But it was just after an upgrade to an i7/950 and the credit were climbing like a rocket.

Just got home from work.

found this machine almost totally frozen, task manager was showing 100% processor usage, one core was showing almost 100% Kernel times. could not get into Seti, GPU temps showing low, 50C - 60C.

Ended up having to restart via big switch.

All 9 GPU tasks were showing very high elapsed times, up to about 6+ Hrs, first one finnished and uploaded onto my error page, the other 8 I aborted, computer is now running in HP mode, probably something to do with completion times jumping up to 6+ Hrs, (normal for regular WU is 20 min)

I am running v0.38 with 275.33

---

Kevin

From the Release Notes:

Newer (270+) drivers use more kernel RAM - you may run into memory problems,
especially on 256 MiB cards or when multithreading on Fermis or with a lot of
cards in one host.

I suggest your try only running two Wu's per GPU and see if that helps,

Claggy

From the Release Notes:

Newer (270+) drivers use more kernel RAM - you may run into memory problems,
especially on 256 MiB cards or when multithreading on Fermis or with a lot of
cards in one host.

I suggest your try only running two Wu's per GPU and see if that helps,

Claggy

Only got 4 Gig in here, MB was having problems running any more.

Have switched to 2 WU per card, will see how this runs.

Thank you

---

Kevin

I know that when the NVIDIA are flagged as (CUDA). I used Lunatics Windows Installer v0.38 on one of my machines just to see what would happen. Can someone tell me how to identify workunits that are using the ATI GPU or those that are using both ATI GPU and CPU? I don't think I have any of these type currently running but I can't be sure. wondering if I need to change settings but first need to know how to identify them when I get them.

---

ATI units will be listed as (ati13ati) or 14.

---

Count me a happy user of the new installer, though my circumstances differ from those suggested to fit most appropriate users.

I had been running Raistmer's ATI Astropulse ap, with all my CPU for that host dedicated to Einstein. In a (I hope not BOINC related) machine freeze early today, on reboot my entire Einstein work queue was lost to CPU error. By the time I attempted cleanup with a project detach/re-attach sequence, I'd already consumed my remaining 1 task quota for the day. So while I wait for a new Einstein download day at 0000 UTC I decided that using the 0.38 installer could get me to a clean configuration running Raistmer ATI astropulse, plus CPU Multibeam.

After first greatly lowering my requested work queue (to a quarter day) I exited BOINC, ran the installer, then compared the command line parameters it chose to those I had been using. It has set my unroll to 6, while I had previously used 8, fruit, I think, of pretty careful comparisons on my particular card on in this environment. So I put that back to 6, and added -hp -no_cpu_lock. Then, to be conservative, I did a full Windows restart.

The new configuration got and started work so fast I was startled. My existing queue of Astropulse work assigned to the ATI card was not discarded, though a new one was downloaded and started up rather than continuing the old partly finished one. So I've suspended all ATI AP units save the partially completed old one to see how things go. So far it is running, consuming power, and indicating progress toward completion, so I imagine all is well.

For my card (a GIGABYTE GV-R455D3-512I Radeon HD 4550 512MB 64-bit DDR3) previous exploration of the command line parameters had not found values which allowed streaming video to play satisfactorily without gravely impairing AP computational output, so I've relied instead using the BOINC "Suspend GPU work while computer is in use?" setting to Yes.

With a five minute restart interval setting, this works well enough, though I need to nudge the mouse once every five minutes, and when I am using voice input (generally do for a full hour each morning), If I read something long the voice commands for moving within an HTML page don't count as mouse or keyboard work, so it can slow. Fortunately I issue voice mouse clicks, which do count, often enough that this is only occasionally a problem

I'm mentioning this last in this thread, as the unified installer may attract some new ATI card owners. If adjusting the suggested command line parameters does not give you satisfactory results, you may wish to try the method I use.

My thanks to the Lunatics application developers, the Lunatics installer developers, and all the testers who helped them deliver this product.

---

Uh, what does the -no_cpu_lock parameter do? It has not been mentioned before, and it's not in the release "Tuning cmd line parameters" in the first post on this thread, only the -unroll, -ffa_block, and the -ffa_block_fetch parameters.

This thread says that back at Raistmer's r503 level, this parameter allowed the application to use any CPU on multi-CPU processors. My own testing showed an exceedingly small impact, and not necessarily beneficial. But I dislike tasks restricting themselves to subsets of available CPU's, so I left it turned on since then.

I have not checked to see what the processor affinity is for this release--it is possible the behaviors are now difference than they were on r503.

---

I have not checked to see what the processor affinity is for this release--it is possible the behaviors are now difference than they were on r503.

I've checked now, and on my Westmere CPU Windows 7 x64 system, the behavior is as I described in the cited posting on r503--without this parameter on my eight virtual CPU host Process explorer shows the supporting CPU application having affinity to CPU 0 and CPU 1, which turns out to be the two different virtual appearances of one physical core. With the parameter enables, the affinity box is ticked for all eight virtual CPU instances--in other words no affinity at all.

Possibly it is not mentioned in the release notes as not being provably useful.

I can make no undertaking as to the behavior or performance impact on other sorts of host.

---

I have not checked to see what the processor affinity is for this release--it is possible the behaviors are now difference than they were on r503.

They remained the same. CPUlock actual for multy-GPU or multy-task per GPU setups only. So other can use -no_cpu_lock param and even get some speedup.

Also, as Installer release notes didn't include all included application notes, I think it's better to reference to original release notes for each separate application that was included into installer. Standalone application release notes list all application parameters and describes meaning.

BTW, targed audience for installer (instead of standalone application) is "plug-and-forget" users who will not read much abot app tuning.

As per other users, I'm also a very happy user of the 0.38 Installer. I'm only using it as it came, 'out of the tin', but it did what I was a little wary of doing....namely, installing the relevant applications in the right place. The installation was simple and painless and done at the same time as installing the latest version of BOINC. At last, the HD4890 (one of the 1 GHz core capable RV790 GPUs) in my main PC can do some useful work, even if its full potential is probably not being realised. I've not even tried to tweak the ATI GPU applications, as it is working very well as it is - any speed increase over the Lunatics CPU applications I was already using, is very welcome! From me, a very big thumbs-up and an even bigger 'thanks guys' to The Lunatics team and all the testers, particularly, Raistmer, who has done a brilliant job, in spite of Open CL!

---

Don't take life too seriously, as you'll never come out of it alive!

I had not had any problems using .37 with my radeon 6970. All was working just went ahead and upgraded to .38 last night came down this morning and has the BSOD rebooted came back and it was locked up again. I did not mess with the config file or anything just install and go with the new ati options. Any ideas?

I had not had any problems using .37 with my radeon 6970. All was working just went ahead and upgraded to .38 last night came down this morning and has the BSOD rebooted came back and it was locked up again. I did not mess with the config file or anything just install and go with the new ati options. Any ideas?

Did you check the temps of the GPU ?

Which drivers are you running?
Did you upgrade drivers?
If so which one was used before ?

Do you have knowledge with appinfo.xml ?

I guess you had driver restarts so we could start changing period_iterations first.

---

With each crime and every kindness we birth our future.

I had not had any problems using .37 with my radeon 6970. All was working just went ahead and upgraded to .38 last night came down this morning and has the BSOD rebooted came back and it was locked up again. I did not mess with the config file or anything just install and go with the new ati options. Any ideas?

Did you check the temps of the GPU ?

Which drivers are you running?
Did you upgrade drivers?
If so which one was used before ?

Do you have knowledge with appinfo.xml ?

I guess you had driver restarts so we could start changing period_iterations first.

IIRC, LI0.37 hadn't ATI/AMD GPU apps included.
The ATI/AMD GPU apps are now new in LI0.38 .

So before your GPU hadn't calculated WUs.
So it's normal that you hadn't probs with your HD6970 and with LI0.37 . ;-)

In the 'Lunatics ReadMe' file is an explanation how to edit the app_info.xml <cmdline> entries:

(...)
Tuning cmd line parameters:
For AP: If you get lags or worse driver restarts, decrease unroll. If you run
stable you can try to increase it. ffa_block should be a multiple of ffa_block_fetch.
Start low e.g. -ffa_block 4096 -ffa_block_fetch 2048 and try increasing if it runs
fine. Sticking to the power of 2 line at first can help.
The will be a system specific best combination - too low slows you down, too high
slows you down as well.
Remember AP runtimes depend on blanking % so only compare runtimes on similar
blanking %.
For MB: other way round - if you experience lag or driver restarts increase
-period_iteration_num
(...)

- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

I had not had any problems using .37 with my radeon 6970. All was working just went ahead and upgraded to .38 last night came down this morning and has the BSOD rebooted came back and it was locked up again. I did not mess with the config file or anything just install and go with the new ati options. Any ideas?

Did you check the temps of the GPU ?

Which drivers are you running?
Did you upgrade drivers?
If so which one was used before ?

Do you have knowledge with appinfo.xml ?

I guess you had driver restarts so we could start changing period_iterations first.

IIRC, LI0.37 hadn't ATI/AMD GPU apps included.
The ATI/AMD GPU apps are now new in LI0.38 .

So before your GPU hadn't calculated WUs.
So it's normal that you hadn't probs with your HD6970 and with LI0.37 . ;-)

In the 'Lunatics ReadMe' file is an explanation how to edit the app_info.xml <cmdline> entries:

(...)
Tuning cmd line parameters:
For AP: If you get lags or worse driver restarts, decrease unroll. If you run
stable you can try to increase it. ffa_block should be a multiple of ffa_block_fetch.
Start low e.g. -ffa_block 4096 -ffa_block_fetch 2048 and try increasing if it runs
fine. Sticking to the power of 2 line at first can help.
The will be a system specific best combination - too low slows you down, too high
slows you down as well.
Remember AP runtimes depend on blanking % so only compare runtimes on similar
blanking %.
For MB: other way round - if you experience lag or driver restarts increase
-period_iteration_num
(...)

- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

I think i figured out the problem. I had left my "Trading Paints" application for my iRacing running. It seems to reek havoc on the GPU when it tries to minmize the screen saver to show the upadates. It kinda ends up with the same result as the Freeze during a youtube video. I apreciate the help.

With a non-FERMI-equipped machine & 0.38g installed, the newly-downloaded CUDA units are showing in the cache as CUDA_FERMI, whereas understandably they didn't before. Is this likely to lead to errors once the card comes across them or is it nothing to worry about?

With a non-FERMI-equipped machine & 0.38g installed, the newly-downloaded CUDA units are showing in the cache as CUDA_FERMI, whereas understandably they dind't before. Is this likely to lead to errors once the card comes across them or is it nothing to worry about?

It's nothing to worry about, there's extra enties in the app_info to cover multiple different configurations, so work isn't lost,

Claggy

With a non-FERMI-equipped machine & 0.38g installed, the newly-downloaded CUDA units are showing in the cache as CUDA_FERMI, whereas understandably they dind't before. Is this likely to lead to errors once the card comes across them or is it nothing to worry about?

It's nothing to worry about, there's extra enties in the app_info to cover multiple different configurations, so work isn't lost,

Claggy

To add to Claggy's reply just a little. The 6.10 (cuda- fermi) app is listed first in the app_info. The work is all the same so it just picks the first name it comes to. It is running the work you already had as whatever version you had asked for when you got them. If those other versions were not included in the app_info you would have lost all that earlier work. All the work from now on will be marked as 6.10.

---

PROUD MEMBER OF Team Starfire World BOINC