delta1513
commented
5 years ago Regarding #3370
I am a newbie to contributions and hence have barely any knowledge of the inner workings of the server component of the BOINC software. I drew a conclusion from the logic of the program that the user would have to wait until the diff was beyond that of the min_sendwork_interval and hence why I used that in the metric.
If someone with more experience can direct me to some variables that would better achieve this, or rather fork my branch, that would be great.
As the author of #3360, please may I ask for a reconsideration of the solutions implemented in #3370 and #3371? As these issues / PRs are all now closed, I think it's cleaner to re-gather the threads in a single place.
3370: The new 'delay' value shown to the user is the 'time left' in the backoff from the previous RPC. But it isn't.
There are three RPCs in play: previous, current, next. Because we are in the middle of the current RPC, the server will request the full min_sendwork_interval before the next RPC - the amount of time used up in the interval between previous and current RPCs is now ancient history and should be disregarded.
3371: Because the user would now be seeing the full min_sendwork_interval in the 'too recent' message, why not display it as a normal (non-debug) message in the scheduler reply, and avoid the confusion arising in the first place?
For information, I think the problem arises in two places: 1) Impatient users over-clicking the 'update' button when work is scarce. That's their own silly fault, and we don't need to do anything except tell them what the delay should have been. 2) When performing maintenance chores which require a BOINC restart or computer reboot. The current server delay is non-persistent across restarts, and if the reboot takes less than 5 minutes (SETI) or 1 hour (CPDN), the client may request new work before the curfew has ended.
[this issue fao @delta1512, @Rytiss, @AenBleidd]