Also the Project will report every 20 Minutes on it's own, a Server Side Setting I think. That amount of time will slowly creep up though if no work is returned or requested.

That might be more of a plausible explanation. I'll have to look at the log file tonight...

I looked into this today... The reporting happened at no more than 4 seconds (sometimes 1 second) after the completion of the upload for each and every task. What comes to mind right offhand is that BOINC is confused by the high DCF.

However, there is one other possibility... Can return_results_immediately be triggered by a science application or, put another way, can science applications initiate a communication session on their own?

Ageless or JMVII could probably answer that better than me, but I do think they can especially if BOINC thinks you need more work for that Project ... ???

Another thought is seeing you just attached to the Project a few days ago your Debt Share is probably high to the Project so BOINC wants to catch you up ... ???

However, there is one other possibility... Can return_results_immediately be triggered by a science application or, put another way, can science applications initiate a communication session on their own?

Yes and No. A project can set a maximum delay before the client will contact it again. Also if the deadline is tight enough you get the same effect.

---

BOINC WIKI

BOINCing since 2002/12/8

owever, a thought or question, not an observation of any such behaviour:
If you get one of the long WUs and your DCF is too low for it, would the To Completion not increase during processing until 50%, since the initial estimate would have been too low? Any ideas on that?

Rod

I would think it should to some degree, but with the To Completion time as Hesitant as it is it might over-ride any DFC discrepancy so the To Completion time wouldn't rise anyway unless the DFC was so far off it almost had to rise ... IMO

Like when the crunch time is increased by about 60 times without adjusting the estimated time? He he he. Jokes aside, I agree with this response of yours.

Like when the crunch time is increased by about 60 times without adjusting the estimated time?

Exactly, or "" somebody messes with a certain .xml file to much "" ... :P

Just for the record. Since this morning, I have yet to see To Completion increase.

I caught the To Completion time on 1 Wu increasing this morning, it started out @ 3:09:28 & about every 30 Seconds or so rose 1 Second until it reached 3:11:24 or a 1 minute & 56 second rise in the To Completion time before it started to slowly drop again.

I think it could have something to do with the varying lengths of the Wu's, every time you finish a long Wu it will adjust your To Completion time upwards & when you finish a short Wu the To Completion time is adjusted downwards. I don't think the middle length Wu's have much affect on the To Completion time.

Also it could probably have something to do too with the order (short, medium or long) your running the Wu's in if the To Completion time goes up or down at the start of the next Wu because of which way the To Completion time gets adjusted because of the last Wu it ran & the next Wu it starts ... :)

On my system BOINC Manager's estimate of the completion time reduces slightly when a short (371) WU completes, reduces slightly more when a medium WU (373) completes, but jumps right back up in one go when a long WU (372) completes.

This is consistent with my experience on other projects - for example, I had an ABC WU that completed in 40 hours instead of the usual 1 to 2 - all the estimates went up to 40 hours and the Manager went into high priority panic. I took about twelve hours of short WU completions before the estimates dropped enough to cancel the panic...

---

"Never trust a computer you can't throw out a window." Steve Wozniak

On my system BOINC Manager's estimate of the completion time reduces slightly when a short (371) WU completes, reduces slightly more when a medium WU (373) completes, but jumps right back up in one go when a long WU (372) completes.

This is consistent with my experience on other projects - for example, I had an ABC WU that completed in 40 hours instead of the usual 1 to 2 - all the estimates went up to 40 hours and the Manager went into high priority panic. I took about twelve hours of short WU completions before the estimates dropped enough to cancel the panic...

Yes, actually the To Completion time is slow to drop but the first longer Wu will make it jump considerably higher, don't know if thats a flaw or bug in the BOINC Client but it will disproportionately go much higher faster than it will come down.

Like you say thats consistent though across the Projects ... :)

On my system BOINC Manager's estimate of the completion time reduces slightly when a short (371) WU completes, reduces slightly more when a medium WU (373) completes, but jumps right back up in one go when a long WU (372) completes.

This is consistent with my experience on other projects - for example, I had an ABC WU that completed in 40 hours instead of the usual 1 to 2 - all the estimates went up to 40 hours and the Manager went into high priority panic. I took about twelve hours of short WU completions before the estimates dropped enough to cancel the panic...

Yes, actually the To Completion time is slow to drop but the first longer Wu will make it jump considerably higher, don't know if thats a flaw or bug in the BOINC Client but it will disproportionately go much higher faster than it will come down.

Like you say thats consistent though across the Projects ... :)

It's my understanding that this is in fact part of the design. The estimate takes into account the Duration Correction Factor (DCF) so will tend to adjust the same way the DCF adjusts.

If a WU takes much longer than estimated (like when we got the 372's here at Milkyway) then the DCF adjusts to fully compensate for the 'error'. But when a WU takes less than estimated (getting a 373 or 371, after a 372) then it only adjusts by 10% of what it would need to.

The full adjust upwards means that Boinc immediately know the 'correct' running time and won't download more than it should (it's too late for long WUs already in a cruncher's cache).
By not adjusting downwards too quickly Boinc won't suddenly download lots of WUs if an unusually short WU is crunched (at Milkyway that would be a 371 or a 373 after a 372 WU).

Hope that helps.
Rod

On my system BOINC Manager's estimate of the completion time reduces slightly when a short (371) WU completes, reduces slightly more when a medium WU (373) completes, but jumps right back up in one go when a long WU (372) completes.

This is consistent with my experience on other projects - for example, I had an ABC WU that completed in 40 hours instead of the usual 1 to 2 - all the estimates went up to 40 hours and the Manager went into high priority panic. I took about twelve hours of short WU completions before the estimates dropped enough to cancel the panic...

Yes, actually the To Completion time is slow to drop but the first longer Wu will make it jump considerably higher, don't know if thats a flaw or bug in the BOINC Client but it will disproportionately go much higher faster than it will come down.

Like you say thats consistent though across the Projects ... :)

It's my understanding that this is in fact part of the design. The estimate takes into account the Duration Correction Factor (DCF) so will tend to adjust the same way the DCF adjusts.

If a WU takes much longer than estimated (like when we got the 372's here at Milkyway) then the DCF adjusts to fully compensate for the 'error'. But when a WU takes less than estimated (getting a 373 or 371, after a 372) then it only adjusts by 10% of what it would need to.

The full adjust upwards means that Boinc immediately know the 'correct' running time and won't download more than it should (it's too late for long WUs already in a cruncher's cache).
By not adjusting downwards too quickly Boinc won't suddenly download lots of WUs if an unusually short WU is crunched (at Milkyway that would be a 371 or a 373 after a 372 WU).

Hope that helps.
Rod

Yes, I was already thinking that it was probably designed that way & not a flaw or bug so as to keep from Downloading to much, thanks for the input though ... :)

However, there is one other possibility... Can return_results_immediately be triggered by a science application or, put another way, can science applications initiate a communication session on their own?

Yes and No. A project can set a maximum delay before the client will contact it again. Also if the deadline is tight enough you get the same effect.

Thanks John... I figured out that it is deadline related...

IOW, I forgot to check one of my settings... :-(