GPU load varies from 65% to 80% on my OC'd GTX570. I think different WUs using GPU more or less.

I wonder if app_info trick exists on GPUGRID in order to run 2 WUs concurrently and thus maximize the output.

And one more question. Does linux app speed up calculation like in those days? I was out from GPUGRID for some time and now I'm looking to come back :-)
____________

I get about 85% to 95% usage on my GTX 570, no OC, running Linux with SWAN_SYNC=0. Yes, it seems the usage depends on the app or task.

I haven't done any solid comparisons between OS's but they say the Linux app is 15% faster than the Windows app on Win7.

I've heard it said that 2 tasks running concurrently don't run in parallel, they run serially. If that's true then I don't see much benefit from running 2 tasks concurrently. I could be wrong. I've never tried it.

I get about 85% to 95% usage on my GTX 570, no OC, running Linux with SWAN_SYNC=0. Yes, it seems the usage depends on the app or task.

I haven't done any solid comparisons between OS's but they say the Linux app is 15% faster than the Windows app on Win7.

I've heard it said that 2 tasks running concurrently don't run in parallel, they run serially. If that's true then I don't see much benefit from running 2 tasks concurrently. I could be wrong. I've never tried it.

I've tested the app_info in the past on tasks with various GPU utilization.
By the time you get to about 85% utilization there is little or no point.
When you go up to about 95% you would see an overall loss.
At 65% there should be some gain, but then you have to consider task turn around time and the credit system. The problem with having multiple tasks is that you could gain from running one type, but lose from running the other.
I'm not sure what the ratio of task types are, and the utilization might change when new batches are created.
It may also be the case that different operating systems benefit differently. So for example, there might be less gain on Linux than W7.

Theretically speaking 2 tasks runnig concurrently will increase GPU load to 100% (I see no reasons why not). That will slow down individual task for sure, but while running 2 tasks that should increase overall output.

that's weird. in my understanding while you increasinf GPU load you getting more. That approach works on any other GPU project and I see no reason why it should not work on GPUGRID. But that's thoery, I'd like to try that in real life.

I've got couple of questions:
1. SWAN_SYNC=0 - where I should input that? AFAIK it's on in linux by default...

2. How I can check GPU load on linux? AFAIK, nvclock project is dead since G200 series (beta support, my GTX5275 never worked properly though) and year 2008 :-(

That's good news that linux is faster. I need to spend some time on w7 though to find stable clocks/voltage and then to flash them and then - "home, sweet home" :-)

Theretically speaking 2 tasks runnig concurrently will increase GPU load to 100% (I see no reasons why not). That will slow down individual task for sure, but while running 2 tasks that should increase overall output.

That's correct, but the wu turnaround (return) time is more important in GPUGrid, than the overall output.

GPUGrid is different than other GPU projects. Here in GPUGrid a new workunit continues the calculation from where the previous wu finished. Therefore the new workunit depends on the result of the previous workunit

that's why turnaround time is very important, and honored by +50% bonus credit if you return the result within 24 hours, (and by +25% bonus credit if you return the result within 48 hours). If you run two workunits simultaneously on the same GPU, your wu turnaround time will miss the 24 hour deadline (with the long workunits), and you will lose the +50% bounus, and you will receive only +25% bonus. All in all, there is no point to increase the overall output by 5-15% to lose 25% credit bonus.

BTW your wus are failing because you're overclocking your GTX570 too much. The higher the GPU utilization is, the lower the overclocking can be. GPUs cannot be overclocked for 5-8 hours long GPUGrid tasks as much as for gaming (or for shorter workunits). You should also increase your GPU's fan speed. The lower the GPU temperature is, the more stable the GPU will be.

It might be on by default in Linux, I don't know. The stderr on the website for each task shows the value for SWAN_SYNC. If it says there the value is 0 and you have no "export SWAN_SYNC=0" statement anywhere then assume it's 0 by default. I put "export SWAN_SYNC=0" in ~/.bashrc. Note the period, it's a hidden file. I'm the only user on the system so that's adequate for me. If you have multiple users you'll want to put the statement in a script that runs for every user.

Yah, nvclock doesn't work here either. The nvidia-settings utility doesn't give GPU load either. I've been able to read GPU usage only with the nvidia-smi utility and only with the 270.xx drivers. It doesn't report usage here with the 260.xx driver.

There's only one way to be sure and that's to try it and see. I'm sure skgiven and others have been down that road before so keep in mind what they say when you're testing. And as Retvari said, make sure your tasks return within 24 hrs. if you want the credit bonus. I think a GTX 570 will have no problem returning 2 concurrently running tasks in 24 hrs. but ya never know.

Also, I had troubles with the temperature on my GTX570 when I started running it on Linux. The fan would not speed up as the temp rose so I had to manually force it to run at high speed permanently. That required some research and playing around. I expect you and others will run into the same problem so I wrote up what I did and posted it here on the BOINC dev forum. I recommend getting a handle on that BEFORE you run your first CUDA task on Linux.

BTW, what’s version of drivers is the fastest? 260, 270 or 275?

If you need modded BIOS for your card –just let me know, I’ll do it for u.

OK, I'll use 275.xx drivers, NP at all :-)
____________

But I cannot see any mentioning of SWAN_SYNC…

It only says so if you are running SWAN_SYNC, it doesn't mention anything if not (at least when looking at my results).

Be careful when putting SWAN_SYNC in .bashrc, it will only work if boinc is running as that user.
To set it system-wide, look in /etc/environment or /etc/env.d/

Be careful when putting SWAN_SYNC in .bashrc, it will only work if boinc is running as that user.
To set it system-wide, look in /etc/environment or /etc/env.d/

that's not a problem coz there's one user account on that PC.

If you installed BOINC from repositories then it is NOT setup to run on your account. It will run on a special boinc user's account which is usually named boinc or something similar. In that case the boinc user will not see the SWAN_SYNC environment variable if you put it in your .bashrc. If you installed BOINC from the Berkeley installer (the .sh script) then putting it in your .bashrc is adequate.

Try this message from the Einstein forums. It has an app_info.xml used for running 4 Einstein tasks on a GTX480. It should give you the general idea. Maybe you can modify it to work with GPUgrid.

Try this message from the Einstein forums. It has an app_info.xml used for running 4 Einstein tasks on a GTX480. It should give you the general idea. Maybe you can modify it to work with GPUgrid.

<name>acemdlong_6.15_windows_intel86__cuda31.exe</name>

Let’s take the worst case scenario (theoretical case) when GPU load is 100%. If I'm running the 2nd WU concurrently, duration for both of them is twice longer then for single WU. Am I right?

Let's come back to the real world. I finished one WU in 6hrs, so if I'm running 2 WUs it should take me 12 hrs to complete both of them. But remember - GPU load is less than 100%, so in reality it will be not 12hrs, but, let's say, 9-11hrs. All in all, I'm pretty much OK to be within 24hrs limit to get +50% bonus.

That’s why IMHO it makes sense to go with app_info trick.

I did run using an app_info file for a week or more on a dual GPU setup, but that was over 6months ago. Others also did this. For a short time it was worth it, but that was before 6.14 and only when there were lots of less GPU utilizing tasks around (~50%).

Double checked and I did have the .exe in my old app_info file (might not make any difference in Windows).

Nice discussion. guys :-) Rite now I'm waiting WU to complete and then I'll try app_info - both with and w/o .exe

You're right. Theoretically. :)

There is a prerequisite for this scenario: Your PC should not keep a spare pair of WU's in it's queue for too long, because if these two spare WUs are sitting in the queue for 12 hours, and then they are processed for another 12 hours they will just miss the 24 hours deadline. But if your queue is short, and a WU fails, your GPU will run only one WU (or in worst case: nothing) until a new one (or two) is downloaded.

You forget about the reason behind low GPU utilization:
GPUGrid uses both the GPU and the CPU for processing a WU. The more the CPU usage of a WU is, the less its GPU usage is, because of the heavy data transmission on the PCIe bus. A GIANNI_KKFREE WU (82% GPU usage) uses 5.5 times more CPU than a TONI_AGGsoup WU (98% GPU usage). I learned from my experience, that I have to overclock a Core2Duo by 33% to get the performance (say 5-10% more GPU usage) of a Core i3 (its integrated PCIe controller is 33% faster than the X48 chipset's). I think the existence of a bus between the GPU and the CPU is the bottleneck, and this bus (ie. the PCIe) can be overloaded even by processing a single GIANNI_KKFREE-like WU. If this is right, there will be no significant rise in GPU usage by running two of them simultaneously (although there can be significant rise in GPU usage by running low and high GPU utilizing tasks at the same time, but maybe the lower GPU utilizing would be more slow than expected).
Don't get me wrong, I'm curious about this, but at the same time I'm very skeptical. Let's find out...

OK, I tried both version (with .exe and w/o .exe). They deleted everything (including .exe and all .dll) file from the BOINC folder, so smth wrong with app_info

Guys, don't get me wrong - I'm not complaining, I'm just reporting :-)
____________

I don't know what the problem is but I guess the issue may be related to the fact that priority is now being controlled at the thread level rather than Process level.

Generally this should match the corresponding elements in a scheduler reply message (sched_reply_URL.xml)

If you're going to change it in one place, you have to change it in the other, too.

The app name is wrong:

<app>
<name>acemd2</name>
</app>

should be,

<app>
<name>acemd_long</name>
</app>


Corrected app_info file:

<app_info>
<app>
<name>acemd_long</name>
</app>
<file_info>
<name>acemdlong_6.15_windows_intel86__cuda31.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart32_31_9.dll</name>
<executable/>
</file_info>
<file_info>
<name>cufft32_31_9.dll</name>
<executable/>
</file_info>
<file_info>
<name>tcl85.dll</name>
<executable/>
</file_info>
<app_version>
<app_name>acemd_long</app_name>
<version_num>615</version_num>
<avg_ncpus>0.025</avg_ncpus>
<max_ncpus>0.050</max_ncpus>
<flops>1089000000000</flops>
<plan_class>cuda31</plan_class>
<coproc>
<type>CUDA</type>
<count>0.5</count>
</coproc>
<gpu_ram>1280000000</gpu_ram>
<file_ref>
<file_name>acemdlong_6.15_windows_intel86__cuda31.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_31_9.dll</file_name>
</file_ref>
<file_ref>
<file_name>cufft32_31_9.dll</file_name>
</file_ref>
<file_ref>
<file_name>tcl85.dll</file_name>
</file_ref>
</app_version>
</app_info>

Thanks Richard.

If anyone tests this, post your findings.

same story - almost everything gone from www.gpugrid.net folder...
____________

Probably too late, but maybe helpful for future tests:

Make a copy of all files needed for the app_info, e.g. cudart32_31_9.dll and so on, put them all into a folder with the app_info and copy all into your GPUGRID folder, overriding the existing files. Alternately you can get the files somewhere from the GPUGRID download server (sorry, but I forgot the link).

Not sure why, but BOINC does not recognize those files present even if they have the same file name.

Hope this helps.


____________

Obviously it does not, I tried myself. But I also tried to translate a working app_info from 6.14 to 6.15 and it did not work either. :(
____________