| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Help Conquer Cancer
Thread: HCC resent tasks returned within 4days but status is Too Late |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 7
|
|
| Author |
|
|
sk..
Master Cruncher http://s17.rimg.info/ccb5d62bd3e856cc0d1df9b0ee2f7f6a.gif Joined: Mar 22, 2007 Post Count: 2324 Status: Offline Project Badges: 
|
Project Name: Help Conquer Cancer
Created: 08/09/2011 08:50:52 Name: X0000121960954201007191011 Minimum Quorum: 2 Replication: 2 Result Name App Version Number Status Sent Time Time Due / Return Time CPU Time (hours) Claimed/ Granted BOINC Credit X0000121960954201007191011_ 3-- 642 Valid 14/08/11 06:18:18 14/08/11 17:13:16 3.95 32.3 / 20.1 X0000121960954201007191011_ 2-- 642 Too Late 11/08/11 11:04:47 15/08/11 08:00:20 1.59 20.7 / 0.0 X0000121960954201007191011_ 1-- 642 Valid 10/08/11 18:42:28 11/08/11 03:40:41 1.32 20.1 / 20.1 X0000121960954201007191011_ 0-- 642 Error 10/08/11 18:42:23 11/08/11 07:54:57 0.00 0.0 / 0.0 Project Name: Help Conquer Cancer Created: 08/02/2011 03:39:20 Name: X0000120500479201006041922 Minimum Quorum: 2 Replication: 2 Result Name App Version Number Status Sent Time Time Due / Return Time CPU Time (hours) Claimed/ Granted BOINC Credit X0000120500479201006041922_ 3-- 642 Valid 14/08/11 00:21:42 14/08/11 08:52:34 1.66 35.4 / 35.2 X0000120500479201006041922_ 2-- 642 Too Late 11/08/11 05:08:06 15/08/11 08:00:20 1.63 21.2 / 0.0 X0000120500479201006041922_ 1-- - No Reply 03/08/11 20:38:38 10/08/11 20:38:38 0.00 0.0 / 0.0 X0000120500479201006041922_ 0-- 642 Valid 03/08/11 20:38:31 04/08/11 03:58:46 1.55 35.1 / 35.2 I know the standard deadline is 7days, and I can see from other resent HCC tasks that the resend deadline is now under 3days (for both _2 and _3 resends). I would like to have the option to opt out of such short deadline resends on some systems, but would be quite happy to run more resends on some other systems. Boinc is not able to predict long weekends, never mind random shutdowns, and does not automatically push resends to the top of the queue (even on HCC only systems), or even automatically report tasks. So if this is going to be an issue for other projects (HCC nearing its end) perhaps the techs could facilitate such an option within device profiles? Off to queue jump a few _2 and _3 HCC tasks. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I haven't had this problem but that may be because I keep the "Additional work buffer" set to 2 days on my quads. Less on my duo and duo lap top.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
skgiven,
There's the ol ''connect every'' trick to set that above 2 days, which would stop repairs, being send, up front. There's also the old switch/preempt trick set to e.g. 5 days to force these repairs ahead. These computers could then be switched off during the weekend and eventually fall out of the RR class. Maybe if playing with the UL/DL budget settings, you can stop BOINC to not cache all the work based on the ''connect every'' Never tried that. And whilst they were too late and redundant, the scripts take periodically care to still grant credit... at least I've had 2 ''Too Late'' recently which got the auto-magic treatment. Deadlines are made to allow weekend switch-offs and if a client can't then I can't see that as a members fault. There are prior discussions on working the options to not get repairs. A ''don't send me short deadline work" was on the wish list. --//-- NB: Repairs in general are 40% of original deadline! |
||
|
|
sk..
Master Cruncher http://s17.rimg.info/ccb5d62bd3e856cc0d1df9b0ee2f7f6a.gif Joined: Mar 22, 2007 Post Count: 2324 Status: Offline Project Badges:
|
Sound suggestions but the systems in question are not readily accessible, and have local configurations – exactly what I’m not even sure, but probably low cache and don’t crunch or use network when in use. They have been attached to WCG for a fairly long time (years) and have low RAM and bandwidth restrictions as is. They are on and off quite a bit, sporadically, so setting a large cache would be a bigger problem. I wasn’t aware of the 40% of original repair rule. Just saw the 4day rule.
Not bothered about any loss of credit, well not from a few tasks now and then, more the wasted runtime, but which project doen’t have that? Perhaps a percentage complete update 'trickle' report to servers for running tasks (when reporting, or asking for work) would be useful for some Boinc projects, but I think that would be too heavy for WCG; too many tasks. Definitely not needed/wanted on high end low cache systems for short runtime projects (HCC), but possibly for resends only on longer tasks in the future. Holidays and long weekends are difficult to account for server side; you would need to make location tables and arrays of national holidays. Doable, but it would be big, and the work profile would have to be just that, a location specific profile to which such arrays could be applied. Anyway, it would take Berkeley to implement an “apply local holidays to work profile systems” check box. Can’t see that making it to high priority, and I think ‘local holidays’ might be more difficult than just by country (state, province, time zones...). So the ''don't send me short deadline work" suggestion has been unknowingly bumped ;) |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
There's one more trick combined with the ''connect every'' and switch time for which the RTFM functions need to be employed, but I won't print it, nor do I expect it to be reprinted. A future server function [6.13 I suspect] will be able to tell clients to do the very thing, when the project requires ASAP returns. I'm going to test this minute to see if it still works under 6.12.
----------------------------------------BTW, make a shutdown script using boinccmd forcing an update, make an icon on the desktop and start-bar, so it will execute on orderly power-down. The script could include to not fetch work that round prior to the update, snooze the client, then set workfetch back, to minimize work stored over the weekend. On power up, normal operation since snooze also expires when the computer is off. Trickle is really only employed for the multi-day projects... CPDN does that and think to have seen it at QMC, the Quake project does it too, so work secured, and intermediate credit is granted. HCC is a ''if lost, it's lost at 1 hour a pop'', on my quad. --//-- edit: Quake (Catcher Network) [Edit 1 times, last edit by Former Member at Aug 16, 2011 12:19:25 PM] |
||
|
|
JSYKES
Senior Cruncher Joined: Apr 28, 2007 Post Count: 202 Status: Offline Project Badges: 
|
I'm quite surprised that there isn't a way (or at least a simple way, if one does actually exist in some hidden recess of the software) of re-ordering WU's to process in date order (more or less) so that the schedule becomes locally (and automatically) prioritised - Is there a way of doing this (that I haven't found) or is there a way that this could be worked into an upgrade in due course???
---------------------------------------- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
JSYKES,
It's been mentioned twice in this thread, the "switch" time aka "switch between application every xx minutes". The default is 60 minutes, but if you set it to a longer time than the repair jobs deadlines, which are generally 4 days, then e.g. entering 5500 minutes makes your client run in panic mode long as there are tasks with those <= 4 days deadline. Soon as there are none, the client resumes in FIFO mode. If you want to always run order of deadline then try the switch time of 14400 minutes, then mix HCC (7 days) with FAAH (10 days) and watch the fun evolve. Some client versions stop work fetching when all threads are processing in High Priority, so cache will jump up and down. --//-- P.S, Just tried the trick on a 6.12.34 client. It's not jumping the short deadline jobs forward (there are 2), but it does work for 6.10.58 according many forum reports. The cache size might work into the equation now i.e. at 1 day, a job due on the 20th will still get done in time. by the FIFO principle. Not going to try the ''connect every'' function as that also adds to the cache. i.e. set it to 2 days and you'll get work cached for 2 days. |
||
|
|
|