Message boards :
Number crunching :
rate of processing
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
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. 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 ... ??? |
Send message Joined: 29 Aug 07 Posts: 20 Credit: 2,710,089 RAC: 0 |
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 |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 0 |
owever, a thought or question, not an observation of any such behaviour: 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. |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
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 |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
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 ... :) |
Send message Joined: 31 Mar 08 Posts: 1 Credit: 120,008 RAC: 0 |
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 |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
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. 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 ... :) |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 0 |
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. 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 |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
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. 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 ... :) |
Send message Joined: 21 Aug 08 Posts: 625 Credit: 558,425 RAC: 0 |
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? Thanks John... I figured out that it is deadline related... IOW, I forgot to check one of my settings... :-( |
©2024 Astroinformatics Group