"Last request too recent" error when using "network_available"

[hucker75]

If "boinccmd --network_available" is used, Boinc Manager forgets the project's requested delay.

[BrianNixon]

This appears to be by design
https://github.com/BOINC/boinc/blob/master/checkin_notes_2005#L8312-L8314

[hucker75]

Not sure what you're referring to in all that text.

[BrianNixon]

The link is just a reference to David Anderson’s notes from the original implementation of the feature:

        - network_available() resets all backoff timers
            (of PERS_FILE_XFERs and PROJECTs) to zero,
            so everything will be retried immediately.

[hucker75]

Why is it done this way?

[BrianNixon]

Because the intention is to tell the client that the network is available and it should get on with using it.

It could be an oversight if network_available doesn’t distinguish between client-side and project-requested backoffs.

[hucker75]

Indeed. Climate prediction for example has a 1 hour backoff. If my client loses network, then regains it, in under an hour, it will annoy the server and presumably delay things until another hour has passed.

[davidpanderson]

The client has a "min_rpc_time" for each project, which reflects both the project-requested delay
and the exponential backoff when a scheduler request fails.

I think it would be OK to leave this alone (not set it to zero) on a network_available command.
Same for file transfer backoff.

On the other hand, the extra requests and "too recent" messages don't really hurt anything.
The server doesn't change its min RPC time when it gets a too-soon request.

[hucker75]

I could be wrong but I'm sure if I've manually asked for more work a bit too soon, I get punished by the server, it resets the wait time.

[RichardHaselgrove]

You are correct. "Last request too recent" relies on a server-side timer, and can't be reset by any client action. It only controls the sending of new work (if requested and available) - not any other of the functions performed by a client update request. (It's only sent from one point in the code - https://github.com/BOINC/boinc/blob/master/sched/handle_request.cpp#L1409)

The client-server RPC backoff is set in a variety of circumstances, and is variable (irrespective of project minimum) - it can rise to 24 hours, during an extended server or network failure. It is not limited to the work fetch case.

I've always taken network_available to be a last-resort 'reset all' sledgehammer - not expected or intended for general use. I think it should remain in that role: I can imagine the sysop of an institution's internal BOINC instance using a broadcast script to restart research after a known period of downtime, for example. That needs to restart RPCs after one of those 24 hour 'network failure' delays, too.

[BrianNixon]

last-resort 'reset all' sledgehammer - not expected or intended for general use

Should Tools » Retry pending transfers be removed from BOINC Manager?

[hucker75]

Why would you want that removed? That's a very useful command if I or the server have had difficulties transferring files.

[BrianNixon]

I don’t want it removed. I’m just asking the question because Retry pending transfers and boinccmd --network_available are exactly the same thing.

[hucker75]

I wasn't aware retry pending transfers did that, it seems a strange thing for it to do, I'm just asking it to retry any transfers which are in the queue, not telling it anything about the network being available.

I use Boinctasks as I can't stand the clunky Boinc Manager interface, and I'd always assumed it just requested individual stuck files to be retried, since I can retry one of 10 in a list and it only does that one. I guess it's the equivalent in Boinc manager of going to the transfers tab and retrying files in there. I didn't know there was a global one aswell.

[RichardHaselgrove]

Please leave both 'Retry pending transfers' and '--network_available' as they are. Changing either of them would be using another sledgehammer to crack a very trivial nut.

BOINC is a very broad church, used in a wide range of situations by a very diverse range of user classes. Skewing the user interface to suit the perceived need of one group or another would be a poor design choice.