| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: BOINC 6.10.58 on Mac OS X - slow to 'report' completed items |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 7
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I have an issue with current BOINC 6.10.58 running on Mac OS X 10.6.6 (latest Snow Leopard). It runs and uploads completed WUs, but the WUs in 'Ready to Report' status keep piling up. They will report (eventually), but more than once I hit the 'Update' button on the Projects page to clear them. Today I had 7 in 'RtoR' status. Why does it do this?
I have same software installed on a Windows XP box, running under the same user name, that never gives that issue - uploads WUs, reports them as complete. Both boxes have Intel Core 2 Duo CPUs and both are in Run Always mode and have Network Always Available. Why am I having this discrepancy? |
||
|
|
Powhatan
Advanced Cruncher Joined: Oct 20, 2009 Post Count: 58 Status: Offline Project Badges: 
|
I notice the same thing on my Mac, same versions as you. Curiously, I usually notice the same behavior on my other platforms: windows and Linux.
Don't know if occured only recently or something that's been going on for a while. There's nothing in the messages log to indicate a problem. Not quite sure how long they sit till report, but I believe it's between 15 to 60 minutes. I've just felt it's the manager knowing when it was best to communicate. |
||
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 3010 Status: Offline Project Badges: 
|
Generally, it IS the BOINC manager knowing when best to communicate - as that's the most efficient way for it to work.
----------------------------------------Basically, there are several automatic 'triggers' (I do believe they're documented in the FAQ's), but the three main ones are here; 1) When BOINC is requesting more work, it'll send back any that are in the RtR state at the same time. 2) When the RtR have been waiting 24 Hrs 3) When a WU is within 24 Hrs of it's deadline, it'll send the results back and then do the RtR function straight away. As I say, there are more 'triggers' (other than, of course, manually hitting the 'Update' button). Is this the kind of behaviour you're seeing?, or is it something different? BTW, I'm not running a Mac, so I can only go on what BOINC is supposed to do - there may be something peculiar with this release/configuration. Obviously, the more information you can provide, the easier it'll be for it to be resolved.  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Generally, it IS the BOINC manager knowing when best to communicate - as that's the most efficient way for it to work. Basically, there are several automatic 'triggers' (I do believe they're documented in the FAQ's), but the three main ones are here; 1) When BOINC is requesting more work, it'll send back any that are in the RtR state at the same time. 2) When the RtR have been waiting 24 Hrs 3) When a WU is within 24 Hrs of it's deadline, it'll send the results back and then do the RtR function straight away. As I say, there are more 'triggers' (other than, of course, manually hitting the 'Update' button). Is this the kind of behaviour you're seeing?, or is it something different? BTW, I'm not running a Mac, so I can only go on what BOINC is supposed to do - there may be something peculiar with this release/configuration. Obviously, the more information you can provide, the easier it'll be for it to be resolved. Most likely it's a combination of the above. I could be just over anxious to see results reported. Probably best to leave things alone. |
||
|
|
macusen
Advanced Cruncher Germany Joined: Mar 31, 2009 Post Count: 59 Status: Offline Project Badges: 
|
Yes, I can confirm, what gb009761 said:
----------------------------------------If there is one of these "triggers" met, BOINC reports the RtoR WUs. And for me it's on Mac OS 10.6.6 on a Core 2 Duo.  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The more cores there are in a device working on WCG, the shorter the time becomes between completing a task [and immediately uploading the non-scheduler involved result files] and requesting new work.
Sometimes when the servers are very busy, clients are told to back off for e.g. 60 minutes since RtR clearing is non-critical for immediate project continuity, yet that scheduler/validator combo being the heaviest part. It's why setting cache to really extreme low is not advisable and has a default of 0.25days, so 6 hours of server interruption can be bridged at the minimum. Those that crunch multiple grids actively [i.e. also outside WCG], are bound to see longer time spans between task completion and RtR clearing, simply because the client will also be backfilling from different projects and usually has at least 1 task of the active grids in cache already to cover it's share time... there's lesser frequent need calling for work from e.g. WCG. The phenomena of reducing cache from say 4 days to 1 day does cause a temporary extended delay of RtR clearing. No rush as there are no work calls for longer. Then the 24 hour delay will probably be seen more frequent. There are actually some 10 kick off conditions when a task is reported, but for that you'll have to read the FAQs. Some will think: Too much info ;>) --//-- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
My cache I set on both boxes to 2.5 days, since in the intervening six months that I was off WCG, I got (much) faster boxes, so it does units in only a couple of hours.
|
||
|
|
|