Now would be a good time to check out if a host really needs maxed out work cache anymore...
Absolutely!! For people with large caches, please be advised that the 2004L data file that followed 2003L produces tasks (as mentioned by Oliver) that take the normal time. I have measured one to confirm it.
So, if you have a multi-day cache and haven't changed it, you will have been accumulating 2004L tasks which will be estimated as if they will crunch like 2003L tasks. You will probably have *lots* of them already. You will probably still be crunching whatever you have left of the 2003L tasks and everything will *appear* normal. If you also crunch CPU tasks, you will also be seeing a lot more of those than previously.
If the above description applies to you, your pain and suffering will come when the first 2004L task gets crunched. When finished, it will immediately impose a new and 4 to 5 times larger estimate on *everything* in your cache. As an example, say you had a 3 day cache as per your settings. When the new estimate is imposed, you will end up with work that equates to something like 10-15 days worth (or more, particularly on CPU tasks) and BOINC will immediately go into panic mode. You really don't want that to happen.
The solution is very simple. Remember, this advice applies to people with multi-day caches who are still crunching 2003L tasks. Since 2004L tasks have been available for well over a day now, you probably already will have much more than 5 days worth of them. You just need to say enough is enough by setting your work cache back to something very low (0.1 days would be good) until the storm has passed. Just put your cache back to normal one you have worked off sufficient of the excess you have.
If you don't want to change the size of your work cache, you could just set NNT (No New Tasks) in BOINC manager to stop further work fetch until the excess tasks have been worked off. It's better to change the work cache because there is a higher risk of BOINC going into high priority mode with a larger work cache setting still in place.
Richie wrote:Now would be a
)
Absolutely!! For people with large caches, please be advised that the 2004L data file that followed 2003L produces tasks (as mentioned by Oliver) that take the normal time. I have measured one to confirm it.
So, if you have a multi-day cache and haven't changed it, you will have been accumulating 2004L tasks which will be estimated as if they will crunch like 2003L tasks. You will probably have *lots* of them already. You will probably still be crunching whatever you have left of the 2003L tasks and everything will *appear* normal. If you also crunch CPU tasks, you will also be seeing a lot more of those than previously.
If the above description applies to you, your pain and suffering will come when the first 2004L task gets crunched. When finished, it will immediately impose a new and 4 to 5 times larger estimate on *everything* in your cache. As an example, say you had a 3 day cache as per your settings. When the new estimate is imposed, you will end up with work that equates to something like 10-15 days worth (or more, particularly on CPU tasks) and BOINC will immediately go into panic mode. You really don't want that to happen.
The solution is very simple. Remember, this advice applies to people with multi-day caches who are still crunching 2003L tasks. Since 2004L tasks have been available for well over a day now, you probably already will have much more than 5 days worth of them. You just need to say enough is enough by setting your work cache back to something very low (0.1 days would be good) until the storm has passed. Just put your cache back to normal one you have worked off sufficient of the excess you have.
If you don't want to change the size of your work cache, you could just set NNT (No New Tasks) in BOINC manager to stop further work fetch until the excess tasks have been worked off. It's better to change the work cache because there is a higher risk of BOINC going into high priority mode with a larger work cache setting still in place.
Cheers,
Gary.