Greg,

Please understand, if you increase the buffer it's a one time forced request. If at that exact moment there is no beta work, you get regular work. But, every request checks for beta first, provided the beta program and relevant device profile is associated.

widdershins,

this "all over the place" is all by design and depends on the number of positions included in the parent results and children and their toughness. See announcement

1. Run 4 CPU hours and test for 60% of total positions completion. If less progress (you cant see that), finish current position and pass remaining positions to new child result.
2. If run 4 hours and progress > 60%, continue on to finish, but stop with the position if it goes over 8 CPU hours. Remaining positions not computed passed to child.
3. Any results that have a 12345-12675 like suffix are child/grandchild results. They should follow the same 1/2 rule, except if these are very tough positions. They will run as long as it takes to finish the position.

My first results on Windows.Mes premiers résultats sur Windows.

BETA_CMD2_0006-2A5AA.clustersOccur-ACADM.clustersOccur_29

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<stderr_txt>
INFO: No state to restore. Start from the beginning.
Finishing early because max runtime has been exceeded.14403.078125
called boinc_finish

</stderr_txt>
]]>

BETA_CMD2_0006-2A5AA.clustersOccur-ACADM.clustersOccur_4

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<stderr_txt>
INFO: No state to restore. Start from the beginning.
Finishing early because max runtime has been exceeded.14401.093750
called boinc_finish

</stderr_txt>
]]>

Bye

Smart men RTFM before before knobbing.

The runtime exceeded stop is the design. The HCMD2 tasks are meant to stop by completing the position on hand when the 60% of total positions in the task has not been reached at the 4 hour CPU mark... 14,400 seconds ;>).

PS, a work fetch is limited to 15 tasks, so going from 0.3 days (think that's the default), to 10 days (way too much and almost guaranteed to cause a high priority / earliest deadline first panic state), will do multiple requests on a duo or quad, depending on their known speed of course. High priority processing on all cores causes immediate work fetch stop until the condition normalizes.

One more for Kevin or amrstrdj,

Does this beta version also have improved "progress counting" logic as discussed in other thread v.v. tough positions?

Got 109 Beta WU. 87 Valid, 10 PV, 12 IP

edit; updated counts