Hi,

Please see: http://setiathome.berkeley.edu/

Notice the latest news about SETI@home servers.

That is no updating can take place between Tuesdays starting at 4am Pacific time until 4am Friday. At least that's how I read it and seems to be true.

So Boinc should not even try to communicate with SETI@home servers during this time period.

I really sick of seeing this in bonic and it's a waste of bandwidth:

7/21/2010 4:42:13 PM SETI@home Started upload of 29my10aa.13242.12202.11.10.128_1_0
7/21/2010 4:42:13 PM SETI@home Started upload of 29my10aa.13242.13838.11.10.163_1_0
7/21/2010 4:42:15 PM Project communication failed: attempting access to reference site
7/21/2010 4:42:15 PM SETI@home Temporarily failed upload of 29my10aa.13242.12202.11.10.128_1_0: connect() failed
7/21/2010 4:42:15 PM SETI@home Backing off 1 min 58 sec on upload of 29my10aa.13242.12202.11.10.128_1_0
7/21/2010 4:42:15 PM SETI@home Temporarily failed upload of 29my10aa.13242.13838.11.10.163_1_0: connect() failed
7/21/2010 4:42:15 PM SETI@home Backing off 1 min 0 sec on upload of 29my10aa.13242.13838.11.10.163_1_0
7/21/2010 4:42:16 PM Internet access OK - project servers may be temporarily down.
7/21/2010 4:43:33 PM SETI@home Started upload of 03jn10aa.15751.476.5.10.219_1_0
7/21/2010 4:43:33 PM SETI@home Started upload of 29my10aa.13242.13838.11.10.163_1_0
7/21/2010 4:43:35 PM Project communication failed: attempting access to reference site
7/21/2010 4:43:35 PM SETI@home Temporarily failed upload of 03jn10aa.15751.476.5.10.219_1_0: connect() failed
7/21/2010 4:43:35 PM SETI@home Backing off 1 min 7 sec on upload of 03jn10aa.15751.476.5.10.219_1_0
7/21/2010 4:43:35 PM SETI@home Temporarily failed upload of 29my10aa.13242.13838.11.10.163_1_0: connect() failed
7/21/2010 4:43:35 PM SETI@home Backing off 1 min 0 sec on upload of 29my10aa.13242.13838.11.10.163_1_0
7/21/2010 4:43:36 PM Internet access OK - project servers may be temporarily down.

So bottom line is, Boinc should know the servers are down and not even bother during the downtime.

Thanks,

Will

And how do you expect BOINC to know that servers are down and when they are back up without probing them? if you don't want to see those retry messages, set up alternate allowed to connect to internet preferences. They are available in the Advanced preferences menu.

---

Hi everybody!

I think Will is right. Having some decent numbers of ready to report units all trying to connect once in a while over 3 days produces completely unnecessary and avoidable traffic.

Projects could provide a downtime or down_until string (timestamp) that is probed after a unsuccessful up/download attempt and/or on failing regular project connection, silencing all communication with this project until given date/time.

Even easier way whithout touching servers would be, if scheduled transfers to one specific project inherit information of transaction failures from others.
So for example; when a connection fails at noon sharp and it is re-scheduled for 1pm, all following connections scheduled for the period noon until 1pm (re-scheduled transfers and newly finished jobs) are stalled until 1pm.
Just define a practical value for the period in which transfers inherit retry times; and at which point they are no longer have to obey them keeping their own retry time.
Means for the example from above with a given inherit period of 1h:
Transfers that are scheduled for a connection later than “last connection failure + 60min” (1:00:01pm and later) will not be affected and executed as planed; UNTIL no transfer fails less than 60min prior this event.

Rather simple logic that could save some traffic and relieve hammering against project servers.

Maybe this could be implemented as a friendly_network_behavior_option or something.


In my case I now have about 50 seti results waiting all trying to re-connect in a 20min timeframe which could be avoided if the first failing retry “tells” the other 49 transfers, that the service is still unavailable delaying them all until its own next retry.
This would be 49 less connections within 20min from a single machine =)

Cheers and have a nice weekend!

I have been a contributor to SETI for 11 years now. I too am tired of seeing this waste of clock cycles and bandwidth during their three day outages. As a result until I have a means of avoiding this waste without impacting the other Boinc projects, I am signing out of SETI.

---

What BOINC version do you use?

The new versions have "Project backoff" feature which does exactly that.
(if one upload failed all uploads are paused for some time (minutes to hours))

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

What BOINC version do you use?

The new versions have "Project backoff" feature which does exactly that.
(if one upload failed all uploads are paused for some time (minutes to hours))

I have 6.10.56 running but I cannot see this behavior.
It is still like I wrote above. Up to 50 transfer re-tries within 20 minutes. No throttle or something.

Do I need a newer version?

@Brent: c'mon mate, no need to sing out. It's not that bad ;)

It is still like I wrote above. Up to 50 transfer re-tries within 20 minutes. No throttle or something.

Well, then something else is wrong with your BOINC, as Seti has had upload available since Friday and the cricket graph isn't maxed out at this time. (EDIT: of course, minutes after I typed that, the Monday lift-off started and the uploads and downloads are now maxed out... ;-))

Try a restart of your client, make sure you allowed network activity or that it's set to run based on preferences and that your preferences allow you to upload at this time.

Now, for fun, open BOINC Manager->Advanced view->Projects tab->Select Seti->Click Properties. Between Resource Share and Disk Usage you should see a Project Backoff saying either "File downloads deferred for" or "File uploads deferred for" with a timer. Do you see this value?

If so, your project backoff works correctly.

Now, as for having 20 uploads retrying simultaneously, there is a chance that you at one time added a cc_config.xml file and added to it:

<options>
<max_file_xfers>20</max_file_xfers>
</options>

.. and promptly forgot about that. Check that as well. Normal value for simultaneous uploads and downloads is 2 per.

---

Now, for fun, open BOINC Manager->Advanced view->Projects tab->Select Seti->Click Properties. Between Resource Share and Disk Usage you should see a Project Backoff saying either "File downloads deferred for" or "File uploads deferred for" with a timer. Do you see this value?

There is

Scheduler RPC deferred for: 00:06:52

entry. But no "File up/download deferred for"
Does this value do the same? Or do I need a newer BOINC client?

I unfortunately need to use

<max_file_xfers>

because I have only limited hours which I can use to transfer data from/to project servers. Therefore I need to use “some force” in order to get everything done within this rather short timeframe.

There is

Scheduler RPC deferred for: 00:06:52

entry. But no "File up/download deferred for"
Does this value do the same? Or do I need a newer BOINC client?

You shouldn't need a newer client. All 6.10s do this.
See this picture (taken off my machine) for an example.

I unfortunately need to use

<max_file_xfers>

because I have only limited hours which I can use to transfer data from/to project servers. Therefore I need to use “some force” in order to get everything done within this rather short timeframe.

Uhuh... as if that's going to help. When the Seti 100Mbit pipeline is clogged up by all the computers attached trying to upload, setting more connections isn't exactly going to help. It may even hamper your uploads.

If you can upload on Saturday, you could also set BOINC to use the network then, instead of on the Friday when you know the pipe is going to be clogged. Of course, by setting the max_file_transfers to a value other than default, you are in no position to complain that BOINC is constantly trying to upload that many files at the same time or at different times. It's what you chose BOINC to do.

When you have more uploads than the value you set for the transfers, BOINC will initialize the project backoff. if you then manually try to upload them (Transfer->Retry) and they fail, you'll have different values for all the tasks trying to upload, all counting down again. Also nothing that the client can't do about, as you seem to feel you're more important than others by clicking the retry button instead of letting the client figure it out. (not attacking anyone)

---

If uploads are going smoothly at SETI server side they go in seconds
so you don't need <max_file_xfers> (which are 2 by default).

Or set this value to 5-10, not 50-100

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

I'm not complaining! I just made a suggestion how one could cope with the issue war59312 initially described, remember ;)

I now upgraded to latest BOINC and will keep an eye on the transfers.

And how do you expect BOINC to know that servers are down and when they are back up without probing them? if you don't want to see those retry messages, set up alternate allowed to connect to internet preferences. They are available in the Advanced preferences menu.

Um easy. Simply assume in the programming the servers are down during those times specified so don't bother making any connections during that time period.

Pretty simple if you ask me. Like you said you can already do it yourself using the overrides in advanced so why not simply include default values when the user adds the SETI@home project?

That being said those settings would only need to apply to the SETI@home project. I see no way to apply these networks settings to only 1 project. Am I blind?