| 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: 1
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Maybe we might do well with a MDIY [Member DIY] 'Changed without notice' thread. 2 go bust, one with the too many exits [not our fault] and the second on "(unknown error) - exit code -529697949 (0xe06d7363)", we've seen a number of times but no real explanation to be found [see my post researching this]. In this case, I think it was a Wednesday busy with backup effect. Noticed validations lagging way behind, so extra copies were not going out one by one, but in twos, since both returned during the busy phase. What's goofy/odd/weird/abnormal/deviative [lost for more words], is that the deadline is it's 30%... where did we see the 30 second new to drop it from 35% ;?
MCM1_ 0000703_ 5621_ 2-- - In Progress 12/18/13 13:37:47 12/20/13 16:01:47 0.00 0.0 / 0.0 MCM1_ 0000703_ 5621_ 3-- - In Progress 12/18/13 13:37:46 12/20/13 16:01:46 0.00 0.0 / 0.0 MCM1_ 0000703_ 5621_ 1-- 728 Error 12/17/13 21:25:40 12/18/13 10:34:20 1.65 19.7 / 0.0 MCM1_ 0000703_ 5621_ 0-- 728 Error 12/17/13 21:25:27 12/18/13 12:09:09 0.00 0.1 / 0.0 @techs: Never mind the % repair deadline change... we've been conditioned [I only noticed because with an exact 1 day buffer + TTC uprounding, this one still jumped ahead on the client queue]... courtesy of the v7 EDF logic. What really would be nice to know is that bolded error message, seen during beta and IIRC reported as 'all report with this error', meaning if not fixed, these devices are best somehow taken off the MCM receipt list. Smells like one of those HPF2 never fully resolved crash and burn without computing time, but if only doing MCM [exclusive] could be sending many a day to the repair queue, which we all like shortest and with 40% repair deadline and not 30% ;D |
||
|
|
|