Beta has priorty over regular wu ONLY at the feeder/download stage, they are normally 4 day deadline and will run in order of download unless there is danger of not finishing in time, HP mode, just like any other wu. Also remember if you have a cache larger than the deadline they will not download at all. Also there is a limit of 1 per core at a time, as you finish you will get replacements IF there are any left

Gandalf_the_Grey, when there are Beta WU's around and you're fortunate to pick up one or more, the ideal thing is (if you can), is to test them under various different circumstances - i.e., stop/start BOINC/your machine(s), making a note of any events that don't look right (e.g., checkpoints not being stored etc.), as well as any other odd eventualities - memory usage etc.

Don't be too surprised if you see a few aborts whilst running Beta's - that's normal and to be expected (after all, it is Beta), and generally, you'll get credited for the work your computer(s) do.

Needless to say, there'll generally be a thread started in the Beta forum where things can be reported back to the techs.

Finally, have fun with Beta's - as that's the first general sign that a new project is on it's way

To complete the information, if ever work is -not- sent because deadlines cannot be met, the below is the typical line that will be printed in the message/event log:


Obviously, a host that runs for instance on 50% throttle or only crunches 8 to 5, will have the first percent much lower. The sampled system is 24/7, where the 98.4% is reflective of things as power outs and boots. These values can always be checked in the client_state <time_stats> section,

<time_stats>
<on_frac>0.972058</on_frac>
<connected_frac>0.984378</connected_frac>
<cpu_and_network_available_frac>0.984171</cpu_and_network_available_frac>
<active_frac>0.996381</active_frac>
<gpu_active_frac>0.996381</gpu_active_frac>
<client_start_time>1371491106.067957</client_start_time>
<previous_uptime>52107.424309</previous_uptime>
<last_update>1371543212.492207</last_update>
</time_stats>

the on fraction deteriorated because we had several multi hour out in the past week, the active frac always close to 100%, because when the comp is on, it crunches.

but we're [me is] wandering off topic.

On topic, Beta original tasks are indiscriminately distributed, no reliability check, no cache check [but for that over-commit condition]. This is because even the non-reliable rated hosts have to be checked in the test mix, to see if they succeed would they get the project work after launch.

There's a BETA FAQ topic in Start Here called 'Beta testing program information' btw, but wizards don't read them before asking ;>)
(Point 3 is needing overhaul... the working of caching in v7 has substantially changed as covered in a discussion topic, which is probably where the misunderstanding came from 'connect every...' no longer exists. Someone could run zero minimum/connect and 7 days Additional buffer... then you'd still get beta's with the v6 client).

edits: 2 to complete the picture.

Rob - Suggestion:
Since Beta testing is not the same as standard WUs, when a new Beta tester signs up, send a test Beta WU through to verify that all the I's are dotted and the T's are crossed.

Can't hurt.