It would be quite nice to be able to get a bigger feed of these tasks, but as fast turn-around is important I'm not sure about whether a significant change in feeding would be a good idea.

About 8% of the 50000 step jobs I'm getting are resends because the first recipient has timed out, Sometimes, the first retry has also timed out (so that's a 48-hour delay)! And I'm even seeing about 1% resends-on-timeout for the 10000 step jobs, so some folks probably have quite large buffers or are running less than 24/7 and even the one-per-core limitation isn't working out...

On the larger jobs, "timed out" has passed "Error - a required privilege is not held" as the major source of retries that I'm receiving!

As there are now (it seems) two identical sets of tasks, one all 10000-step, the other all 50000-step, it might be interesting to find out how many retries are needed for each size of task! If, as I suspect, the number of timed out tasks has risen significantly for the longer tasks, I don't know how they can strike a fair balance between keeping faster crunchers fed and avoiding larger numbers of 24-hour delays because of time-outs.

Can guess the reason to the one-per-core-thread plus 1 quota, but explaining the thinking to the less 'in' would help to make it understood to all.. Certainly would recommend to set the <report_result_immediately/> flag in app_config.xml for fahb to get the swiftest backfill, if so desired. Does require the newest client, i.e.not the WCG skinned.

Easy to overcome BTW, just fake having ncpus+1 in cc_config.xml, then set app_config.xml to max_concurrent with the true thread count, if only doing this science. Of course in time the 1 extra will have aged about half of the average runtime before starting, i.e. Not a good idea for slower devices.

If 64 is the observed hard limit per client, then no amount of tricking will get you more, but to set up 2 concurrent clients

Currently have 1 per core +1 of WUs since the update.

Patrick