Well, me quad got 5 of CEP2 Beta last night and cannot see in log it downloading the science apps such as the 2x qcaux, just the small task zips and they don't take even a second.

--//--

10448 WCG 07-07-2011 23:32 [sched_op_debug] Starting scheduler request
10449 WCG 07-07-2011 23:32 Sending scheduler request: To fetch work.
10450 WCG 07-07-2011 23:32 Requesting new tasks
10451 WCG 07-07-2011 23:32 [sched_op_debug] CPU work request: 147868.04 seconds; 0.00 CPUs
10452 WCG 07-07-2011 23:32 Scheduler request completed: got 3 new tasks
10453 WCG 07-07-2011 23:32 [sched_op_debug] Server version 601
10454 WCG 07-07-2011 23:32 Project requested delay of 11 seconds
10455 WCG 07-07-2011 23:32 [sched_op_debug] estimated total CPU job duration: 93507 seconds
10456 WCG 07-07-2011 23:32 [sched_op_debug] Deferring communication for 11 sec
10457 WCG 07-07-2011 23:32 [sched_op_debug] Reason: requested by project
10458 WCG 07-07-2011 23:32 Started download of 8e9c7abe1d7de639a427e8842ff87590.zip
10459 WCG 07-07-2011 23:32 Started download of BETA_E202699_905_A.25.C21H14N2SSe.305.3.set1d06_A.25.C21H14N2SSe.305.3.zip
10460 WCG 07-07-2011 23:32 Finished download of 8e9c7abe1d7de639a427e8842ff87590.zip
10461 WCG 07-07-2011 23:32 Finished download of BETA_E202699_905_A.25.C21H14N2SSe.305.3.set1d06_A.25.C21H14N2SSe.305.3.zip
10462 WCG 07-07-2011 23:32 Started download of 2c213fbe6cb0e58efa890cc36b0d5f46.zip
10463 WCG 07-07-2011 23:32 [cpu_sched] Preempting E202607_684_C.26.C20H12N2OS2Si.00773003.1.set1d06_1 (left in memory)
10464 WCG 07-07-2011 23:32 Starting BETA_E202699_905_A.25.C21H14N2SSe.305.3.set1d06_1
10465 WCG 07-07-2011 23:32 [cpu_sched] Starting BETA_E202699_905_A.25.C21H14N2SSe.305.3.set1d06_1 (initial)
10466 WCG 07-07-2011 23:32 Starting task BETA_E202699_905_A.25.C21H14N2SSe.305.3.set1d06_1 using beta11 version 640
10467 WCG 07-07-2011 23:32 Finished download of 2c213fbe6cb0e58efa890cc36b0d5f46.zip
10468 WCG 07-07-2011 23:32 [cpu_sched] Preempting c4cw_target04_039925401_0 (left in memory)
10469 WCG 07-07-2011 23:32 Starting BETA_E202699_907_C.25.C23H14SSe.00023461.0.set1d06_0
10470 WCG 07-07-2011 23:32 [cpu_sched] Starting BETA_E202699_907_C.25.C23H14SSe.00023461.0.set1d06_0 (initial)
10471 WCG 07-07-2011 23:32 Starting task BETA_E202699_907_C.25.C23H14SSe.00023461.0.set1d06_0 using beta11 version 640

You can cc_config the number of allowed DLs, Overall and per-project.

Corr. to me previous post, got 7. Two had finished while in REM state, about 8:25 hours CPU time each. 4 Concurrent due the HP state is a bit to much for the old clunker, so an extra 20 minutes went to Elapsed.

--//--

Here's the cc_config.xml manual and options/log flags available. Specifically, you'd have to introduce either of the 2 below:

<max_file_xfers>N</max_file_xfers>
    Maximum number of simultaneous file transfers (default 8). 
<max_file_xfers_per_project>N</max_file_xfers_per_project>
    Maximum number of simultaneous file transfers per project (default 2). 

For longer I've had it on 3, but be aware, that the more concurrent DLs, the lower the measured speed will be by BOINC and that could jeopardize what the servers will send. Someone up in this thread had trouble getting FAAH, not meeting the min. requirement for that science.

Note that newer settings have a version number as of which client the code is functional. Seen a few flags mentioned recently [by skgiven] such as <heartbeat_debug> but these are not there, yet!

--//--

I have observed some strange behaviour when changing Current Assigned Device Profile on the WCG site. I have been using Device Profiles to allow me to allow me to quickly switch between a 'beta-friendly' profile and a 'my-default' setting.

Monitoring messages with BoincTasks and also with the Messages module in Boinc Manager, I can confirm that the new profile has been adopted by the individual device.

My observation is that on one machine after I had made the change in Current Assigned Device Profile, subsequent reports in Messages showed that the 'new' profile appeared not to have been adopted.

In an attempt to not waste processing times (several modules sitting at 5-minute checkpoints), I decided to just let the device continue processing. The 'new' profile continued to be ignored for over an hour before I saw that it was now being shown

08/07/2011 13:51:31 General prefs: using separate prefs for school

I am glad that the 'problem' fixed itself, but cannot understand why it took so long on this 1 machine.

I cannot see in any of the xmls where this pref setting might be found, so am presuming that the data is passed directly from the WCG servers.

1 Is this assumption correct, or have I overlooked something?

2 Can you think of what could have caused this glitch when usually a change in profile is almost automatically shown in Boinc Manager Messages?

Sometimes the messaging system that tells the scheduler according which profile to assign work falls behind. It IS important that if you want the client to operate according website settings [The non-science selection parts of the device profiles], you clear the local prefs.

''Reading in Local Prefs" is ancient and left there for those who manually edit the global_prefs_override.xml file [overrides ALL profiles]. Using the GUI of BOINC Manager will loose these edits once you hit OK in the interface. If you don't want to save them, cancel out or hit clear to let the website settings take charge.

Obviously, if the client has not communicated to the servers, it wont know about the new profile assignment. Locally hacking the locations xmls, wont change what the servers know.

In a nutshell

--//--

edit:

Addendum. Occasionally there are complaints about still getting more or different work than that what was set... e.g. changing cache from 2 days to 1 day. When the client requests work subsequent to a profile change, but prior to having communicated to the servers, the client would only know of the 2 day cache setting and the profile it's was lastly assigned to e.g. work. It takes a full communications cycle ** before the new prefs completely kick in. When reducing cache via the web profile or changing profile with project selections, it's best to temporarily suspend work fetch, then hit update, then allow work-fetch again.

Generally though BOINC is not designed for micro-managing... it's set and forget! Already it's got way way way too many knobs IMNHO.

** Clarification: "Full communication cycle" meaning after having made a change to the web profile or changed profile or project selections the client needs to first fetch the new preferences from the server, then any subsequent server connect/request will be under the new profile/preferences i.e. such things as work fetches, volume and science. When Local preferences are changed, they take immediate effect and override web-prefs until cleared [all prefs], except for a few that don't until the client is restarted or a new task starts (write to disk e.g.). Local prefs do not affect the science selections, but bandwidth restriction e.g. would/could. E.g. if FAAH requires 128 kbps and the limit is set to 64kbps, they'd not be send with a warning in the event/message log.