Would seem that a golden opportunity to notify crunchers of this outage via the BOINC 6+ 'Notices' facility has been let slip by,

The only people aware are the forum-users, apparently. I'm not worried - I've a full-ish buffer; bit of a worry that it now appears that comms have been deferred for 3 hours at the behest of the server....

It would seem that it would be useful if a 'maintenance' facility was inbuilt into BOINC such that the buffered work could be temporarily increased by the expected-down-time on notification from the project; similarly attempts to communicate with the project could also be suspended for the outage period.

Not many threads listed when I clicked on 'recent threads', this thread was not listed, just a few threads. I found this one only by manually going to 'boinc agent support' threads/forum first. I wonder if this is related to the maintenance planned.

Completely the wrong question.

The real question is what happens with a processor dedicated to one project - we can ignore that small proportion micromanaged by the forum-frequenting addicts.

With the current system, the machine goes to idle when the work runs out because there's no more coming from the project. BOINC should simply increase the work buffer to cover the downtime and reduce it to its original value when the maintenance period finishes. Remember that after the maintenance commences, the client will make no further requests to that project for more work since BOINC knows that the project is down. Consequently, work will only be downloaded to cover the outage.

If a client is crunching more than one project, then the buffer should be extended to the maintenance end-time and required-work calculated for the project-in-maintenance, with due regard to the processor-availabilty schedule. Multiply that time by the fraction that BOINC knows the project in question receives for the installation and call for THAT amount of extra work for the project undergoing maintenance. In fact, the dedicated processor does the same calculation, but with a fraction of 1.

The issue is far more with dedicated machines than with those crunching more than one project. What I have suggested won't affect non-dedicated machines - existing mechanisms will ensure they aren't allowed to remain idle. It's the ones that have nothing else to do that would be affected.

Let's hope all team leaders and people know enough not to run out of work early in the shutdown. If only 10% of the world's devices are wihtout work, it means that close to 194,137 devices will not be helping, multiplied by 10 hours = 1,941,375 cpu hours

The wrong question? You propose that WCG patronizes the volunteers and overrides their settings! There's no way that WCG can presume to increase cache, even temporarily, let alone it having any effect when local preferences override these settings and there being many versions of client out there. The effect is that those that get upset will be a bigger loss than the impact of this outage, which with a cache default of 0.3 days bridges > 7 hours, plus whatever is work in progress is not enormous.

Again, how should would BOINC *simply* increase it's cache? You propose, you tell the Berkeley developers how that then would fit in with everything else. Meantime, the present clients have a mechanism to back off and autonomously try later at programmed increments. The message to back off for the planned downtime was already proposed way up in this thread. But then, what if the outage lasts not 11 hours, but 6? What if it gets last minute cancelled? Present security rules dictate that clients initiate connection, not the server. Once a client is told to back off by X time it will stick to that.

At any rate, what you want is not viable. That is what my question inferred.

--//--