I didn't chose anything other than the number of threads on a machine I purchased. All other limits are forced on me.UBT - wbiz wrote: ↑Sat Mar 09, 2024 5:37 amTrue! But again that is your chosen strategy which is highly beneficial in many instances but less so in other circumstances. However, I can't understand their rational for a 400 limit, especially as they have a reasonably long deadline.entity wrote: ↑Sat Mar 09, 2024 3:55 am Unfortunately, there are some of us that can't get 2 days worth of work due to the number of threads per machine, the WU runtime, and the 1000 WU BOINC client limit. It is even worse with A@H because they have a 400 WU limit. 400 WUs on a 128 thread machine don't last that long. I guess each contributor has to decide whether it is worth battling all the obstacles.
The 1000 limit is client side and not entirely a hard limit, there are ways round it but I don't know what most server limits are set to, I've been above 1200 on some projects occasionally (by fluke, not by design).
The 1000 limit is a hard limit and hard coded in the client. The reason you get more than a 1000 on some occasions is because the client logic isn't sophisticated enough to totally enforce it.
EXAMPLE: you have 998 runnable tasks on the client and the client now makes a scheduler request. This is a normal request because you are under the 1000 limit. The server returns 200 tasks as a result of the request. You now have 1198 tasks. No more WUs will be fetched until you drop below the 1000 limit. The limit is invoked before the scheduler request not after it. The server sent 200 because it knows nothing about the 1000 client limit. To the server, it was just another client request. The interesting part is 200 WUs were sent because the client asked for that much which goes back to the sophistication of the limit. The client should have only asked for 2 WUs
