There'll be a new version out later today, after stumps.

As promised, version 845 should report progress correctly.

Matt

Or not, because I don't know the difference between percentages and fractions. 846 out now, which should also correctly report to the client when a checkpoint was performed.

Matt

Just aborted a V845 that has been been at 100% complete forever...
According to BOINC it was 4,706.000% DONE

Application	Test application for CPU MD 8.45 (mt)
Workunit name	6_745-MJHARVEY_gpugrid10z4-0-1-RND3120
State	Waiting to run
Received	28-07-2014 16:10
Report deadline	02-08-2014 16:08
Estimated app speed	3.82 GFLOPs/sec
Estimated task size	5,000,000 GFLOPs
Resources	2 CPUs
CPU time at last checkpoint	00:00:00
CPU time	21:05:58
Elapsed time	13:59:25
Estimated time remaining	00:00:00
Fraction done	4,706.000%
Virtual memory size	49.34 MB
Working set size	0.35 MB
Directory	slots/5
Process ID	5716

---

According to BOINC it was 4,706.000% DONE

845 misreported by a factor of 100. You job was 47% complete when you killed it.
This is fixed in 846.

MJH

Matt,
currently running a v 8.46 -
http://www.gpugrid.net/result.php?resultid=12898547

It has been running 1 hour and reports that it is 1% complete, with time to completion 5days and 36 minutes?

EDIT - Also, there are no other BOINC tasks or non-BOINC app's running. BOINC reports CPU usage at 100%, but Win XP Task Manager reports only 50% CPU usage.

Mine ran for roughly 5 1/2 hours, and went from 8732% to complete instantly, and the part that is really bothering me is that I have the test applications turned off.

Hi Matt,

Just started up an 8.46 job in Windows 7. My app_config is listed below, but the app seems to ignore the app_config settings for number of CPU's. Can you see something that needs to be changed in my app_config. BOINC Manager is not showing any errors when it reads the app_config.

<app_config>
    <app>
        <name>android</name>
        <max_concurrent>8</max_concurrent>
    </app>
  <app_version>
    <app_name>cpumd</app_name>
    <plan_class>mt</plan_class>
    <avg_ncpus>8</avg_ncpus>
    <cmdline>--nthreads 8</cmdline>
  </app_version
</app_config>

The Linux tasks seems to be running well and running within the number of CPU's specified in the app_config. As a reminder, I really like using the app_config so I can reserve a few cpu threads to support GPU processing.

Thanks,
captainjack

The 8.46 task on Windows 7 just finished. It was running on 16 threads. Here are the estimates:

Elapsed minutes: 42
% complete: 1.75
Estimated to finish: 40:53:39

Elapsed minutes: 103
% complete: 4.2
Estimated to finish: 39:53:44

Elapsed minutes: 107
Finished

Hope that helps.

Captainjack,

That app config looks ok to me. Have a look in the stderr reported by the job, that will say at the top how many threads the program is using.

Matt

The app_config probably won't take effect immediately (even if you read the config files from Boinc) as work units occupy slots and cores are already allocated to started work. So it should kick in after a WU finishes. The trouble with this is that the WU's are long (just like the GPU work units).

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Excellent job. Multithreaded application works fine on my host, V846 report progress correctly. Now GPUGRID is like Folding@Home project - with apps for the GPUs and multi-core CPUs. Thx.

I don't have time to check my BOINC client all that often so I am not sure how long this has been going on. I had "Test Applications" disabled but I still found these work units running on my system. It appears GPU tasks will not run with these WUs using all the cores. At least that is my assumption, possibly an incorrect one, since no GPU WU was running or even pending.

I disabled the "Molecular Dynamics on CPU" jobs, updated the BOINC client, aborted all the MT WUs and updated the client again. No GPU WUs were loading so I tried updated the client again with the same results. The BOINC client log says no short or long GPU tasks are available. I checked the server and there are thousands of short and long WU that are unsent. I rebooted and I am still getting the same thing.

Any guesses on how long my GPU will remain idle?

The client log also says I have processed my daily quota of 16 tasks. :-(

I suppose that means I won't get any new tasks until tomorrow. I guess my GPU will get another day of vacation. :-)

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

Matt

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

Matt

Only if GPUGrid is the only project the client is attached to. Look at this Event Log snippet from one of my GPUGrid attached machines.

02/08/2014 15:51:51 | boincsimap | [work_fetch] REC 0.000 prio -0.000000 can req work
02/08/2014 15:51:51 | LHC@home 1.0 | [work_fetch] REC 0.429 prio -0.000007 can req work
02/08/2014 15:51:51 | Einstein@Home | [work_fetch] REC 2309.624 prio -0.044407 can req work
02/08/2014 15:51:51 | NumberFields@home | [work_fetch] REC 5219.505 prio -0.088347 can req work
02/08/2014 15:51:51 | GPUGRID | [work_fetch] REC 232810.246 prio -1.957289 can req work
02/08/2014 15:51:51 | SETI@home | [work_fetch] REC 242781.786 prio -2.030169 can req work

<work_fetch_debug> lists projects in priority order for the next work fetch. SIMAP is highest priority because they've been off-stream for about the last month between batches. When SIMAP comes back on-stream on Thursday, work will be fetched preferentially from there to even up resource share and make up for that missing month.

LHC and NumberFields are my other two active CPU projects (Einstein is intel_gpu only on this machine, so let's leave it out for now). When all three are active and have work available, their REC and priority figures will all be jostling around the same levels, and work will be fetched turn-and-turn-about to maintain resource share.

But my two GPU projects - SETI and GPUGrid, they're allocated one GPU each - are in a class of their own. The REC (Recent Estimated Credit - bears no relationship to actual granted credit) from a GPU is so much higher than from a CPU that work fetch priority is driven extremely low - CPU work will only be fetched as a last resort when all other possible sources of supply have been exhausted.

Even if you force it to fetch work by blocking other projects, it still faces a similar priority hurdle before actually running. I've been trying to get a couple of test CPU tasks from SETI to run this afternoon, and I've had to tweak a lot of my normal settings to force them into action.

In short: if a client is running GPU work from GPUGrid, it will have a strong bias towards running "anything except GPUGrid" on its CPUs.

I don't know about obtaining but I can confirm that Linux BOINC 7.2.47 does not suspend my Einstein GPU WUs when running cpumd on all cores. That must be a BOINC error however.

Matt asked:

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

I just reconfigured my Ubuntu box to not have an app_config and test Matt's question. It is currently running two GPUGRID GPU tasks and one CPUMD task using all available CPU's.

The GPU tasks show that they are using 0.756 CPU each and the CPUMD task is using 11 CPU's (all that is allocated to that BOINC client). BOINC has over-commited the CPU's available, but it does seem to be working.

Let us know if you want us to perform a different test with a different configuration.

Hope that helps,
captainjack

Matt, the harsh reality is that GPU WU's use the CPU and the more you use the CPU for other work the more it impacts upon GPU work.
Your app is fine for systems without an NVidia GPU. Otherwise its a bang your head of a wall exercise!

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

The Linux version of CPUMD has been updated. Changes:

* Rebase from gmx 4.6 to 5.0
* There are now optimised builds for SSE2, SSE4 and AVX.
* BOINC progress reporting

Matt