Index  | Recent Threads  | Unanswered Threads  | Who's Active  | Guidelines  | Search
 
World Community Grid Forums
  Category: Support
  Forum: BOINC Agent Support
  Thread: Why BOINC attempts to connect to network IMMEDIATELY after system resume from standby and does not try again?

Quick Go »
No member browsing this thread
Thread Status: Active
Total posts in this thread: 13
Posts: 13   Pages: 2   [ Previous Page | 1 2 ]
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 2358 times and has 12 replies Next Thread
Ingleside
Veteran Cruncher
Norway
Joined: Nov 19, 2005
Post Count: 974
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Why BOINC attempts to connect to network IMMEDIATELY after system resume from standby and does not try again?
"BOINC can't access Internet "

Which is the root of the problem, for as long as the condition persists. Eif/we're looking a workaround, optimal settings, so BOINC won't get stopped from doing the work report and fetch without hitting that 3-4 and more hours auto-backoff when the line is actually up and NOT having micromanage.

--//--

Hmm, well, let's do a small test with scheduler-request, to make sure triggered work-request, increased "Connected..." to 3 days, and this gave the following log (just showing the backoffs). Oh, and partway through added a 2nd. project to the mix of asking:

16.09.2011 18:02:12 | World Community Grid | [sched_op] Deferring communication for 1 min 31 sec
16.09.2011 18:02:33 | | BOINC can't access Internet - check network connection or proxy configuration.
16.09.2011 18:04:09 | World Community Grid | [sched_op] Deferring communication for 1 min 51 sec
16.09.2011 18:06:28 | World Community Grid | [sched_op] Deferring communication for 1 min 8 sec
16.09.2011 18:08:00 | World Community Grid | [sched_op] Deferring communication for 1 min 46 sec
16.09.2011 18:10:13 | World Community Grid | [sched_op] Deferring communication for 1 min 2 sec
16.09.2011 18:11:41 | World Community Grid | [sched_op] Deferring communication for 1 min 17 sec
16.09.2011 18:13:23 | World Community Grid | [sched_op] Deferring communication for 1 min 17 sec
16.09.2011 18:15:06 | World Community Grid | [sched_op] Deferring communication for 1 min 43 sec
16.09.2011 18:17:13 | World Community Grid | [sched_op] Deferring communication for 1 min 42 sec
16.09.2011 18:19:22 | World Community Grid | [sched_op] Deferring communication for 1 min 58 sec
16.09.2011 18:20:24 | SETI@home | [sched_op] Deferring communication for 40 sec
16.09.2011 18:21:27 | SETI@home | [sched_op] Deferring communication for 30 sec
16.09.2011 18:21:54 | World Community Grid | [sched_op] Deferring communication for 1 min 28 sec
16.09.2011 18:22:21 | SETI@home | [sched_op] Deferring communication for 31 sec
16.09.2011 18:23:18 | SETI@home | [sched_op] Deferring communication for 47 sec
16.09.2011 18:23:45 | World Community Grid | [sched_op] Deferring communication for 1 min 16 sec
16.09.2011 18:24:32 | SETI@home | [sched_op] Deferring communication for 36 sec
16.09.2011 18:25:24 | World Community Grid | [sched_op] Deferring communication for 1 min 52 sec
16.09.2011 18:25:52 | SETI@home | [sched_op] Deferring communication for 57 sec
16.09.2011 18:27:14 | SETI@home | [sched_op] Deferring communication for 33 sec
16.09.2011 18:27:42 | World Community Grid | [sched_op] Deferring communication for 1 min 1 sec
16.09.2011 18:28:14 | SETI@home | [sched_op] Deferring communication for 30 sec
16.09.2011 18:29:06 | World Community Grid | [sched_op] Deferring communication for 1 min 13 sec
16.09.2011 18:29:35 | SETI@home | [sched_op] Deferring communication for 30 sec
16.09.2011 18:30:32 | SETI@home | [sched_op] Deferring communication for 55 sec
16.09.2011 18:30:59 | World Community Grid | [sched_op] Deferring communication for 1 min 56 sec
16.09.2011 18:31:51 | SETI@home | [sched_op] Deferring communication for 56 sec
16.09.2011 18:33:14 | SETI@home | [sched_op] Deferring communication for 44 sec
16.09.2011 18:33:41 | World Community Grid | [sched_op] Deferring communication for 1 min 22 sec
16.09.2011 18:34:23 | SETI@home | [sched_op] Deferring communication for 48 sec


So, clearly, the "Connected..."-setting has zero effects on how frequently the scheduler-requests are, and also, as long as internet is down, scheduler-requests happens so frequently that it's no problem with client being in a long scheduler-backoff then internet finally is up again.

The long scheduler-request-backoffs only starts appearing then internet-connection finally is back again, but connection to project-server is still unaccessible.

Since your internet-connection is up, having a "workaround" for project-servers being unaccessible... well, quite frankly, I can't see any good way to differenciate between "your connection to the particular server are broken" and "the affected server is currently under a DDOS-attach due to all BOINC-clients using a 30-second backoff between retries so isn't responding in a timely manner"...
----------------------------------------


"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
----------------------------------------
[Edit 1 times, last edit by Ingleside at Sep 16, 2011 5:17:59 PM]
[Sep 16, 2011 5:15:26 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Why BOINC attempts to connect to network IMMEDIATELY after system resume from standby and does not try again?
EiF,

There is seemingly no satisfactory way of getting BOINC to work more humane even after ''expert'' involvement.

If interested in a work around, here are the lines you can put in a script file (.bat) and let the OS scheduler execute at time suitable to you:

boinccmd --set_network_mode auto 60
boinccmd --project $http://www.worldcommunitygrid.org update
sleep 60
boinccmd --set_network never

Notably, you'd have to put the paths in front of boinccmd. Tested this on Linux, and when watching this simultaneous in the BOINC manager message tab / event log window, could see it recording the script activity and after 60 seconds suspend the netwrok again i.e. the number of seconds needs to be selected for how long you'd want BOINC to communicate.

When executing the above 2 lines the following was logged in client after manually setting the network in BOINC to fully suspended:

Fri 16 Sep 2011 07:32:49 PM CEST | | Suspending network activity - user request
Fri 16 Sep 2011 07:33:09 PM CEST | | Resuming network activity
Fri 16 Sep 2011 07:33:11 PM CEST | World Community Grid | update requested by user
Fri 16 Sep 2011 07:33:15 PM CEST | World Community Grid | [sched_op] Starting scheduler request
Fri 16 Sep 2011 07:33:15 PM CEST | World Community Grid | Sending scheduler request: Requested by user.
Fri 16 Sep 2011 07:33:15 PM CEST | World Community Grid | Not reporting or requesting tasks
Fri 16 Sep 2011 07:33:15 PM CEST | World Community Grid | [sched_op] CPU work request: 0.00 seconds; 0.00 CPUs
Fri 16 Sep 2011 07:33:17 PM CEST | World Community Grid | Scheduler request completed
Fri 16 Sep 2011 07:33:17 PM CEST | World Community Grid | [sched_op] Server version 601
Fri 16 Sep 2011 07:33:17 PM CEST | World Community Grid | Project requested delay of 11 seconds
Fri 16 Sep 2011 07:33:17 PM CEST | World Community Grid | [sched_op] Deferring communication for 11 sec
Fri 16 Sep 2011 07:33:17 PM CEST | World Community Grid | [sched_op] Reason: requested by project
Fri 16 Sep 2011 07:34:10 PM CEST | | Suspending file transfers - user request

Notably, the first line activated the °Network based on preferences again", so a third+fourth line is needed to suspend the network again until next time the script is processed. The 'sleep' command is a standard function in Linux. Somewhere on the forums we in past worked out the code to put in for Windows to set the batch processing to wait, which I think was with the ping or choice commands. http://ss64.com/nt/timeout.html has a little timeout util to pause batch executing for a desired amount of time.

Let us know and we'll work to a solution so you can be sure that work gets uploaded and new fetched.

--//--
[Sep 16, 2011 5:55:42 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Ingleside
Veteran Cruncher
Norway
Joined: Nov 19, 2005
Post Count: 974
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Why BOINC attempts to connect to network IMMEDIATELY after system resume from standby and does not try again?
If interested in a work around, here are the lines you can put in a script file (.bat) and let the OS scheduler execute at time suitable to you:

boinccmd --set_network_mode auto 60
boinccmd --project $http://www.worldcommunitygrid.org update
sleep 60
boinccmd --set_network never

A similar script under windows, example trying_to_connect.cmd could be:

:start_the_script
call boinccmd --set_network_mode auto
call sleep 600
call boinccmd --project http://www.worldcommunitygrid.org update
call sleep 600
call boinccmd --set_network never
call sleep 85100
goto start_the_script


It's possible you'll need to download a sleep-program from internet, since windows doesn't normally have this included.

Also, please note I've not verified the exact syntax of the boinccmd-commands, so it's possible these needs to be changed.


As for the script itself, while my version will automatically re-loop after roughly 24 hours, neither my version nor Sekerob's version will magically create a working internet-connection, meaning running as a scheduled task or in a perpetual loop won't help to solve this threads connection-problems.
----------------------------------------


"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
----------------------------------------
[Edit 1 times, last edit by Ingleside at Sep 16, 2011 8:17:27 PM]
[Sep 16, 2011 8:13:42 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Posts: 13   Pages: 2   [ Previous Page | 1 2 ]
[ Jump to Last Post ]
Post new Thread