Hi.

BM says communication deferred 5.00mins after BM 7.x.x has requested work.
Then it waits for like another 5 mins after the "communication deferred" 5mins has elapsed.
I also see a "fetch deferal interval" in properties of the project in BM under projects tab. And that is 600seconds.
What is the point in having 2 alternate ways when to request more work.

I tried to change the 600 seconds interval in client_state.xml and client_state_prev.xml files but they just gets back to "normal".

If you ask me 120seconds would be along waiting. This should be an automated work fetching thing in the 21'st century where a millisecond is too much!!!

//TRuEQ


//TRuEQ

---

TRuEQ & TuVaLu

Hi.

BM says communication deferred 5.00mins after BM 7.x.x has requested work.
Then it waits for like another 5 mins after the "communication deferred" 5mins has elapsed.
I also see a "fetch deferal interval" in properties of the project in BM under projects tab. And that is 600seconds.
What is the point in having 2 alternate ways when to request more work.

I tried to change the 600 seconds interval in client_state.xml and client_state_prev.xml files but they just gets back to "normal".

If you ask me 120seconds would be along waiting. This should be an automated work fetching thing in the 21'st century where a millisecond is too much!!!

//TRuEQ


//TRuEQ

Client_state.xml is read at startup only. After that it only gets written to.

I assume you are talking about boinc 7 behaviour when a task request failed.

You have two difefrent backoffs. One is the 5 minutes from the server set there to stop clients asking for work in too short intervals. That you get alwasy afrer a sucessful server contact. The 600 sec (10 minutes) is BOINC's 'I didn't get work' backoff, which increases with every failed request. It's designed to make sure the client doesn't hammer the project, when there is no work to be had.

Several of BOINCs policies (regardles of version) don't work too well with SETIs overloaded servers. David appears deaf on that ear.

Patience is a virtue. Eventually you'll get work. With Boinc 7 workfetch policy even will make sure after some time seti gets always asked first.

setting a small 'additional buffer' helps, because then boinc 7 will ask more frequently, increasing the chances of grabbing something.

---

I'm not the Pope. I don't speak Ex Cathedra!

Hi.

BM says communication deferred 5.00mins after BM 7.x.x has requested work.
Then it waits for like another 5 mins after the "communication deferred" 5mins has elapsed.
I also see a "fetch deferal interval" in properties of the project in BM under projects tab. And that is 600seconds.
What is the point in having 2 alternate ways when to request more work.

I tried to change the 600 seconds interval in client_state.xml and client_state_prev.xml files but they just gets back to "normal".

If you ask me 120seconds would be along waiting. This should be an automated work fetching thing in the 21'st century where a millisecond is too much!!!

//TRuEQ


//TRuEQ

In addition to what LadyL said.
You can try to request work as often as you like, but the server will ignore any request that occurs sooner than about every 5 minutes. That was enabled a while ago on the server side as the hardware just can't keep up with all of the requests. I'm sure they have thought about bumping that up to 10 minutes even.

---

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

setting a small 'additional buffer' helps, because then boinc 7 will ask more frequently, increasing the chances of grabbing something.

(Sorry for the hijack.)

Is there a FAQ that explains the way those two setting work, compared to the old way? I looked on the wiki, but couldn't find anything. With the old way, I used 0 and 1. What would the settings be with the new scheme, to have as similar behavior as possible? If I go by what I *think* the descriptions imply, it should use 1 and 0. Is that right?

Old:
* Computer is connected to the Internet about every
(Leave blank or 0 if always connected.
BOINC will try to maintain at least this much work.)
* Maintain enough work for an additional
Enforced by version 5.10+

New:
* Maintain enough tasks to keep busy for at least
(max 10 days).
* ... and up to an additional

---

Dublin, California
Team: SETI.USA

It has been said that patience is not only helpful, but a requirement.

---

Janice

try this post

---

I'm not the Pope. I don't speak Ex Cathedra!

Hi.

BM says communication deferred 5.00mins after BM 7.x.x has requested work.
Then it waits for like another 5 mins after the "communication deferred" 5mins has elapsed.
I also see a "fetch deferal interval" in properties of the project in BM under projects tab. And that is 600seconds.
What is the point in having 2 alternate ways when to request more work.

I tried to change the 600 seconds interval in client_state.xml and client_state_prev.xml files but they just gets back to "normal".

If you ask me 120seconds would be along waiting. This should be an automated work fetching thing in the 21'st century where a millisecond is too much!!!

//TRuEQ


//TRuEQ

Client_state.xml is read at startup only. After that it only gets written to.

I assume you are talking about boinc 7 behaviour when a task request failed.

You have two difefrent backoffs. One is the 5 minutes from the server set there to stop clients asking for work in too short intervals. That you get alwasy afrer a sucessful server contact. The 600 sec (10 minutes) is BOINC's 'I didn't get work' backoff, which increases with every failed request. It's designed to make sure the client doesn't hammer the project, when there is no work to be had.

Several of BOINCs policies (regardles of version) don't work too well with SETIs overloaded servers. David appears deaf on that ear.

Patience is a virtue. Eventually you'll get work. With Boinc 7 workfetch policy even will make sure after some time seti gets always asked first.

setting a small 'additional buffer' helps, because then boinc 7 will ask more frequently, increasing the chances of grabbing something.

well, before i wrote stuff here about it I clicked the update button to try to get more work.
Work cache will not fill up.....
Since I get too few tries to "talk" to the server.

And of this there will be a big difference in the calculation of "debt" that might not be healthy for the BM.

And having the use of "debt" when it doesn't use that "debt" to try to get more frequent contact with the server to keep up...
What can I say....Non working non finished stuff here....

If the calculation of "debt" would make the BM to request work more frequent then If work is obtained and processed. The "debt" will decrease as it should.
There is a correction factor calculation here as well that would fix the flaw debt thing. How and if it works I can as a user not tell.
My guess is that it doesn't work here.
If it did, the BM should request more work more often to get the debt equalized between that projects.

You say DA doesn't listen.
Strange.
Doesen't he want this to work properly???
Is it that you say here?

I have mailed DA 1 mail yesterday an 1 mail today with message logs and my saying how this does not work.

I hope more people that encounter work fetch, BM cue and cache problems mail this to DA and/or the Boinc alpha mailing list.

Or, maybe I am alone about this BM problem/behaviour.

//TRuEQ

---

TRuEQ & TuVaLu

I have mailed DA 1 mail yesterday an 1 mail today with message logs and my saying how this does not work.

I hope more people that encounter work fetch, BM cue and cache problems mail this to DA and/or the Boinc alpha mailing list.

Or, maybe I am alone about this BM problem/behaviour.

//TRuEQ

I am now quoting myself here.

I got an answer from DA saying he saw in the logs what was not right and that he will fix it in a few days.

Thank you DA!!!

//TRuEQ

---

TRuEQ & TuVaLu