| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 40
|
|
| Author |
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1412 Status: Offline Project Badges:
|
Proposing to pull the internet cable is like asking to squeeze my aorta
Client 6.12.34 (recommended version by Berkeley) The work fetch module is running every minute (pulling the cable has no influence), directly after a prefs update or a preference override and directly after allowing new work for a project. It seems that the latter is changed in 7 (see my former post) and you have to wait for the 1 minute cycle. In Boinc's event log there's noted the reason why from a project no work is fetched like (no new tasks) or (comm deferred). For how long 'comm deferred' you have to look at the projects tab. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Right, the computing of buffer size and work need will be in 1 minute intervals, but the acting upon would be incrementing.
The Backoff seconds is showing from 7.0.17 in the event log per the developer change log * client: instead of saying "comm deferred", say "project backoff XXX.XX". and just hit the fn-f12 to suspend the WIFI and this popped out: 217 World Community Grid 22-2-2012 16:09:17 [sched_op] Starting scheduler request 218 World Community Grid 22-2-2012 16:09:17 Sending scheduler request: To fetch work. 219 World Community Grid 22-2-2012 16:09:17 Requesting new tasks for CPU 220 World Community Grid 22-2-2012 16:09:17 [sched_op] CPU work request: 58745.27 seconds; 0.00 devices 221 World Community Grid 22-2-2012 16:09:18 Scheduler request failed: Couldn't resolve host name 222 World Community Grid 22-2-2012 16:09:18 [sched_op] Deferring communication for 1 min 32 sec 223 World Community Grid 22-2-2012 16:09:18 [sched_op] Reason: Scheduler request failed 224 22-2-2012 16:09:19 Project communication failed: attempting access to reference site 225 22-2-2012 16:09:20 BOINC can't access Internet - check network connection or proxy configuration. 226 World Community Grid 22-2-2012 16:10:51 [checkpoint] result GFAM_x2bl9Pvivax_DHFRdry_0007219_0041_1 checkpointed 227 World Community Grid 22-2-2012 16:10:53 [sched_op] Starting scheduler request 228 World Community Grid 22-2-2012 16:10:53 Sending scheduler request: To fetch work. 229 World Community Grid 22-2-2012 16:10:53 Requesting new tasks for CPU 230 World Community Grid 22-2-2012 16:10:53 [sched_op] CPU work request: 59502.76 seconds; 0.00 devices 231 World Community Grid 22-2-2012 16:10:54 Scheduler request failed: Couldn't resolve host name 232 World Community Grid 22-2-2012 16:10:54 [sched_op] Deferring communication for 1 min 37 sec 233 World Community Grid 22-2-2012 16:10:54 [sched_op] Reason: Scheduler request failed 234 World Community Grid 22-2-2012 16:12:35 [sched_op] Starting scheduler request 235 World Community Grid 22-2-2012 16:12:35 Sending scheduler request: To fetch work. 236 World Community Grid 22-2-2012 16:12:35 Requesting new tasks for CPU 237 World Community Grid 22-2-2012 16:12:35 [sched_op] CPU work request: 60606.27 seconds; 0.00 devices 238 World Community Grid 22-2-2012 16:12:36 Scheduler request failed: Couldn't resolve host name 239 World Community Grid 22-2-2012 16:12:36 [sched_op] Deferring communication for 1 min 27 sec 240 World Community Grid 22-2-2012 16:12:36 [sched_op] Reason: Scheduler request failed 241 World Community Grid 22-2-2012 16:12:58 [checkpoint] result GFAM_x2bl9Pvivax_DHFRdry_0007235_0075_0 checkpointed 242 World Community Grid 22-2-2012 16:14:06 [sched_op] Starting scheduler request 243 World Community Grid 22-2-2012 16:14:06 Sending scheduler request: To fetch work. 244 World Community Grid 22-2-2012 16:14:06 Requesting new tasks for CPU 245 World Community Grid 22-2-2012 16:14:06 [sched_op] CPU work request: 61588.72 seconds; 0.00 devices 246 World Community Grid 22-2-2012 16:14:07 Scheduler request failed: Couldn't resolve host name 247 World Community Grid 22-2-2012 16:14:07 [sched_op] Deferring communication for 1 min 36 sec 248 World Community Grid 22-2-2012 16:14:07 [sched_op] Reason: Scheduler request failed 249 World Community Grid 22-2-2012 16:14:48 [checkpoint] result GFAM_x2bl9Pvivax_DHFRdry_0007227_0238_1 checkpointed 250 World Community Grid 22-2-2012 16:15:47 [sched_op] Starting scheduler request 251 World Community Grid 22-2-2012 16:15:47 Sending scheduler request: To fetch work. 252 World Community Grid 22-2-2012 16:15:47 Requesting new tasks for CPU 253 World Community Grid 22-2-2012 16:15:47 [sched_op] CPU work request: 63414.33 seconds; 0.00 devices 254 World Community Grid 22-2-2012 16:15:48 Scheduler request failed: Couldn't resolve host name 255 World Community Grid 22-2-2012 16:15:48 [sched_op] Deferring communication for 1 min 59 sec 256 World Community Grid 22-2-2012 16:15:48 [sched_op] Reason: Scheduler request failed 257 World Community Grid 22-2-2012 16:16:04 [checkpoint] result GFAM_x2bl9Pvivax_DHFRdry_0007227_0159_1 checkpointed 258 World Community Grid 22-2-2012 16:17:48 [sched_op] Starting scheduler request 259 World Community Grid 22-2-2012 16:17:48 Sending scheduler request: To fetch work. 260 World Community Grid 22-2-2012 16:17:48 Requesting new tasks for CPU 261 World Community Grid 22-2-2012 16:17:48 [sched_op] CPU work request: 65309.07 seconds; 0.00 devices 262 World Community Grid 22-2-2012 16:17:53 Scheduler request completed: got 2 new tasks It's better this way, as in past it would just keep trying in 1 min intervals IIRC and fill up the log. Did Hit fn-f12 again after it reached 2 minutes, so can't tell if it goes further. --//-- |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1412 Status: Offline Project Badges:
|
Is World Community Grid the only project listed?
If so, with 2 or more projects the behaviour could be different. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
WCG is the only active... everything else is suspended. The calculation of the buffer is overall and encompasses all active projects to determine who's next up for a work fetch, I'd venture to think. Moreover by doing these bulk calls, each project will get less visits to request work, the balancing of projects per their resource share over a longer time period. I'm sure some wont like that and continue their MM act to keep their RACs up to snuff... to each her/his own, but that's not what the object was, nor do I think the developers would accommodate. BOINC is to do the job, on it''s own.
But we're wondering off from the outset... when the buffers will be filled under old and new. --//-- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Think the Min/Max additional buffer topic can be binned as it is currently captured. Just discovered that at 0.75 MinB and 1.00 MaxAB, the cache has been trickle filling all day with 7.0.17 (see time stamps of receipt time at end of below task records). But, there's now a 7.0.18 Alpha out... it's like a flippin crap shoot in Atlanta.
World Community Grid 6.13 sn2s SN2S_A37114_0000006_0020_1 - (-) 0,00 0,000 11:52:14 09d,12:10:53 23-2-2012 10:37:15 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000006_1027_1 - (-) 0,00 0,000 11:52:14 09d,12:10:53 23-2-2012 10:37:15 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000006_0466_0 - (-) 0,00 0,000 11:52:14 09d,12:11:15 23-2-2012 10:37:34 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000006_0073_1 - (-) 0,00 0,000 11:52:14 09d,12:12:00 23-2-2012 10:38:20 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000006_1112_0 - (-) 0,00 0,000 11:52:14 09d,12:17:56 23-2-2012 10:44:16 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000025_0534_1 - (-) 0,00 0,000 11:52:14 09d,15:43:53 23-2-2012 14:10:13 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000025_0785_0 - (-) 0,00 0,000 11:52:14 09d,15:43:53 23-2-2012 14:10:13 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000029_0814_0 - (-) 0,00 0,000 11:52:14 09d,17:42:28 23-2-2012 16:08:49 Ready to start World Community Grid 6.13 sn2s SN2S_A37114_0000032_0758_0 - (-) 0,00 0,000 11:52:14 09d,18:58:30 23-2-2012 17:24:50 Ready to start World Community Grid 6.13 sn2s SN2S_AAA74693_0000011_0074_1 - (-) 0,00 0,000 11:52:14 09d,20:44:19 23-2-2012 19:10:40 Ready to start World Community Grid 6.13 sn2s SN2S_AAA74693_0000018_0491_1 - (-) 0,00 0,000 11:52:14 09d,23:13:57 23-2-2012 21:40:18 Ready to start World Community Grid 6.13 sn2s SN2S_AAA74693_0000019_0850_1 - (-) 0,00 0,000 11:52:14 09d,23:35:04 23-2-2012 22:01:25 Ready to start --//-- |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1412 Status: Offline Project Badges:
|
.... But, there's now a 7.0.18 Alpha out... it's like a flippin crap shoot in Atlanta. Be happy, because of one of the fixes: | * Fix WCG download issue Setting the Min.buffer to the tasks deadline e.g. 3.0 days, let start the tasks run in High Priority, although there is only 6 minutes/core work in buffer (NNW). It looks like Min.buffer is acting like CE. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Yes, when it comes down to setting off high priority processing MinB acts same as old CE, but the silliness is that CE was really the wrong descriptor, since when connected, the client would still continue to fetch and report [in various ways depending on version]. Of course, that HP state would only happen on tasks that are due within, say 4-6 days [assuming MaxAB is zero], as when the task of 6 days due would get it's turn, it would already have passed another 3 days... does that make sense?
----------------------------------------At any rate, I'm parking the FAQ for now... it's not settled from what I'm taking off the alpha mail list... more work fetch rule changes. It's only settled for the point release one has at the present moment. Still to load 7.0.18 and test those queued FAAH/HFCC. Downloading them with 7.0.17 gave no issue i.e. the last fix of WCG download problems is focused on the sciences with those .gzb/.gz files FAICT. Then I'll try a few HPF2 and HCC too, skipping HCMD2... too few left to mess with. --//-- edit: Such joys, now hitting update button will fetch no matter if buffer is filled to setting, fetch at least 1 task. snip from 7.0.17 change log: client: tweak to work-fetch policy: above the min buffer (idea from John McLeod).If we're making a scheduler RPC to a project for reasons other than work fetch, and we're deciding whether to ask for work, ignore hysteresis; i.e. ask for work even if we're My interpretation is that at least the server connect did not go to waste, but as I tried, hitting update 4x in a row, 4 tasks were fetched and it does act when MaxAB is also exceeded. The other positive side is that less complaints will arrive when eager beavers hit update, wanting work [even though not needed] and not getting any. :D [Edit 1 times, last edit by Former Member at Feb 24, 2012 10:59:10 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
A little polishing to the draft FAQ, hitting Update to for instance clear Ready To Report accumulations in the MicroManager way or just out of "can't hold it any more", is combined with a work request if there's room. Kind of the view that "why waste a connection and not send work if the buffer is not filled up to the MaxAB value".
Of course, hitting Update is mostly a No No. Let BOINC do the job... long as it's busy on all fronts, why interfere? [like the referee blowing the whistle when no foul has been committed] --//-- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Can't edit the Draft FAQ OP anymore [too old], but will address a question asked by PecosRiverM few days ago, how to push short deadline tasks with the 7.0.x client. Here is:
----------------------------------------1) Applies at least to version 7.0.31 (which is what I'm running on W7, but likely 7.0.28 does same) 2) Settings: -a) MinB set to 1.50 days -b) MaxAB set yo 0.00 days -c) Switch between applications every 2400.00 minutes (about 1.67 days) -d) Leave application in memory when suspended: On (ticked) Not really watched it intensely, but had noticed that the actual buffer each time it dropped below 1.5 days [including work started] is backfilled to satisfy the MinB setting, so have an equivalent of > 1.5 days. *All* repair tasks are running in High Priority state, having a deadline of 4 days, without knobbing. Turnaround time basically the run time + time for soonest reconnection possibility, which means when they arrive just before a scheduled off-line, they get immediately uploaded on the next open network connection. The Ready to Report (RtR) though is treated normal, cleared when any of the 12 conditions in the client rulebook are met, such as when new work is required. In practical terms, with a 1.5 day buffer, next morning with a fixed 9 hour off-line, the MinB state is sure to be less than 1.5 days, so reporting is "very soon", *without* any other manual or config help of most frowned sorts. P.S. If you don't know what MinB or MaxAB is... this topic explains it from the start ;>) [Edit 1 times, last edit by Former Member at Aug 27, 2012 4:13:09 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
On closer inspection, strike the "Switch between applications every..." part. It does nothing in 7.xx either to force short deadline tasks ahead, even when upped to 6000 minutes. As can be seen in the below screenshot, the 4 day deadline tasks sat around for a while... The SN2S/DSFL for a day+, the HCC several hours, before being pushed ahead. Also can be seen that there are more queued for DSFL/SN2S/HCC1 with over 3 days deadline in the future happily waiting for their FIFO turn or when BOINC considers a panic mood is ordered for with the 1.5 day MinB setting and the safety margin used [The network on frac is about 0.6]. There's even an SN2S task with just a few hours more short deadline that got preempted, to let even shorter due HCC ahead [Standard deadline 7 days, repair deadline 2.8 days]. With 8GB memory and LAIM on it can't bother me, long as the final deadline is met.
![]() |
||
|
|
|