gmane.comp.distributed.boinc.devel

Intel GPUs

Jon Sonntag — 2013-05-23T14:50:25

I'm having trouble with OpenCL Intel GPU work requests.  The problem is no
work ever gets sent.
If the Intel GPU is requesting 108000 seconds of work would the
work_req_seconds show as 0?  Is that a bug or is the work_req_seconds now
deprecated?  The log on the server shows:


013-05-23 09:34:21.4934 [PID=27500]    [send] CPU: req 0.00 sec, 0.00
instances; est delay 0.00
013-05-23 09:34:21.4934 [PID=27500]    [send] Intel GPU: req 108000.00 sec,
1.00 instances; est delay 0.00
013-05-23 09:34:21.4934 [PID=27500]    [send] work_req_seconds: 0.00 secs
013-05-23 09:34:21.4934 [PID=27500]    [send] available disk 95.47 GB,
work_buf_min 86400
013-05-23 09:34:21.4934 [PID=27500]    [send] active_frac 0.999834 on_frac
0.999692
013-05-23 09:34:21.4934 [PID=27500]    [send] CPU features: fpu vme de pse
tsc msr pae mce cx8 apic sep mtrr pge mca c$
013-05-23 09:34:21.4941 [PID=27500]    Sending reply to [HOST#123978]: 0
results, delay req 181.80
013-05-23 09:34:21.4945 [PID=27500]    Scheduler ran 0.005 seconds


Jon Sonntag

Behavior of core client/GPU apps when remote desktophits

Eric J Korpela — 2013-05-22T17:12:17

I'm having some difficulty figuring out how to handle some hosts that I
think are getting their GPU access cut off by remote desktop.

Here's one such host...

http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=62767
He's using BOINC 7.0.64

If you check out the tasks list you'll see two sets of GPU apps that are
failing.  The ati_cal apps are failing with an error "-226
(0xffffffffffffff1e) ERR_TOO_MANY_EXITS" when attempting to use the GPU.
The opencl apps are exiting with "201 (0xc9) EXIT_MISSING_COPROC" which I
assume is the appropriate exit code.

In both cases, the max_jobs_per_day in host_app_version is getting
decremented, so it will take many days for this host to recover should the
GPU come back.

Not much can be done about the version that returns the error except build
a version that recognizes the GPU is gone, and exit properly.  But should
the core client, rather than aborting a result that has an
EXIT_MISSING_COPROC, just not attempt to run it again until a GPU is
detected?

Maybe this conversation has been had before and I missed it.

PHP errors in user.log and syslog

Jon Sonntag — 2013-05-22T14:45:30

I noticed my log files were really, really large lately.  I have about 20GB
of the same errors showing up in the user and syslog files:

May 18 06:23:49 debian2 suhosin[9247]: ALERT - script tried to increase
memory_limit to 268435456 bytes which is above the allowed value (attacker
'46.105.102.130', file '/home/boincadm/projects/collatz/html/inc/util.inc',
line 33)

Line 33 of util.inc contains:
ini_set("memory_limit", "256M");

Having never changed the default settings in /etc/php5/apache2/php.ini the
memory_limit was set to 128M.  It seems that BOINCs attempt to increase the
query size to 256M was seen as an attack.  Has the value always been 256M
or was it increased recently?  Or, is the 128M a change in a recent PHP
version? I am using PHP 5.3.3-7+squeeze14 with Suhosin-Patch (cli) (built:
Aug  6 2012 14:18:06)

If BOINC needs to be 256M, then maybe something should be added to the
server install documentation that explains how the PHP settings need to be
edited to allow 256M to avoid every client visit being considered an
error.  If not and the default is 128M for PHP installs, maybe BOINC can
use 128M as well or omit the ini_set line and use the server default. (I
assume that 256M was a conscious choice but one never knows unless one
asks.)

Jon Sonntag

7.1.1 also getting new work for suspended project

2013-05-21T19:38:01

I suspended Constellation since "No New Work" wasn't preventing boinc from requesting
new work units from it and just noticed that it's still requesting work units from
constellation. Here's the section of stdoutdae.txt where it got another WU.

5/21/2013 2:29:52 PM |  | [work_fetch] ------- start work fetch state -------
5/21/2013 2:29:52 PM |  | [work_fetch] target work buffer: 83808.00 + 11232.00 sec
5/21/2013 2:29:52 PM |  | [work_fetch] --- project states ---
5/21/2013 2:29:52 PM | The Lattice Project | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | superlinkattechnion | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | MindModeling< at >Beta | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | Constellation | [work_fetch] REC 24.280 prio 0.000000 can't req
work: suspended via Manager
5/21/2013 2:29:52 PM | rosetta< at >home | [work_fetch] REC 28.099 prio -0.065670 can req work
5/21/2013 2:29:52 PM | correlizer | [work_fetch] REC 27.875 prio -0.066564 can req work
5/21/2013 2:29:52 PM | eon2 | [work_fetch] REC 14.597 prio -0.066898 can req work
5/21/2013 2:29:52 PM | World Community Grid | [work_fetch] REC 276.058 prio -0.067595
can req work
5/21/2013 2:29:52 PM | Docking | [work_fetch] REC 71.034 prio -0.069294 can req work
5/21/2013 2:29:52 PM | NumberFields< at >home | [work_fetch] REC 15.042 prio -0.071349 can
req work
5/21/2013 2:29:52 PM | SZTAKI Desktop Grid | [work_fetch] REC 14.960 prio -0.075118 can
req work
5/21/2013 2:29:52 PM | malariacontrol.net | [work_fetch] REC 34.898 prio -0.077509 can
req work
5/21/2013 2:29:52 PM | boincsimap | [work_fetch] REC 32.339 prio -0.082647 can req work
5/21/2013 2:29:52 PM | ibercivis | [work_fetch] REC 15.922 prio -0.088790 can req work
5/21/2013 2:29:52 PM | fightmalaria< at >home | [work_fetch] REC 10.710 prio -0.098163 can
req work
5/21/2013 2:29:52 PM | Asteroids< at >home | [work_fetch] REC 15.895 prio -0.105204 can req work
5/21/2013 2:29:52 PM | Milkyway< at >Home | [work_fetch] REC 11.340 prio -0.215259 can req work
5/21/2013 2:29:52 PM | NFS< at >Home | [work_fetch] REC 28.400 prio -0.260310 can req work
5/21/2013 2:29:52 PM | LHC< at >home 1.0 | [work_fetch] REC 34.703 prio -0.318082 can req work
5/21/2013 2:29:52 PM | Poem< at >Home | [work_fetch] REC 4017.988 prio -4.603479 can req work
5/21/2013 2:29:52 PM | SETI< at >home | [work_fetch] REC 2618.643 prio -6.264621 can't req
work: scheduler RPC backoff (backoff: 297.68 sec)
5/21/2013 2:29:52 PM | Einstein< at >Home | [work_fetch] REC 4160.403 prio -9.768530 can req
work
5/21/2013 2:29:52 PM | PrimeGrid | [work_fetch] REC 1389.675 prio -12.795318 can req work
5/21/2013 2:29:52 PM |  | [work_fetch] --- state for CPU ---
5/21/2013 2:29:52 PM |  | [work_fetch] shortfall 3133.46 nidle 0.00 saturated 91906.54
busy 0.00
5/21/2013 2:29:52 PM | The Lattice Project | [work_fetch] fetch share 0.000
5/21/2013 2:29:52 PM | superlinkattechnion | [work_fetch] fetch share 0.000
5/21/2013 2:29:52 PM | MindModeling< at >Beta | [work_fetch] fetch share 0.000
5/21/2013 2:29:52 PM | Constellation | [work_fetch] fetch share 0.000
5/21/2013 2:29:52 PM | rosetta< at >home | [work_fetch] fetch share 0.050
5/21/2013 2:29:52 PM | correlizer | [work_fetch] fetch share 0.050
5/21/2013 2:29:52 PM | eon2 | [work_fetch] fetch share 0.025
5/21/2013 2:29:52 PM | World Community Grid | [work_fetch] fetch share 0.497
5/21/2013 2:29:52 PM | Docking | [work_fetch] fetch share 0.124
5/21/2013 2:29:52 PM | NumberFields< at >home | [work_fetch] fetch share 0.025
5/21/2013 2:29:52 PM | SZTAKI Desktop Grid | [work_fetch] fetch share 0.025
5/21/2013 2:29:52 PM | malariacontrol.net | [work_fetch] fetch share 0.062
5/21/2013 2:29:52 PM | boincsimap | [work_fetch] fetch share 0.050
5/21/2013 2:29:52 PM | ibercivis | [work_fetch] fetch share 0.025
5/21/2013 2:29:52 PM | fightmalaria< at >home | [work_fetch] fetch share 0.012
5/21/2013 2:29:52 PM | Asteroids< at >home | [work_fetch] fetch share 0.025
5/21/2013 2:29:52 PM | Milkyway< at >Home | [work_fetch] fetch share 0.006
5/21/2013 2:29:52 PM | NFS< at >Home | [work_fetch] fetch share 0.012
5/21/2013 2:29:52 PM | LHC< at >home 1.0 | [work_fetch] fetch share 0.012
5/21/2013 2:29:52 PM | Poem< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:29:52 PM | SETI< at >home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:29:52 PM | Einstein< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:29:52 PM | PrimeGrid | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:29:52 PM |  | [work_fetch] --- state for NVIDIA ---
5/21/2013 2:29:52 PM |  | [work_fetch] shortfall 5949.70 nidle 0.00 saturated 89090.30
busy 0.00
5/21/2013 2:29:52 PM | The Lattice Project | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | superlinkattechnion | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | MindModeling< at >Beta | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | Constellation | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | rosetta< at >home | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | correlizer | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | eon2 | [work_fetch] fetch share 0.000 (blocked by configuration
file)
5/21/2013 2:29:52 PM | World Community Grid | [work_fetch] fetch share 0.000 (blocked by
prefs) (no apps)
5/21/2013 2:29:52 PM | Docking | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | NumberFields< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | SZTAKI Desktop Grid | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | malariacontrol.net | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | boincsimap | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | ibercivis | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:29:52 PM | fightmalaria< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | Asteroids< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | Milkyway< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:29:52 PM | NFS< at >Home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | LHC< at >home 1.0 | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:29:52 PM | Poem< at >Home | [work_fetch] fetch share 0.615
5/21/2013 2:29:52 PM | SETI< at >home | [work_fetch] fetch share 0.000
5/21/2013 2:29:52 PM | Einstein< at >Home | [work_fetch] fetch share 0.308
5/21/2013 2:29:52 PM | PrimeGrid | [work_fetch] fetch share 0.077
5/21/2013 2:29:52 PM |  | [work_fetch] ------- end work fetch state -------
5/21/2013 2:29:52 PM | Constellation | [work_fetch] set_request() for CPU: ninst 2
nused_total 0.000000 nidle_now 0.000000 fetch share 0.000000 req_inst 0.000000 req_secs
3133.463423
5/21/2013 2:29:52 PM | Constellation | [work_fetch] request: CPU (3133.46 sec, 0.00
inst) NVIDIA (0.00 sec, 0.00 inst)
5/21/2013 2:29:52 PM | Constellation | Sending scheduler request: Requested by user.
5/21/2013 2:29:52 PM | Constellation | Requesting new tasks for CPU
5/21/2013 2:29:54 PM | Constellation | Scheduler request completed: got 1 new tasks
5/21/2013 2:29:54 PM |  | [work_fetch] Request work fetch: RPC complete
5/21/2013 2:29:56 PM | Constellation | Started download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870973.7z
5/21/2013 2:29:56 PM | Constellation | Started download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870973_job_0.10.xml
5/21/2013 2:29:57 PM | Constellation | Finished download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870973.7z
5/21/2013 2:29:57 PM | Constellation | Finished download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870973_job_0.10.xml
5/21/2013 2:30:00 PM |  | [work_fetch] work fetch start
5/21/2013 2:30:00 PM |  | [work_fetch] ------- start work fetch state -------
5/21/2013 2:30:00 PM |  | [work_fetch] target work buffer: 83808.00 + 11232.00 sec
5/21/2013 2:30:00 PM |  | [work_fetch] --- project states ---
5/21/2013 2:30:00 PM | The Lattice Project | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:30:00 PM | superlinkattechnion | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:30:00 PM | MindModeling< at >Beta | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:30:00 PM | Constellation | [work_fetch] REC 24.279 prio 0.000000 can't req
work: suspended via Manager
5/21/2013 2:30:00 PM | rosetta< at >home | [work_fetch] REC 28.098 prio -0.065670 can req work
5/21/2013 2:30:00 PM | correlizer | [work_fetch] REC 27.874 prio -0.066564 can req work
5/21/2013 2:30:00 PM | eon2 | [work_fetch] REC 14.597 prio -0.066898 can req work
5/21/2013 2:30:00 PM | World Community Grid | [work_fetch] REC 276.063 prio -0.067595
can req work
5/21/2013 2:30:00 PM | Docking | [work_fetch] REC 71.045 prio -0.069304 can req work
5/21/2013 2:30:00 PM | NumberFields< at >home | [work_fetch] REC 15.041 prio -0.071349 can
req work
5/21/2013 2:30:00 PM | SZTAKI Desktop Grid | [work_fetch] REC 14.960 prio -0.075118 can
req work
5/21/2013 2:30:00 PM | malariacontrol.net | [work_fetch] REC 34.897 prio -0.077509 can
req work
5/21/2013 2:30:00 PM | boincsimap | [work_fetch] REC 32.338 prio -0.082647 can req work
5/21/2013 2:30:00 PM | ibercivis | [work_fetch] REC 15.921 prio -0.088790 can req work
5/21/2013 2:30:00 PM | fightmalaria< at >home | [work_fetch] REC 10.709 prio -0.098163 can
req work
5/21/2013 2:30:00 PM | Asteroids< at >home | [work_fetch] REC 15.895 prio -0.105204 can req work
5/21/2013 2:30:00 PM | Milkyway< at >Home | [work_fetch] REC 11.340 prio -0.215258 can req work
5/21/2013 2:30:00 PM | NFS< at >Home | [work_fetch] REC 28.399 prio -0.260309 can req work
5/21/2013 2:30:00 PM | LHC< at >home 1.0 | [work_fetch] REC 34.702 prio -0.318081 can req work
5/21/2013 2:30:00 PM | Poem< at >Home | [work_fetch] REC 4017.856 prio -4.603467 can req work
5/21/2013 2:30:00 PM | SETI< at >home | [work_fetch] REC 2618.968 prio -6.265336 can't req
work: scheduler RPC backoff (backoff: 289.83 sec)
5/21/2013 2:30:00 PM | Einstein< at >Home | [work_fetch] REC 4160.267 prio -9.768505 can req
work
5/21/2013 2:30:00 PM | PrimeGrid | [work_fetch] REC 1389.630 prio -12.795284 can req work
5/21/2013 2:30:00 PM |  | [work_fetch] --- state for CPU ---
5/21/2013 2:30:00 PM |  | [work_fetch] shortfall 3142.81 nidle 0.00 saturated 91897.19
busy 0.00
5/21/2013 2:30:00 PM | The Lattice Project | [work_fetch] fetch share 0.000
5/21/2013 2:30:00 PM | superlinkattechnion | [work_fetch] fetch share 0.000
5/21/2013 2:30:00 PM | MindModeling< at >Beta | [work_fetch] fetch share 0.000
5/21/2013 2:30:00 PM | Constellation | [work_fetch] fetch share 0.000
5/21/2013 2:30:00 PM | rosetta< at >home | [work_fetch] fetch share 0.050
5/21/2013 2:30:00 PM | correlizer | [work_fetch] fetch share 0.050
5/21/2013 2:30:00 PM | eon2 | [work_fetch] fetch share 0.025
5/21/2013 2:30:00 PM | World Community Grid | [work_fetch] fetch share 0.497
5/21/2013 2:30:00 PM | Docking | [work_fetch] fetch share 0.124
5/21/2013 2:30:00 PM | NumberFields< at >home | [work_fetch] fetch share 0.025
5/21/2013 2:30:00 PM | SZTAKI Desktop Grid | [work_fetch] fetch share 0.025
5/21/2013 2:30:00 PM | malariacontrol.net | [work_fetch] fetch share 0.062
5/21/2013 2:30:00 PM | boincsimap | [work_fetch] fetch share 0.050
5/21/2013 2:30:00 PM | ibercivis | [work_fetch] fetch share 0.025
5/21/2013 2:30:00 PM | fightmalaria< at >home | [work_fetch] fetch share 0.012
5/21/2013 2:30:00 PM | Asteroids< at >home | [work_fetch] fetch share 0.025
5/21/2013 2:30:00 PM | Milkyway< at >Home | [work_fetch] fetch share 0.006
5/21/2013 2:30:00 PM | NFS< at >Home | [work_fetch] fetch share 0.012
5/21/2013 2:30:00 PM | LHC< at >home 1.0 | [work_fetch] fetch share 0.012
5/21/2013 2:30:00 PM | Poem< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:30:00 PM | SETI< at >home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:30:00 PM | Einstein< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:30:00 PM | PrimeGrid | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:30:00 PM |  | [work_fetch] --- state for NVIDIA ---
5/21/2013 2:30:00 PM |  | [work_fetch] shortfall 5955.27 nidle 0.00 saturated 89084.73
busy 0.00
5/21/2013 2:30:00 PM | The Lattice Project | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | superlinkattechnion | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | MindModeling< at >Beta | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | Constellation | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | rosetta< at >home | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | correlizer | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | eon2 | [work_fetch] fetch share 0.000 (blocked by configuration
file)
5/21/2013 2:30:00 PM | World Community Grid | [work_fetch] fetch share 0.000 (blocked by
prefs) (no apps)
5/21/2013 2:30:00 PM | Docking | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | NumberFields< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | SZTAKI Desktop Grid | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | malariacontrol.net | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | boincsimap | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | ibercivis | [work_fetch] fetch share 0.000 (blocked by
configuration file)
5/21/2013 2:30:00 PM | fightmalaria< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | Asteroids< at >home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | Milkyway< at >Home | [work_fetch] fetch share 0.000 (blocked by prefs)
5/21/2013 2:30:00 PM | NFS< at >Home | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | LHC< at >home 1.0 | [work_fetch] fetch share 0.000 (no apps)
5/21/2013 2:30:00 PM | Poem< at >Home | [work_fetch] fetch share 0.615
5/21/2013 2:30:00 PM | SETI< at >home | [work_fetch] fetch share 0.000
5/21/2013 2:30:00 PM | Einstein< at >Home | [work_fetch] fetch share 0.308
5/21/2013 2:30:00 PM | PrimeGrid | [work_fetch] fetch share 0.077
5/21/2013 2:30:00 PM |  | [work_fetch] ------- end work fetch state -------
5/21/2013 2:30:00 PM |  | [work_fetch] No project chosen for work fetch
5/21/2013 2:31:00 PM |  | [work_fetch] work fetch start
5/21/2013 2:31:00 PM |  | [work_fetch] ------- start work fetch state -------
5/21/2013 2:31:00 PM |  | [work_fetch] target work buffer: 83808.00 + 11232.00 sec
5/21/2013 2:31:00 PM |  | [work_fetch] --- project states ---
5/21/2013 2:31:00 PM | The Lattice Project | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:31:00 PM | superlinkattechnion | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:31:00 PM | MindModeling< at >Beta | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:31:00 PM | Constellation | [work_fetch] REC 24.278 prio 0.000000 can't req
work: suspended via Manager


David Ball

Problems with 7.1.1 work fetch on projects set to Nonew tasks

2013-05-21T17:13:42

Yesterday, I upgraded to 7.1.1 and had to set the constellation project to "no new
tasks". I would have suspended it but it's work units take about 10 hours and it only
had about 2 hours to go on the one work unit it had.

Sometime late yesterday or overnight, it finished that work unit. However, even with "no
new tasks" set, it fetched another work unit at 11:11:41. I've included the relevant
section of stdoutdae.txt below. I included enough before and after the work fetch so you
can see that it definitely had "no new tasks" set.

FYI, the reason I set Constellation to "no new tasks" was because after the upgrade to
7.1.1, it started executing Constellation work units as NCI aqain, which it had not done
in 7.0.64, although it had this same problem in some earlier versions of 7.0.
Constellation is not NCI so this caused an extra work unit to be executed on my C2D
E6420, which slowed down other work units and anything that ran on the system.

I aborted the new Constellation work unit if fetched at 11:11:41 and suspended
Constellation now that it has no work units.

Here is the section of stdoutdae.txt where it fetched a work unit while set to "no new
tasks" :


21-May-2013 11:11:34 [---] [work_fetch] ------- start work fetch state -------
21-May-2013 11:11:34 [---] [work_fetch] target work buffer: 83808.00 + 11232.00 sec
21-May-2013 11:11:34 [---] [work_fetch] --- project states ---
21-May-2013 11:11:34 [The Lattice Project] [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
21-May-2013 11:11:34 [superlinkattechnion] [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
21-May-2013 11:11:34 [MindModeling< at >Beta] [work_fetch] REC 0.000 prio 0.000000 can't req
work: suspended via Manager
21-May-2013 11:11:34 [Constellation] [work_fetch] REC 24.318 prio -0.000000 can't req
work: "no new tasks" requested via Manager
21-May-2013 11:11:34 [Docking] [work_fetch] REC 70.270 prio -0.053371 can req work
21-May-2013 11:11:34 [malariacontrol.net] [work_fetch] REC 35.233 prio -0.053520 can req
work
21-May-2013 11:11:34 [rosetta< at >home] [work_fetch] REC 28.369 prio -0.055149 can req work
21-May-2013 11:11:34 [correlizer] [work_fetch] REC 27.663 prio -0.055464 can req work
21-May-2013 11:11:34 [eon2] [work_fetch] REC 14.738 prio -0.055967 can req work
21-May-2013 11:11:34 [World Community Grid] [work_fetch] REC 275.469 prio -0.059589 can
req work
21-May-2013 11:11:34 [NumberFields< at >home] [work_fetch] REC 15.186 prio -0.060085 can req
work
21-May-2013 11:11:34 [SZTAKI Desktop Grid] [work_fetch] REC 15.104 prio -0.063915 can
req work
21-May-2013 11:11:34 [boincsimap] [work_fetch] REC 32.650 prio -0.070539 can req work
21-May-2013 11:11:34 [ibercivis] [work_fetch] REC 14.749 prio -0.074577 can req work
21-May-2013 11:11:34 [fightmalaria< at >home] [work_fetch] REC 10.813 prio -0.082123 can req
work
21-May-2013 11:11:34 [Asteroids< at >home] [work_fetch] REC 16.048 prio -0.093301 can req work
21-May-2013 11:11:34 [Milkyway< at >Home] [work_fetch] REC 11.449 prio -0.180597 can req work
21-May-2013 11:11:34 [NFS< at >Home] [work_fetch] REC 28.673 prio -0.217775 can req work
21-May-2013 11:11:34 [LHC< at >home 1.0] [work_fetch] REC 35.037 prio -0.266106 can req work
21-May-2013 11:11:34 [Poem< at >Home] [work_fetch] REC 4056.596 prio -3.851261 can req work
21-May-2013 11:11:34 [SETI< at >home] [work_fetch] REC 2544.520 prio -5.105209 can req work
21-May-2013 11:11:34 [Einstein< at >Home] [work_fetch] REC 4200.380 prio -8.210770 can req work
21-May-2013 11:11:34 [PrimeGrid] [work_fetch] REC 1403.029 prio -10.714000 can req work
21-May-2013 11:11:34 [---] [work_fetch] --- state for CPU ---
21-May-2013 11:11:34 [---] [work_fetch] shortfall 9834.29 nidle 0.00 saturated 85205.71
busy 0.00
21-May-2013 11:11:34 [The Lattice Project] [work_fetch] fetch share 0.000
21-May-2013 11:11:34 [superlinkattechnion] [work_fetch] fetch share 0.000
21-May-2013 11:11:34 [MindModeling< at >Beta] [work_fetch] fetch share 0.000
21-May-2013 11:11:34 [Constellation] [work_fetch] fetch share 0.000
21-May-2013 11:11:34 [Docking] [work_fetch] fetch share 0.124
21-May-2013 11:11:34 [malariacontrol.net] [work_fetch] fetch share 0.062
21-May-2013 11:11:34 [rosetta< at >home] [work_fetch] fetch share 0.050
21-May-2013 11:11:34 [correlizer] [work_fetch] fetch share 0.050
21-May-2013 11:11:34 [eon2] [work_fetch] fetch share 0.025
21-May-2013 11:11:34 [World Community Grid] [work_fetch] fetch share 0.497
21-May-2013 11:11:34 [NumberFields< at >home] [work_fetch] fetch share 0.025
21-May-2013 11:11:34 [SZTAKI Desktop Grid] [work_fetch] fetch share 0.025
21-May-2013 11:11:34 [boincsimap] [work_fetch] fetch share 0.050
21-May-2013 11:11:34 [ibercivis] [work_fetch] fetch share 0.025
21-May-2013 11:11:34 [fightmalaria< at >home] [work_fetch] fetch share 0.012
21-May-2013 11:11:34 [Asteroids< at >home] [work_fetch] fetch share 0.025
21-May-2013 11:11:34 [Milkyway< at >Home] [work_fetch] fetch share 0.006
21-May-2013 11:11:34 [NFS< at >Home] [work_fetch] fetch share 0.012
21-May-2013 11:11:34 [LHC< at >home 1.0] [work_fetch] fetch share 0.012
21-May-2013 11:11:34 [Poem< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:34 [SETI< at >home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:34 [Einstein< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:34 [PrimeGrid] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:34 [---] [work_fetch] --- state for NVIDIA ---
21-May-2013 11:11:34 [---] [work_fetch] shortfall 0.00 nidle 0.00 saturated 98588.67
busy 0.00
21-May-2013 11:11:34 [The Lattice Project] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [superlinkattechnion] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [MindModeling< at >Beta] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [Constellation] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [Docking] [work_fetch] fetch share 0.000 (blocked by configuration
file)
21-May-2013 11:11:34 [malariacontrol.net] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [rosetta< at >home] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [correlizer] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [eon2] [work_fetch] fetch share 0.000 (blocked by configuration file)
21-May-2013 11:11:34 [World Community Grid] [work_fetch] fetch share 0.000 (blocked by
prefs) (no apps)
21-May-2013 11:11:34 [NumberFields< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [SZTAKI Desktop Grid] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [boincsimap] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [ibercivis] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:34 [fightmalaria< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [Asteroids< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [Milkyway< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:34 [NFS< at >Home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [LHC< at >home 1.0] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:34 [Poem< at >Home] [work_fetch] fetch share 0.471
21-May-2013 11:11:34 [SETI< at >home] [work_fetch] fetch share 0.235
21-May-2013 11:11:34 [Einstein< at >Home] [work_fetch] fetch share 0.235
21-May-2013 11:11:34 [PrimeGrid] [work_fetch] fetch share 0.059
21-May-2013 11:11:34 [---] [work_fetch] ------- end work fetch state -------
21-May-2013 11:11:34 [The Lattice Project] [work_fetch] set_request() for CPU: ninst 2
nused_total 0.000000 nidle_now 0.000000 fetch share 0.000000 req_inst 0.000000 req_secs
9834.292685
21-May-2013 11:11:34 [The Lattice Project] [work_fetch] request: CPU (9834.29 sec, 0.00
inst) NVIDIA (0.00 sec, 0.00 inst)
21-May-2013 11:11:34 [The Lattice Project] Sending scheduler request: Requested by user.
21-May-2013 11:11:34 [The Lattice Project] Requesting new tasks for CPU
21-May-2013 11:11:36 [The Lattice Project] Scheduler request completed: got 0 new tasks
21-May-2013 11:11:36 [The Lattice Project] No tasks sent
21-May-2013 11:11:36 [The Lattice Project] No tasks are available for GARLI
21-May-2013 11:11:36 [The Lattice Project] No tasks are available for HMMPfam
21-May-2013 11:11:36 [The Lattice Project] No tasks are available for MARXAN
21-May-2013 11:11:36 [The Lattice Project] No tasks are available for GARLI-GPU
21-May-2013 11:11:36 [The Lattice Project] Project has no tasks available
21-May-2013 11:11:36 [---] [work_fetch] Request work fetch: RPC complete
21-May-2013 11:11:41 [Constellation] [work_fetch] request: CPU (9834.29 sec, 0.00 inst)
NVIDIA (0.00 sec, 0.00 inst)
21-May-2013 11:11:41 [Constellation] Sending scheduler request: Requested by user.
21-May-2013 11:11:41 [Constellation] Requesting new tasks for CPU
21-May-2013 11:11:43 [Constellation] Scheduler request completed: got 1 new tasks
21-May-2013 11:11:43 [---] [work_fetch] Request work fetch: RPC complete
21-May-2013 11:11:46 [Constellation] Started download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870599.7z
21-May-2013 11:11:46 [Constellation] Started download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870599_job_0.10.xml
21-May-2013 11:11:48 [Constellation] Finished download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870599.7z
21-May-2013 11:11:48 [Constellation] Finished download of
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870599_job_0.10.xml
21-May-2013 11:11:48 [Constellation] Starting task
trackjack_hyend_www.hybrid-triebwerk.de_2013-05-19_00_870599_2 using trackjack version
10 in slot 3
21-May-2013 11:11:49 [---] [work_fetch] ------- start work fetch state -------
21-May-2013 11:11:49 [---] [work_fetch] target work buffer: 83808.00 + 11232.00 sec
21-May-2013 11:11:49 [---] [work_fetch] --- project states ---
21-May-2013 11:11:49 [The Lattice Project] [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager (backoff: 592.57 sec)
21-May-2013 11:11:49 [superlinkattechnion] [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
21-May-2013 11:11:49 [MindModeling< at >Beta] [work_fetch] REC 0.000 prio 0.000000 can't req
work: suspended via Manager
21-May-2013 11:11:49 [Docking] [work_fetch] REC 70.266 prio -0.053367 can req work
21-May-2013 11:11:49 [malariacontrol.net] [work_fetch] REC 35.231 prio -0.053517 can req
work
21-May-2013 11:11:49 [rosetta< at >home] [work_fetch] REC 28.368 prio -0.055146 can req work
21-May-2013 11:11:49 [correlizer] [work_fetch] REC 27.662 prio -0.055460 can req work
21-May-2013 11:11:49 [eon2] [work_fetch] REC 14.737 prio -0.055964 can req work
21-May-2013 11:11:49 [World Community Grid] [work_fetch] REC 275.477 prio -0.059586 can
req work
21-May-2013 11:11:49 [NumberFields< at >home] [work_fetch] REC 15.185 prio -0.060082 can req
work
21-May-2013 11:11:49 [SZTAKI Desktop Grid] [work_fetch] REC 15.103 prio -0.063911 can
req work
21-May-2013 11:11:49 [boincsimap] [work_fetch] REC 32.648 prio -0.070535 can req work
21-May-2013 11:11:49 [ibercivis] [work_fetch] REC 14.771 prio -0.074656 can req work
21-May-2013 11:11:49 [fightmalaria< at >home] [work_fetch] REC 10.812 prio -0.082118 can req
work
21-May-2013 11:11:49 [Constellation] [work_fetch] REC 24.316 prio -0.084874 can't req
work: "no new tasks" requested via Manager
21-May-2013 11:11:49 [Asteroids< at >home] [work_fetch] REC 16.047 prio -0.093298 can req work
21-May-2013 11:11:49 [Milkyway< at >Home] [work_fetch] REC 11.449 prio -0.180586 can req work
21-May-2013 11:11:49 [NFS< at >Home] [work_fetch] REC 28.672 prio -0.217762 can req work
21-May-2013 11:11:49 [LHC< at >home 1.0] [work_fetch] REC 35.035 prio -0.266091 can req work
21-May-2013 11:11:49 [Poem< at >Home] [work_fetch] REC 4056.364 prio -3.851031 can req work
21-May-2013 11:11:49 [SETI< at >home] [work_fetch] REC 2545.094 prio -5.106150 can req work
21-May-2013 11:11:49 [Einstein< at >Home] [work_fetch] REC 4200.139 prio -8.210293 can req work
21-May-2013 11:11:49 [PrimeGrid] [work_fetch] REC 1402.948 prio -10.713362 can req work
21-May-2013 11:11:49 [---] [work_fetch] --- state for CPU ---
21-May-2013 11:11:49 [---] [work_fetch] shortfall 9850.97 nidle 0.00 saturated 85189.03
busy 0.00
21-May-2013 11:11:49 [The Lattice Project] [work_fetch] fetch share 0.000
21-May-2013 11:11:49 [superlinkattechnion] [work_fetch] fetch share 0.000
21-May-2013 11:11:49 [MindModeling< at >Beta] [work_fetch] fetch share 0.000
21-May-2013 11:11:49 [Docking] [work_fetch] fetch share 0.124
21-May-2013 11:11:49 [malariacontrol.net] [work_fetch] fetch share 0.062
21-May-2013 11:11:49 [rosetta< at >home] [work_fetch] fetch share 0.050
21-May-2013 11:11:49 [correlizer] [work_fetch] fetch share 0.050
21-May-2013 11:11:49 [eon2] [work_fetch] fetch share 0.025
21-May-2013 11:11:49 [World Community Grid] [work_fetch] fetch share 0.497
21-May-2013 11:11:49 [NumberFields< at >home] [work_fetch] fetch share 0.025
21-May-2013 11:11:49 [SZTAKI Desktop Grid] [work_fetch] fetch share 0.025
21-May-2013 11:11:49 [boincsimap] [work_fetch] fetch share 0.050
21-May-2013 11:11:49 [ibercivis] [work_fetch] fetch share 0.025
21-May-2013 11:11:49 [fightmalaria< at >home] [work_fetch] fetch share 0.012
21-May-2013 11:11:49 [Constellation] [work_fetch] fetch share 0.000
21-May-2013 11:11:49 [Asteroids< at >home] [work_fetch] fetch share 0.025
21-May-2013 11:11:49 [Milkyway< at >Home] [work_fetch] fetch share 0.006
21-May-2013 11:11:49 [NFS< at >Home] [work_fetch] fetch share 0.012
21-May-2013 11:11:49 [LHC< at >home 1.0] [work_fetch] fetch share 0.012
21-May-2013 11:11:49 [Poem< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:49 [SETI< at >home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:49 [Einstein< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:49 [PrimeGrid] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:49 [---] [work_fetch] --- state for NVIDIA ---
21-May-2013 11:11:49 [---] [work_fetch] shortfall 0.00 nidle 0.00 saturated 98573.07
busy 0.00
21-May-2013 11:11:49 [The Lattice Project] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [superlinkattechnion] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [MindModeling< at >Beta] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [Docking] [work_fetch] fetch share 0.000 (blocked by configuration
file)
21-May-2013 11:11:49 [malariacontrol.net] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [rosetta< at >home] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [correlizer] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [eon2] [work_fetch] fetch share 0.000 (blocked by configuration file)
21-May-2013 11:11:49 [World Community Grid] [work_fetch] fetch share 0.000 (blocked by
prefs) (no apps)
21-May-2013 11:11:49 [NumberFields< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [SZTAKI Desktop Grid] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [boincsimap] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [ibercivis] [work_fetch] fetch share 0.000 (blocked by
configuration file)
21-May-2013 11:11:49 [fightmalaria< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [Constellation] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [Asteroids< at >home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [Milkyway< at >Home] [work_fetch] fetch share 0.000 (blocked by prefs)
21-May-2013 11:11:49 [NFS< at >Home] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [LHC< at >home 1.0] [work_fetch] fetch share 0.000 (no apps)
21-May-2013 11:11:49 [Poem< at >Home] [work_fetch] fetch share 0.471
21-May-2013 11:11:49 [SETI< at >home] [work_fetch] fetch share 0.235
21-May-2013 11:11:49 [Einstein< at >Home] [work_fetch] fetch share 0.235
21-May-2013 11:11:49 [PrimeGrid] [work_fetch] fetch share 0.059
21-May-2013 11:11:49 [---] [work_fetch] ------- end work fetch state -------

Why won't Boinc schedule both GPUs?

Charles Elliott — 2013-05-20T13:08:38

I am posting this here because the S< at >H Beta site message board will not let
me create a table.

 

Below you may see a table showing how Boinc scheduled the 2 GPUs in Computer
ID 52900 (S< at >H Beta) last night.  GPU 2 was vacant for most of the night.  My
conjecture is that when Boinc schedules an AP WU on one GPU, which is now
marked as using 0.805C + 1NV instead of the usual 0.02C + 1NV, it leaves the
other GPU vacant, but his does not explain all the rows in the table.  From
a credit per hour standpoint, it might be better to fully schedule the GPU
and let the O/S priority scheme worry about scheduling the CPU; if most of
the processes in the system are at normal priority, and Boinc tasks have a
lower priority, what it does it matter if the CPUs are over-scheduled?

 

Table: GPU Tasks scheduled on Computer 52900 (S< at >H Beta) 5/20/2013 

 


GPU 1

GPU 2



Start Time

Finish Time

WU Type

Start Time

Finish Time

WU Type


GPU GRID WU

GPU GRID WU



5/19 23:29

5/20 1:58

AP

-Infinity

1:53

GPU GRID 


  1:58

2:08

MB

1:58

2:08

MB


  2:08

2:18

MB



  2:18

3:02

AP



  3:02

3:14

MB

3:02

3:14

MB


  3:14

3:25

MB



  3:25

4:00

AP



4:00

4:12

MB

4:00

4:13

MB


  4:13

4:58

AP



  4:58

5:09

MB

4:58

5:09

MB


  5:09

5:21

MB

5:09

5:21

MB


           5:21

5:32

MB

5:21

5:32

MB

 

 

This system downloaded single-digits numbers of GPU WUs virtually every time
it made a server request last night.  At 5:00 AM it had the following WUs in
inventory:

 

MB CPU 168

        GPU 1906

AP  CPU  25

       GPU 578

 

This information posted yesterday on the Beta Site message board may help
clarify the situation.  

 

"BOINC Strange Behavior "

 

"1. Since installing 2 Kepler-class GPUs, Computer ID 52900 has been unable
to download more than a day's supply of WUs, usually there has been less
than a day's supply in inventory.

2. On May 14, the server sent 22 AP CPU WUs (which take about 27 hours
apiece to complete) with only two hours to finish them; they all timed out
and errored out.

3. Last week I suspended all the S< at >H WUs via Efmer's BoincTasks to finish up
the few AP WUs in inventory. Boinc only processed 3 more AP WUs, and then
quit using the GPUs altogether. It would only start using the GPUs again
when I unsuspended the regular S< at >H WUs, which it then processed.

4. At 21:40:00 5/18/2013, with about 1 day's supply of WUs available, all
evenly distributed between AP & S< at >H and between CPU and GPU, when an AP WU
finished on GPU 2 and after a communication with the server returning that
result, Boinc refused to schedule any further work on that GPU; it just left
it idle. I did not notice it until about 13:00:00 5/19/13. I tried
everything I could think of with preferences and cc_config.xml to try to
make Boinc use the second GPU; I even reinstalled Boinc 7.0.62 (replacing
7.0.64), but nothing worked. I could not reboot because I am running a long
experiment that would be impossible to restart except at the beginning.
Finally, at 13:39:00 I resumed GPUGRID and requested some work. When a
GPUGRID WU was finally completely downloaded at 13:52:00, it preempted the
AP WU on GPU 1, and began executing there; GPU 2 was still unused. So I
requested another WU from GPUGRID and it was scheduled on GPU 2. At that
point Boinc went wild with requests for more work from S< at >H Beta. At one time
there were 971 workunits in the transfer queue; I have not seen that for
months. Jealous mistress syndrome? Now I have 306 S< at >H CPU WUs (2 days), 1169
S< at >H GPU WUs (5.4 days), 5 AP CPU WUs (0.7 days), and 423 AP GPU WUs (14.5
days). The day's estimates may be a little fuzzy because of changes in apps,
which affects the average time per WU, but the quantities are exact.

5. Boinc no longer computes the time remaining on a WU by ratio and
proportion after the WU is 50% or even 85% complete based on how long it
took to complete the first part. When an AP WU is 99.99% complete, the GUI
still indicates it has 34 hours remaining." 

 

 

Has anyone at Berkeley ever taken a look at the top-performing computer on
the primary S< at >H site?  This guy has a Core i7-3970X with 12 CPUs and 8
NVidia GTX Titan GPUs; conservatively estimated at retail prices, that is at
least a $9,000 system.  Yet in terms of workunits, he operates always at the
margin.  For example, right this minute he has only 178 workunits in
progress.  Yet he can finish a SETI< at >home V7 MB GPU task in about a minute
and an AP task in about 33 minutes.  On the Tuesday before last, when I last
looked, he was out of workunits, sitting idle almost the entire day.
Imagine his disappointment, if not heartbreak.  Yeah, I know, he's not
complaining.  But is this really what Berkeley intends?  Does this
scheduling situation have anything to do with the new Kepler-architecture
NVidia GPUs, e.g., the absence of a cuda_kepler plan class analogous to the
cuda_fermi plan class?

 

 

Charles Elliott

Make 'receive PM of action taken by moderator' anopt-in option?

Jorden van der Elst — 2013-05-20T01:38:42

Hi David,

Can't we make the 'action taken by moderator' PMs an opt-in option in
the preferences? I have just moved 29 messages between two people,
they'll both be looking at ~14 PMs detailing how I moved their posts
to a new thread. As if they didn't know this, they requested the move
themselves.

I also get PMs when I make a new thread and lock it, rename it,
sticky/desticky it. Normal moderator actions that don't really need
these messages. So, please, can we get a preference that says "Don't
receive PMs on moderator actions on your posts", with the default
being on, but the option to opt-out?

--

Host getting more tasks that limits allow.

Stephen Maclagan — 2013-05-19T16:42:32

There is a Boinc 7.0.64 host over at Setiathome that has at present got 
~2000 GPU tasks,
when it should be limited to 100 CPU tasks and 100 GPU tasks:

http://setiathome.berkeley.edu/forum_thread.php?id=71687

http://setiathome.berkeley.edu/results.php?hostid=6165045&offset=460&show_names=1&state=0&appid=



It's still managing to pick up fresh GPU tasks too, Any idea why?

Claggy

Admin Pages: Result summary per app version

Jon Sonntag — 2013-05-17T23:04:08

If I check the "list unofficial App versions" box I get the error:

Notice: Trying to get property of non-object in
/home/boincadm/projects/collatz/html/ops/pass_percentage_by_platform.php on
line 121 Database Error

at the top of the page and with the listing of the apps:

Notice: Trying to get property of non-object in
/home/boincadm/projects/collatz/html/ops/pass_percentage_by_platform.php on
line 123 Notice: Trying to get property of non-object


I'll dig into it further unless it has already been fixed in a more recent
version.

Jon Sonntag

possible typo in configure.ac

Toralf Förster — 2013-05-16T17:40:02

/me wonders if here's an unwanted "x" :

AM_CONDITIONAL(ENABLE_MANAGER, [ test "x${ac_cv_have_wxwidgets}" = xyes


BTW is still wxwidgets version <= 2.8.x required ?

The ways in that BOINC tells app to quit

Raistmer the Sorcerer — 2013-05-10T23:46:24

 Trying to solve non-suspending issue listed in this thread:  http://setiathome.berkeley.edu/forum_thread.php?id=71581&postid=1365551
I came to conclusion that either BOINC does something wrong in this situation or app doesn't check all needed flags and not aware about exit request.

I check these flags:
boinc_status.quit_request
boinc_status.abort_request

Maybe some another flag BOINC sets to inform app that suspend required ? 
_______________________________________________
boinc_dev mailing list
boinc_dev< at >ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

GPU and service under Windows

2013-05-10T16:44:39

We are considering using BOINC in an enterprise environment so I'm trying
the configure the client to be as invisible as possible to the user and
the only way I found was to install it as service (Protected application
execution) and uncheck "Allow all users on this computer to control
BOINC". It works well for our CPU application except we can't use the GPU.

Is there another to configure the BOINC client to be 'invisible' to the
user and have access to the CPU?

Thanks

Seb

Workunits no longer usable

Charles Elliott — 2013-05-07T14:08:23

Hello:

 

                The S< at >H Beta site just released a new executable for plan
class cuda50.  For some reason the 

beta server does not recognize plan class cudaNN  (NN = 50, 42, 32, 22,
etc.); it  will only deliver WUs to 

a computer whose app_info file contains plan class cuda_fermi,
opencl_nvidia_100, etc.  So just as I 

had done when cuda42 came out, I changed all the references in these plan
classes from cuda42 to cuda50.  

I copied the Boinc data directory to a different hard disk, shut off the
network, and restarted Boinc.  

This was at 20:55:31.  Everything appeared to be working: Boinc deleted no
WUs, was using the new 

cuda50 executable to process the WUs it had, and communication with the
server proceeded normally, 

at least 10 times.  Then at 22:34:13, almost 2 hours after the change,
Boinc, the server, whatever, decided 

to delete about 5,000 WUs, saying "Result 01mr13ab.6367.7433.11.16.27_2 is
no longer usable," etc.  

There is no error message, absolutely no hint as to what is wrong.   Now  a
computer that processed 790 

WUs yesterday has only 501 WUs total, some of which are Astropulse, so my
statistics program says I have 

about 0.91 days' supply.  The server says I have exceeded my quota of 35
WUs/day (35???) and won't give me 

any more, and sometime in the middle of the night it decided "Your
app_info.xml file doesn't have a usable 

version of SETI< at >home v7."  It is Tuesday, the server will be down all day,
and it will be sometime late in the 

evening before I can download any more WUs.

 

                Several weeks ago a similar incident happened.  I was
carrying something heavy and bumped into the 

computer that was processing S< at >H WUs.  Boinc must have been writing the
client_state file at the time because 

it was clobbered and Boinc would not run.  For some reason client_state_prev
was unacceptable also.  I make a 

copy of the client_state file every time a WU finishes.  I do that because
my statistics program was having trouble 

finding out which GPU the WU was processed on, and I needed to see what
client_state file it was looking at.  

Thus I have a month's supply of client_state files for every computer.  So
to fix the clobbered client_state file, 

I took the one from the previously finished WU - it was literally seconds
old - and used it to replace the clobbered 

client_state file.  Boinc objected and flushed all the WUs.  

 

                There are three facts of which you are obviously unaware:

 

1.       It is intensely humiliating to experience the loss of thousands of
workunits, especially after one has spent hours trying to avoid that exact
situation, and after taking exactly the same actions that had avoided that
loss previously.

2.       You could not realize how much we users have invested in S< at >H.
First, it costs about $70 a month to process S< at >H WUs on a computer with a
modern CPU and two medium-sized GPUs.  Second, it takes about one-half to an
hour a day to check each computer to see that it is operating OK.  Third,
there is a huge emotional investment in competing for credits that have no
extrinsic value, which is compounded by the fact that, for whatever reason,
S< at >H is not analyzing the data we return to it; there have been no results
published since about 2007, that I know of.  So yeah, we fight tooth and
nail for workunits and credits because there is no other measure of progress
and success.  S< at >H is not a no-holds-barred, all's fair war between users and
the server; it is supposed to be a cooperative venture to find evidence of
extraterrestrial life.

3.       Up until about the 1920s the United States was a Christian country.
While it may seem unfair, until the 20's if a person did not understand the
Christian paradigm, he or she simply could not compete.  That changed in the
30's, in part, I believe, because as a highly industrialized country and a
world leader we had to change the societal emphasis from religion and
ethical behavior to technological competence.  Nevertheless, under the
Christian paradigm when a person makes a mistake God no longer sends a
plague of locusts, huge floods, or asks for a human sacrifice; under the new
deal, He sends a message telling the person what is wrong and how to fix it.
If you want to see this exact same point in secular language, then read Dale
Carnegie's How to Win Friends and Influence People. In any case, theology is
the study of God at work in the world.  Successful people no longer destroy,
physically or emotionally, those who err, at least the first few times;
instead they show them how to fix the situation, perhaps change their
behavior, and move on.

 

Flushing all or part of a user's workunits without any clue of the source of
the problem is not evidence of cooperation to find signs of extraterrestrial
life; it is wanton cruelty equivalent to a plague of locusts or a flood.  It
does not solve the problem. 

 

When Boinc perceives the necessity to flush thousands of workunits, why
can't it be made bright enough to understand that this is not a result that
benefits anyone, not S< at >H, not Berkeley, and certainly not the user?
Instead, why can't Boinc output a (long) message saying what its problem is,
post the detested OK-Cancel dialog box, and just wait for input?  I would
much rather come down in the morning to a computer that has done nothing
useful all night than to a computer with all but about 10% of its workunits
wasted (for all to see).  Yes, it is true that the novice user will not
understand either a (long) message or the need to intervene.  But it is also
true that a novice user is unlikely to edit his or her app_info file.  In
any case, it is kinder to give even a novice user the opportunity to fix the
problem than it is to punish them for an action that was almost certainly
well intended.

 

 

Charles Elliott

ASIC miners

Henri Heinonen — 2013-05-05T10:10:47

Hi!

Are you planning to support Bitcoin ASIC miners? (
http://www.butterflylabs.com/ )

At the moment I'm trying to use Wrapper method to BOINCify Bitcoin GPU
miners, but I still haven't figured it out...

Henri.

Boinc and XPM files problem

Gianfranco Costamagna — 2013-05-04T09:54:56

Hi All, don't know if makes sense to report to you this problem.

Your xpm res files starts with the copyright comment
// Berkeley Open Infrastructure for Network Computing

[...]

// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA


Many programs doesn't find when looking for the xpm resource

quoting the mail from Rodrigo Silva
header. So they don't thumbnail, no editor besides eog cannot open them, etc.

This is why in debian I accepted a patch for switching between xpm to png files
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commit;h=83a343230bf609e29cf74e73d02107dd718fa6c9


Don't know, the solution might be put the copyright at the bottom?
Converting to png too?

Just reporting the problem


Gianfranco

php warning messages

Eric Driver — 2013-05-04T01:57:29

Hi all,

 

I recently upgraded the NumberFields project to the latest branch
(boinc-v2).  I am now getting a bunch of warnings on the admin pages like
the following:

 

"Warning: Creating default object from empty value in
/home/boincadm/projects/NumberFields/html/inc/db_ops.inc on line 520"



I can turn off these warnings in the php code by using error_reporting(), in
which case the site acts just like it used to.  But are these warnings
telling me there is a problem somewhere in the php code, and if so does
anyone know how to fix this?

 

Thanks in advance!

Eric

twitter bootstrap and boinc

Francisco Sanz García — 2013-05-03T09:18:13

Hello

I'm working on the php pages of BOINC using twitter bootstrap. You can have
a look to the status at http://alfa.ibercivis.es/ibercivis_alfa/index.php,
(not fully functional yet).

I read in the list that some people worked in this issue  time ago, do you
know something about that?

I´ll publish the code in github when finished

Un saludo

Francisco

Scheduler returns "No end tag"

Nx Hien — 2013-05-02T19:09:23

Hello everyone,

Our project recently upgraded our 2010 BOINC server to commit 2091b257876cfdc4f12fedc0f2a1116f1c85cd8f and now when processing requests from clients, our server often says:

SCHEDULER_REQUEST::parse(): unexpected: ...a part of our result's stderr...
Incomplete request received from IP ......


And the message "no end tag" is displayed on the client's UI.

I am wondering if  this error is related to the size of our task's stderr because our task does produce a remarkably large stderr but this error didn't happen to us when we used our 2010 BOINC server source code. 

Any help would be very much appreciated.

Best regards,

automatic minimum buffer size.

McLeod, John — 2013-05-01T13:31:39

I have been thinking about what the appropriate automatic sizes for work fetch and EDF trigger are for work fetch and for EDF for rr_sim.

If we track the longest duration (over the past N months) from the first time that a task reports as 100% complete till report is complete pre project, then:

The minimum required work buffer is the smallest of these across all projects able to fetch work.  Eg.  Project A has a 1 week value, project B has a 1 hour value, the minimum work buffer would be 1 hour.

For each project, any task that exceeds report deadline for the task - the longest durataion from 100% to report complete needs to be marked as requiring EDF.

It would also be useful if the projects could have a tag that could be set to indicate they expected to be offline for N seconds (probably entered as days and converted to seconds).  The maximum of this and the largest duration already recorded would be used for this.

For example, SETI would normally have this set to 0.4 days to indicate the weekly outage.  Occasionally SETI could bump this number to allow clients to cope with expected longer outages.  Yes, unexpected outages would not be helped by this.

rr_sim and work fetch

McLeod, John — 2013-05-01T13:08:51

I recently posted a simulation that misbehaved because of short comings in the rr_sim function.  The problem in that case was that there was a single CPU task that was running high priority (as it should), and a multi CPU task that was longer than the minimum work buffer.  The problem is that the client will not in that case download any work from anywhere to fill the CPU that is idle.

One possible solution:

Run rr_sim in multiple passes, and track high priority tasks.  Track High Priority tasks and when they will complete.  Assume that once a task is high priority, it stays that way until complete (OK, not true in all cases, but I am trying to avoid the expense of an even more accurate method).

Pseudo code.
Run rr_sim - this marks tasks as requiring EDF or not.  Set a flag indicating if any new tasks were marked as EDF by rr_sim.
Use the results to supply information to a new function that simulates EDF for the tasks that are marked as requiring EDF.  The output of this feeds back into rr_sim.  Rr_sim now has to cope with a staggered start for the remaining Non High Priority tasks.  Multi CPU tasks would not be allowed to start until such a time as sufficient CPUs were available.  Exit the loop when all CPUs are busy with EDF work for minimum work  buffer time.  Gaps is information about forced  gaps due to EDF tasks and multi CPU tasks.  When done, thee will be information about saturation of all CPUs and forced gaps up the minimum work queue.  This can be used to generate appropriate work fetches.

Pseudo code:

Structure gap
{
                Double duration;
                Double start_time;
                Int n_cpus;
}

Initialize tasks for a new rr_sim run
Bool newTasksMarkedEDF = false;
Double CPUSEDFBusyTill = now();
Double * CPUEDFBusyArray = new double(n_cpus);
Initialixe CPUEDFBusyArray to all 0;
Std::array<gap> gaps;
Do
                {
                                newTasksMarkedEDF = rr_sim(CPUEDFBusyArray, &gaps);
                                if (newTasksMarkedEDF)
                                                CPUSEDFBusyTill = edf_sim(CPUEDFBusyArray, &gaps);
                }
While (newTasksMarkedEDF && CPUSEDFBusyTill < now() + min_work_buf)

Run time analysis:
Best case:  No tasks needing EDF - single run of rr_sim.

Typical case ought to be a handful of runs through the loop.  We might want to cap the number of runs though as:

Worst case:  One run of each per task.

NOTE:  Projects would be marked with the number of tasks that need to run EDF by rr_sim. Edf_sim and rr_sim both get shorter on each run as any task already marked as consumed by edf_sim would not need to be inspected again.  It is already in the EDF array someplace.  Both edf_sim and rr_sim can note a forced gap due to EDF requirements.  In both cases, it would be because there was not enough work of a low enough count of CPUs to fill the hole.

Obtaining up to date BOINC sources - not trivial task. Should it be so?

Raistmer the Sorcerer — 2013-04-29T19:50:02

 I'm trying to implement Charlie Fenton suggestions about SETI OpenCL apps and rebuild versus latest BOINC API.

Well, update via TortoiseSVN can give only last year revision. Not too nice but OK, time to learn new ways.
But, looking for help on BOINC main page for some instructions and link for BOINC sources. No links to sources.
Links to binaries, links to statistics, links to message boards and so on and so forth... but no link to sources!
it's direct violation of GNU license linked at the bottom of page, not?
Or should I E-mail one of BOINC devs each time I will need link to source?

IMO such front page design is flaw that needs attention. Open source project should not hide link to its sources but advertise it everywhere it can.
And even better if link would come with some instructions how to obtain sources (archived tree of last stable release for example?). 

 
_______________________________________________
boinc_dev mailing list
boinc_dev< at >ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.