I think a 31 second project update frequency is too often. I recommend something in the order of 2 minutes or 3 minutes. I have a NVIDIA RTX 5070 Ti the fastest turnaround of task is over 3 minutes. The several RX9070XTs are over 4 minutes. And there are always a few queued up. The CPUs tasks on a 9950X run over 80 minutes. A turn update request of 31 seconds (windows) means there are a lot of 1 finished task reported and 1 new task downloaded.

A 121 second project update rate is what WCG (World Community Grid) uses.

Seems like a longer update rate from clients would lower the server (and client) loads, lower network traffic, etc would be better.

Tomorrow I will pop into the top 100 contributors with over 54million credits. Not bad for a southern AZ person helping a ASU project. :)

Thank-you for your kind consideration in advance.

I guess it couldn't hurt to increase it. I can always put it back if there's an unforeseen consequence.

I think a 31 second project update frequency is too often. I recommend something in the order of 2 minutes or 3 minutes. I have a NVIDIA RTX 5070 Ti the fastest turnaround of task is over 3 minutes.

So a RTX 5090 will knock them over in around 1min 30 sec or less.

A 121 second project update rate is what WCG (World Community Grid) uses.

WCG's seutup could best be described as "extremely fragile."
Not to mention a few hundred thousand more users (and even more systems) than here.

Seems like a longer update rate from clients would lower the server (and client) loads, lower network traffic, etc would be better.

That tends to only be in the case of when recovering from an outage.
The rest of the time the BOINC manager on the clients does incremental increases in the delay before re-trying when it encounters a project server/network error.


The 30second server backoff stops clients from being set to hammer the server every few seconds to try to get work if the supply of work is limited and their cache is low, but allows them to re-fill their caches quickly when work is readily available.
eg after project/network outages.

Given the reliability of work here, i doubt increasing the server timeout delay will have much if any effect on it's load, but it will mean that it'll take a few extra tries before those with large caches can re-fill them after an outage.
And it will significantly increase the time it takes for everyone to return and report and get new work when there are connection issues occurring (eg when there are challenges on).

---

Grant
Darwin NT, Australia.

I see the change to project update frequency has already been changed to 121 seconds. I will be fun to monitor the effect. I have one machine running a mix of NumberFields and WCG. The balance between tasks downloaded and running is better. The other 4 machines with 9950Xs are dedicated to NumberFields.

I guess it couldn't hurt to increase it. I can always put it back if there's an unforeseen consequence.

If the server has no problem it's not necessary to change something I think.
However, it is probably a good option for competitions with high server load.

I guess it couldn't hurt to increase it. I can always put it back if there's an unforeseen consequence.

If the server has no problem it's not necessary to change something I think.
However, it is probably a good option for competitions with high server load.

That was also my thinking - it might help during the competitions. The change was made and so far no noticeable difference on either the manager or server. We will need to wait to see what happens during a competition.