Probably more to do with BOINC than the beta task's but BOINC is favouring processing normal tasks over beta taks. I.e. tasks are ordered by deadline, beta's go straight to the top having a shorter deadline. However BOINC continues to crunch down the list of regular tasks. Guess I assumed that the list ordering had an effect on the process order, this is not the case?

Think that a BSOD report and this case is pure coincidence. Same science application as used for the first 26 million tasks processed for this research, probably the exact same compound database against which the tests are run. Got 8, 4 of which just arrived without knobbing the device profile, all valid, processing in under 4 hours each.

Mind you, the AutoDock based sciences credit remains dog-days on Linux, so I'm continuing to live with the feeling that my 64 bit quad client is just not fit to process these tasks efficiently. Think I need a cold cold cold beverage.

As martin64 indicates, BOINC principally processes LILO (an old joke played on an 'certified' auditor who spent half a day figuring out what I said). When there is panic state, the client switches to EDF (Earliest Deadline First). That latter state can easily develop when there is too much cache, cache beyond the shortest deadline, so if you run like I do with just 0.9 days, you rarely see that condition unless the DCF (Duration Correction Factor) is really blown up due to one or a few tasks that took multiples of the original estimated run time.

There's something special about the beta feed. It ignores some rules... e.g. does not look at the recent return time history. If the beta box is ticked and a client asks for work at WCG, the first pipe checked is the beta one. No reliability rating is considered... after all the sample test should include good mix of all devices to check if things break.

When running a pumped cache to hold for instance 6 days and receiving a Beta with 4 day deadline the client will at some point in time go into EDF state, to the point that some will get server aborted because these were not returned quick enough. Aborted tasks are a demerit on the reliability rating, another reason for a number of crunchers who like to get the high priority tasks to keep the cache at the WCG ideal of under 2 days.

So far this loose injection.

Happy crunching.

I tried 'pumping' cache this time to 3 days, but this tactic did not work. There must be some kind of clever counter that just won't let you download more than a 1 day of work at any given time. I could tell if the limit on my hosts has been reached or not just by looking for this message.

Message from server: (there was work but it was committed to other platforms)

When I saw it, then I knew that there were more BETA work-units available for the host, and the limit has not yet been reached. Once the message had disappeared, then I knew that unless my host can upload back processed BETA tasks, there won’t be any more BETA work units for this PC.

Sekerob, are you saying that the beta is basically already done? All WU were sent out already and almost all of them were sent back?