Amazing...

I kind of wonder why so many projects seem to be wanting to increase the size of their WUs. I would think it would increase the number of No Reply situations from smaller crunchers out there. But then I know the big crunchers have been getting bigger and bigger and much faster over the past couple years, so it's probably a response to the technological speeds of the newer big guys out there.

So making all the WUs roughly the same size, but bigger, actually balances out the server load better?

I can understand the point of balancing the sizes of the WUs across projects balancing out the servers, but the point that the size of the WUs is doing this balance doesn't make sense. You could get the same balancing if all the WUs were 1/2 the current size or 1/4 or whatever you wanted. So just making the WUs larger, while it might allow for server balancing would I figure just push up the likelihood of No-Replys amoung smaller crunchers out there. But then I'm not setting the sizes, so apparently the bigger sizes seem to be working for now.

When I said "server load technical", I meant server load, where the up-sizing reduces the number of transactions, so col323 got it rightly interpreted. The inter-research balancing is done by controlling the number of work units per science per unit of time that are allowed to go into the feeders. E.g. if there were only HCC at 1 hour average and HFCC at 6 hour average and you want to balance these, than the hopper is given a ratio of 6:1 of HCC versus HFCC. The average run-times drift, so the techs re-balance these ratios on a periodic basis, no particular schedule.

The smaller tasks preference for the part-time crunchers is something WCG is all too aware of, but the stability of the whole supersedes the needs of the individual. As I commented a week or more back, now that the bugs were found and root cause solutions were applied to what was generating the extraneous server loads, it's a matter of time the techs size results back down where they can. Think at the same time, this will be no earlier than after the HCC-GPU application goes into production. Those 4-6-10 minute tasks could add a whole bunch more tension on the transaction system, but that said, the oodles of RAM also added is sure to help in staving off such a overload condition. We'll see and crunch on patiently.