The scheduling-server doesn't directly check the database if any work is available since this would be inefficient and put larger load on database. Instead it's checking the feeder-array. The feeder-array has a limited number of tasks it can store at a given time, and this can be configured to example max have 100 for each sub-project. After each time feeder-array has been re-filled with work, it will take some time before it will be re-filled again. Meaning, if "too many" users has asked for only HFCC-work, it's possible no HFCC-work is available in feeder-array then it's your turn to get work, and therefore you'll get "other work" instead since you've allowed this. Now, chances are the feeder-array is re-filled with HFCC-work a second later on, but this will be after you've gotten work and has left.

TPCBF,

Those who've had set their profile to HFCC exclusive, without the "alternate" option had priority in the work fetch. In the event there were non in the shared memory, as explained having a limited number of slots, those clients would just back off and try later. In your case, if all slots were designated to other sciences, that rule would have kicked in. The longer a project runs on low or slow priority, the more likely it is that dedicated crunchers will deselect the 'alternate' to get the last job.

Whilst you wrote that ''the last 2 days'', this is not what the techs wrote. HFCC full supply was not put back on until later, yesterday [Oct 27, 2011 8:29:00 PM ] per post by seippel.

At any rate, flukes happen, but we do recommend for anyone who's on single science as main to keep that 'alternate' selected. Better your computer is on and doing something useful than doing nothing. ;-)

Thanks for choosing WCG to crunch and crush.

--//--

The hi minimum spec check would prevent for a CEP2 job to go to a P3. To go, if a device has 1GB ram but is only allowed to use 50% when in use, I'd imagine, that the servers would not assign such a task. I've never tried to confirm if this is really the case, but given that I've had instances where the actual available disk space was below requirement [2GB], seen CEP2 requests being rejected, even though I'd said BOINC could use 10GB. All other sciences kept coming in the meantime.

--//--

Ergo, hint hint, if that were a concern, set it to a percent that CEP2 would not come in any case... is the WCG default not 75% (of the true free)? Think you found that though 1GB is specified, the real check is if 750MB allowed and available. The sum of all other sciences on a duo would not get close to that 750MB restriction on a duo, let alone a P3/P4. Then, if the combined running tasks would take more than the allowed, one or more job would be paused until the crunch had subsided and given the 'idle' I'd not think it to be a major issue.

--//--