err - cc_config has an option for <report_results_immediately>. Why would that not do?

How they will behave on offline host?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

err - cc_config has an option for <report_results_immediately>. Why would that not do?

I use7.6.33. And that option marked as "new in 7.7".

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

For the app_config.xml yes, but for cc_config.xml its been available for years. Easily available in 7.6.33

---

err - cc_config has an option for <report_results_immediately>. Why would that not do?

How they will behave on offline host?

It will sign you up to the most expensive cellular data connection available locally, and report tasks that way.

No, of course it won't. If the host is offline, then BOINC is offline. No amount of pushing and prodding, manually or scripted, will make tasks report.

err - cc_config has an option for <report_results_immediately>. Why would that not do?

I use7.6.33. And that option marked as "new in 7.7".

No, it's the two starred options in the <proxy_info> block above which are "new in 7.7".

As Jord said.

Thanks, Jord and Richard.
What I meant about behavior of offline host is if it will incur additional overhead for boinc process to constantly attempt to connect and fail. Or not?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Thanks, Jord and Richard.
What I meant about behavior of offline host is if it will incur additional overhead for boinc process to constantly attempt to connect and fail. Or not?

Looking at the machine in front of me, boinc.exe has currently used 00:42:37 of CPU time since it was last restarted on 15 September - well under 2 minutes per day. That's on a fast i5 with three GPUs, probably reporting a minimum of 250 tasks per day. Considering it has 5,760 CPU minutes available per day (4 cores), using <0.035% for boinc is hardly going to break the bank.

And if it's offline? The reporting requests will go into extended backoff, and take no time at all.

And if it's offline? The reporting requests will go into extended backoff, and take no time at all.

So,when data directory will be taken to internet host - would that backoff remain? Or re-launching boinc.exe on internet host will trigger immediate connection attempt again?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

And if it's offline? The reporting requests will go into extended backoff, and take no time at all.

So,when data directory will be taken to internet host - would that backoff remain? Or re-launching boinc.exe on internet host will trigger immediate connection attempt again?

Project communication deferrals are kept when restarting BOINC. I would guess that file transfers and other backoff times are retained as well.
If you don't want to use boinccmd -project url update
It looks like you could update <rsc_backoff_time> and <rsc_backoff_interval> in the client_state.xml for each project.
File transfer backoff timers would likely be similar. I imagine some kind of script could be run to reset all of the xml values.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

And if it's offline? The reporting requests will go into extended backoff, and take no time at all.

So,when data directory will be taken to internet host - would that backoff remain? Or re-launching boinc.exe on internet host will trigger immediate connection attempt again?

Project communication deferrals are kept when restarting BOINC. I would guess that file transfers and other backoff times are retained as well.

Then cc_config will not help :/

If you don't want to use boinccmd -project url update
It looks like you could update <rsc_backoff_time> and <rsc_backoff_interval> in the client_state.xml for each project.
File transfer backoff timers would likely be similar. I imagine some kind of script could be run to reset all of the xml values.

Sounds not much easy then handling boinccmd. In both cases additional scripting required and at least I have your examples for boinccmd.
Well, keeping internet host online through night almost solves issue.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Depends if you have a fixed schedule for letting the offline hosts go online - although you mention the situation in your opening post, you don't explain the circumstances or give any idea of timing.

If you, perhaps, take them all home so they can be online 'through night', then set up a networking schedule to allow network use say half an hour after your normal connection setup, and to disallow network use half an hour before you dismantle, that should cover it.

Depends if you have a fixed schedule for letting the offline hosts go online - although you mention the situation in your opening post, you don't explain the circumstances or give any idea of timing.

If you, perhaps, take them all home so they can be online 'through night', then set up a networking schedule to allow network use say half an hour after your normal connection setup, and to disallow network use half an hour before you dismantle, that should cover it.

Interesting idea, thanks.
Offline hosts are offline forever. Data directory physically transfered onto another device for network communications.
Such network schedule can be implemented into global options override XML file, correct?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

There's Tools -> Retry pending transfers in Manager and "--network_available" in boinccmd.

There's Tools -> Retry pending transfers in Manager and "--network_available" in boinccmd.

Thanks, but I don't use GUI part at all for this endeavor and editing XML once would be preferable than to introduce boinccmd.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

There's Tools -> Retry pending transfers in Manager and "--network_available" in boinccmd.

Thanks, but I don't use GUI part at all for this endeavor and editing XML once would be preferable than to introduce boinccmd.

One way could be to use PowerShell.
Something along the lines of:

[xml]$cli_state = Get-Content D:\Temp\state.xml
$project = $cli_state.client_state.project | where {$_.master_url -eq 'http://setiathome.berkeley.edu/'}
$set1 = $project.rsc_backoff_time | where {$_.name -eq 'CPU'}
$set1.value = "0.0"
$set2 = $project.rsc_backoff_interval | where {$_.name -eq 'CPU'}
$set2.value = "0.0"
$set3 = $project.rsc_backoff_time | where {$_.name -eq 'ATI'}
$set3.value = "0.0"
$set4 = $project.rsc_backoff_interval | where {$_.name -eq 'ATI'}
$set4.value = "0.0"
$cli_state.Save("D:\Temp\state.xml")

That is just for the project backoffs. Tasks could have backoff times too, but I don't have any in my client_state.xml to look at for examples right now.
Probably using some for loops to run through all of the projects and the CPU GPUs would be a more efficient way to go than my specific example, but I'm not that good at PowerShell yet.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Data directory physically transfered onto another device for network communications.

Then you could use a different startup command on the internet computer and allow boinccmd to function there?