Lavaflow, Let me change the createWork script for FAHB to be randomized as well. This should help normalize the results in host distribution. However it will require us to gather more data after the 7 day test.

Thanks,
-Uplinger

I have continued to have a steady supply of FAHB work units. I am noticing however, that because I keep short queues, due to looking for ARP units, that changing the deadline to 7 days will have zero effect on how long the duration will be between the receipt of a unit and when the unit will be returned. If there is a significant portion of machines which are configured in a like manner, this may skew the results to show no or slight difference. Just a thought.
Cheers

Thanks for the feedback. The reason I think this project works best for capturing the differences is due to the stability of the work units running. Unlike many of the other projects, that could see a change between batches, FAHB is running the same batches with just minor variances in the work units with each generation.

Thanks,
-Uplinger

A couple of suggestions for other things to try, don't know how practical they are, but

a) 7 day deadlines WU's but only sent to machines that manage to complete units within 3 days on average. (Not sure ECG keeps stats on average return times per device). That'd give more leeway in returning so there are fewer resends for devices that return only an hour or two late but without the full penalty of 7 day returns being the norm.

b) run multiple batches at once with 7 day deadlines e.g. 3 so that overall processing of FAH isn't delayed. Instead of waiting for units from one batch to be returned to generate more units there would be 3 on the go in parallel so they would all end up being out of sync, meaning there would always be some batches waiting on units being returned, but some would have just had theirs returned and have generated the next WU's. It would just mean that instead of getting results of batches in a serial fashion 0001, 0002,0003,0004 and analysing one per week, say, the researchers would get nothing for a 3 weeks then get 001-0002-0003, then a 3 week gap and then 0004-0005-0006 would arrive. But they'd be able to analyse the first batches in the 3 weeks gap whilst they were waiting on the next clump to show up. So no time would be lost overall.

As I said there may be technical reasons why it isn't possible, but just throwing a couple of ideas out there.

Just look at results output! Results returned per day cut more than half! If the goal is to speed up the research this is not the way to go! Buffer size don't have much impact on work u will receive for this project. In my case, machines pick up work depends on cores they have. For example, I got 8 taks and they run until finished and FAH2 is set to unlimited work units. When job is done, host simple need to wait for new ones. That is how it's done in my case. Because of limited work I can't have FAH2 running all the time, but it was picked up pretty often before deadline extended.