Nanoprobe! Is there any benefit using an app-info file to run multiple wu if you, as in my case, have close to 100% load on the GPU without an app-info file?

I stopped almost doubling the number of tasks by using an app_info.xml
After a while the 2 GPU-tasks seem to synchronize and using the GPU at the same time slowing down each other.
After a while that slow down lasts longer than running only 1 GPU-task at a time.
It can even happen that the 2 tasks are slowing down for ever and I had to revive both by restarting them (LAIM not set, suspend and resume).
Restarting 2 tasks out of sync is too much babysitting.
Radeon HD 7770 on i7-2600 HT.

The only advantage now using an app_info.xml is that I'm able to determine a correct estimated runtime for the GPU-tasks.

hm i have some strange error on the computer with the 260GTX after 2,3,4 WUs without error it changes his mind und tell me:

12.10.2012 22:01:35 | World Community Grid | Output file X0960069560256200606141611_0_0 for task X0960069560256200606141611_0 absent
12.10.2012 22:01:35 | World Community Grid | Starting task X0960069560261200606141611_0 using hcc1 version 656 (nvidia_hcc1) in slot 1
12.10.2012 22:01:37 | World Community Grid | Computation for task X0960069560261200606141611_0 finished

Dont know whats exactly the problem :/ GPU is not running hot, cpu is fast enough and free core for gpu, it always runs perfect for some workunits, there is enough HD space for boinc...

PS, edit: ups i found out the error log shows always he wants to use the 9800GTX with is reserved for einstein in this machine..and all valid/pendings are showing they used the 260GTX..i think i forgotten to exclude gpu1 from WCG -_- what a shame..hope it works..

Edit2: ok it runs for two hours now, problem selfsolved ^^

I read from 85 secs on that card so it seems fast on wcg ;)

Just a quick update to the discussions here.

The estimated runtime mechanism of the v7 code keeps statistics on the speed of a device at two levels:

1) The overall 'app_version' level
2) The device-'app_version' level

There were two things going on with the v7 server code that were interfering with the correct collection of these statistics.

a) The 'app version' statistics are updated after each pass of the validator (1 pass is either 1000 workunits or all available workunits which ever is less) if and only if the validator 'did no work' during the pass. Given that this project is currently validating about 4.5 workunits per second it was very rare that this statistics were getting updated. We modified this so that the statistics are updated after every pass where work is done (i.e. every pass where at least one workunit was validated).

b) The individual 'device app version' statistics are updated each time a device has a workunit validated. However, this is only if the server code decides that the peak reported performance of the host * the elapsed time yields what the server code determines is a reasonable value. Unfortunately, almost all ATI cards and about half NVIDIA cards were being considered to be unreasonable. We expanded the range of 'acceptable' values to 20 times its previous values. Now most cards are being deemed 'reasonable'. We need to look at this closer and figure out if the range needs further expansion.

To give you a sense of the issue these were creating together, as of about 15 hours ago, the ATI app version had only captured statistics based on 78 results. Now, 15 hours after releasing the change, statistics have been collected for ATI based on over 95,000 results.

These statistics are key for providing the client with a reasonably accurate 'flops'. Without the data collection working correctly, the flops sent to the client was a crude estimate.

I would be curious to know if anyone had seen an improvement in the duration estimates over the past 6-8 hours now that these statistics should be much more accurate. This should hopefully address some of the issues with non-gpu workunits being very badly estimated and excessive downloads occurring.