| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Drug Search for Leishmaniasis Forum
Thread: WU Stuck in Waiting to send |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 16
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Seems to me that the "until death do us part" was already reached [for DSFL/GFAM and Project 20] as before having these devices included in the Intel group led to invalid results... how much effort is acceptable to keep the last outpost in play?
From past conversations with knreed, there would be a feature coming that identifies a device if unsuccessful at science X Y or Z, and then reject further requests for a longer period. Not read if there's also the permanent, but to me there's no point of assigning tasks to devices that are known to always fail on same. --//-- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Ok, WCG gave Socket-A all the chances for DSFL/GFAM. We will miss you Socket-A: "Invalids did us part."
 Speaking of a different part, time for me to look forward to considering the Piledriver, a.k.a part-2 of the AMD Bulldozer-class CPU family coming up next from AMD. I wish it will be an 8-core with hardware-assisted hyperthreading for a total of 16-cores.; |
||
|
|
KWSN - A Shrubbery
Master Cruncher Joined: Jan 8, 2006 Post Count: 1585 Status: Offline |
Thanks for the responses. As long as there are non-VINA applications, I'll keep running this machine while I can. So far, I have only needed to replace the CPU fan, but there's always the next failure looming on the horizon.
---------------------------------------- Distributed computing volunteer since September 27, 2000 |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
From past conversations with knreed, there would be a feature coming that identifies a device if unsuccessful at science X Y or Z, and then reject further requests for a longer period. Not read if there's also the permanent, but to me there's no point of assigning tasks to devices that are known to always fail on same. While it's possible to permanently blacklist a specific computer, I'm not sure if it's possible to do this just for a specific application-version for individual computers... But, atleast in cases like these there it's known that a whole class of old, slow computers is either erroring-out or only gives invalid results for an application, it's little point of relying on the per-application quota-limits that will after some time set quota to 1 due to all the errors. A better solution is to use plan-classes, example remove the current DSFL/GFAM-applications and instead release them under an app_plan_SSE2. Since pre-64-bit Amd's don't have SSE2, and it's the same with old P3 and similar cpu's, these cpu's won't get any DSFL/GFRAM-work at all if the only available applications is of the app_plan_SSE2-type. While BOINC currently don't include a SSE2-plan-class, it should be easy to use the SSE3-one as basis.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: 
|
From past conversations with knreed, there would be a feature coming that identifies a device if unsuccessful at science X Y or Z, and then reject further requests for a longer period. Not read if there's also the permanent, but to me there's no point of assigning tasks to devices that are known to always fail on same. What happens is that the max_results_day field is added to the host_app_version level. This means that if a client errors out completely or returns only invalids for one app_version but runs other projects fine, then it will drop to 1 result max per day for that project. So it doesn't quite drive it to 0 but that is how it should be for an automatic system since if it is fixed, then it should automatically recover. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OK, great, at least at app version level, but distinctly remember the suggestion for it to be longer, since the CPU as a quorum validator problem is likely not going to go away. At least, the chance with this is substantially less for a 2 or more opted device to run dry. For the 'All Sciences' no worries, the 'if there is no work' for' rule maybe needing review. Mind you, with a quota of 80 per core/day, it will still take multiple days on a 2 and up science selected device to reach that 1 per day quota. Maybe the 'general' quota then also needs adjusting to also be at a science app level? Any such effort of course has to take the achievable gain into account, but to the individual it will most always work as a disappointment/frustration if her/his device gets hit with the issue.
--//-- |
||
|
|
|