Impossible deadlines
Impossible deadlines |
|
| log in |
Message boards : Number crunching : Impossible deadlines
1 · 2 · Next
| Author | Message |
|---|---|
|
I currently have 53 errors and they are all tasks that had deadlines within just a few minutes of the 'Sent' time. My machine is not up there on crunch time ranking like many of you, but even if it were it seems a big ask. | |
ID: 1284749 ·  | |
|
Richard Haselgrove  Volunteer tester Send message Joined: 4 Jul 99 Posts: 10922 Credit: 80,706,298 RAC: 39,131 
 | |
|
Don't worry about it. The explanation is well known, and has been given on these boards many times - but it's only really of interest to people who do monitor their machines obsessively. | |
| ID: 1284755 · | |
|
I take it as an indication of how stresed the download system is, | |
| ID: 1284756 · | |
|
Thanks Richard & Clive. I shall relax and simply consider it a measure of how hard S@H as a whole is stressed. - And the speedy replies as a measure of the enthusiastic community we have. ;) | |
| ID: 1284760 · | |
The explanation is well known, and has been given on these boards many times I think we should have a sticky thread about it, this question seems to come back at least 1-2 times a week (including posts in the panic thread). ____________ .  | |
| ID: 1284772 · | |
The explanation is well known, and has been given on these boards many times People actually read those? Ideally I think the solution would be to change the results messages from "Outcome No reply" & "Timed out - no response" to something like "Outcome server canceled" & "Timed out - server canceled" Something more descriptive would be better, but I haven't had coffee yet this morning. ____________ SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the BP6/VP6 User Group today! | |
| ID: 1284777 · | |
|
That would be even better. There is already the status "Canceled by server", it's used for tasks cancelled by server in case of results returned after deadline, i.e. the replacement task is canceled after the late task has been returned and maybe validated (on projects which use this feature, for example Collatz). That status could be used here too, the current messages are completely wrong. | |
| ID: 1284793 · | |
 RaistmerVolunteer developer Volunteer tester  Send message Joined: 16 Jun 01 Posts: 5128 Credit: 64,867,750 RAC: 17,224 
| |
|
Unfortunatelly, these more destructive... | |
| ID: 1284975 · | |
+1 | |
| ID: 1284980 · | |
|
Isn't this new wording? Change today? | |
| ID: 1284983 · | |
Isn't this new wording? Change today? The client has had that message for quite some time. ____________ SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the BP6/VP6 User Group today! | |
| ID: 1285147 · | |
|
I do wonder why this AP timed out. | |
| ID: 1285155 · | |
|
Now we're at it... How about the BOINC manager working on tasks in order of deadline? I have enough time for all tasks on my system (most of the time...), but I always notice that tasks with a deadline of Nov 3 are already processed while deadlines of Sept 30 are still waiting... | |
| ID: 1285156 · | |
Now we're at it... How about the BOINC manager working on tasks in order of deadline? I have enough time for all tasks on my system (most of the time...), but I always notice that tasks with a deadline of Nov 3 are already processed while deadlines of Sept 30 are still waiting... AFAIK, BOINC works in strict FIFO order unless it thinks that one WU will miss a deadline. If it were working by dealine order, then long tasks with long deadlines will be allways delayed and suspended when new work with short deadlines appears. And then projects with long tasks (and long deadlines) will have serious issues to get their work done (not to mention that then some projects may try to reduce the deadlines to put themselves very high in the order lists). If the client scheduller notices that some WUs will miss the deadline then it enters in "panic mode" (aka High priority) and then it changes from the FIFO order to the deadline order and crunches first those tasks in danger... ____________  | |
| ID: 1285176 · | |
I do wonder why this AP timed out. My guess would be that it was stuck downloading and did not finish the download in time. I am seeing that every now and then now that I am having problems downloading. (This is especially more the case when it is a large file as APs are) ____________  SETI@home classic workunits 4,019 SETI@home classic CPU time 34,348 hours | |
| ID: 1285233 · | |
I do wonder why this AP timed out. My guess is different...and I think its a bug (or feature?) in the resent code that aborts the APs that were sent to a CPU if they get resent to an Nvidia GPU that is not OpenCl "capable" (i.e. its not on a host running Boinc 7.xx)... ____________ | |
| ID: 1285246 · | |
I do wonder why this AP timed out. I have disabled AP's for GPU for now, so it can't be that. | |
| ID: 1285248 · | |
I do wonder why this AP timed out. At the contrary, I think it's more likely then... If the scheduller was not able to sent them to your GPU then thats why they were "aborted"... The resent code doesnt put WUs on hold waiting for a request to a more suitable device... if the scheduller were doing that then instead of the usual short deadline on vlars, they will be skipped until you need a CPU task... (I have several APs "aborted" through the deadline in all my hosts. All them use BOINC 6.10.60 but only one doesnt have the apps to crunch them on GPU...) Edit: What I think, is that with the adition of the new OpenCl stock apps for ATI and Nvidia, and trying to make them compatible with older clients using the optimized apps, and all the workarounds made to avoid vlars on GPU and whatnot... something is not working as intended with the resend of APs... ____________ | |
| ID: 1285254 · | |
I do wonder why this AP timed out. Well then that answers it, that AP just suffered the same fate that VLAR's do. Cheers. ____________ | |
| ID: 1285260 · | |
I do wonder why this AP timed out. I disabled, removed the app_info section, for GPU APs days ago, so that AP could only be sent/resent to CPU. | |
| ID: 1285264 · | |
Message boards : Number crunching : Impossible deadlines
| Copyright © 2016 University of California |
<--- Searching for this one ;-)
