| 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 |
WCG techs wont action reports of lost devices that had tasks "in progress", maybe when there are literally thousands, and even then, they might think twice as bulk aborting tasks will clog the reliable device queue tremendously. There's a dirty way to do this yourself though, stumbled on during last ditch recovery effort. It's really only suitable for those that do not care about new device registrations and with a little planning they wont even appear in the device statistics, since only those are counted that have a valid result returned.
The problem is that a reinstall often creates a device with the same name, so which is which? Well, apart from a creation date printed off the right, the device names are really just the user friendly representations. If one hovers on the device name in My Grid > Device manager, the link has a number in it (address shows for Firefox status bar). For Instance: Listed in the DM as: Laptop01 school 11/2/07 When hovering on link showing: http://www.worldcommunitygrid.org/ms/device/v...d=378235&deviceType=B i.e. the device has number 378235 internally. Now how to progress: 1. Create a device profile associated with 1 intermittent, non work available science and make that the Default profile. 2. Install the new client after the device loss and attach it to WCG. The default profile would get associated and no work would get fetched (not 100% sure about that bit... it could be that WCG sends a random set of work in a "get to know the new cruncher" handshake) 3. Stop the new client completely, and find the client_state.xml file 4. Open the file with an flat text editor such as Notepad or Gedit depending on OS, under extreme caution, and look up near top the <domain_name> field, which should be the present host name. Replace that with the number of the lost device with tasks "in progress" still listing on the Result Status page. 5. Save the file making sure it's name remains client_state.xml 6. Start client. 7. Observe in message/event log how BOINC connects, reports that the device is not happy, and creating a new host_cpid registration. In my case, the 60 odd that were "In Progress" got an Aborted mark, and one of the Jan 27th still sitting in PV jail. 8. After this has happened, associate the new host to a device profile that does supply regular work or change the "Default" profile's science selection. Let me know if this is reproducible, as obviously, I've done this only once. After proven to work repeatedly, will collate a formal FAQ. cheers and thanks in advance for any input. --//-- PS, yes yes, probably merging devices would help to add up multiple device statistics, but to the servers, the newest registration for that host can only be the active registration... the lost "in progress" will still be lost and sit there to get redistributed when they expire. Of course, those that have a backup, any backup of the data_dir, will not have that issue, having restored the old dataset. The servers will just consider the client and server out of sync, abort the old tasks and issue new (with day quota, as the many aborts will put your device temporarily on a work fetch diet, if there were many. Maybe a deterrent not to mess with things :) |
||
|
|
|