Message boards :
Number crunching :
Lost WU
Message board moderation
Author | Message |
---|---|
Send message Joined: 3 Sep 07 Posts: 2 Credit: 439,099 RAC: 0 |
I finished computation of wu gs_3730382_1216077095_2569343_0 but it is not in my list. Seems like it never been in list... How it is possible? ID Date Project Message 48 15.7.2008 21:20:47 Milkyway@home Computation for task gs_3730382_1216077095_2569343_0 finished 49 15.7.2008 21:20:47 Milkyway@home Starting gs_3721282_1216047814_2550830_1 50 15.7.2008 21:20:47 Milkyway@home Starting task gs_3721282_1216047814_2550830_1 using astronomy version 122 51 15.7.2008 21:20:49 Milkyway@home [file_xfer] Started upload of file gs_3730382_1216077095_2569343_0_0 52 15.7.2008 21:20:55 Milkyway@home [file_xfer] Finished upload of file gs_3730382_1216077095_2569343_0_0 53 15.7.2008 21:20:55 Milkyway@home [file_xfer] Throughput 476 bytes/sec 54 15.7.2008 21:21:59 --- Time passed...reporting result now. 55 15.7.2008 21:21:59 Milkyway@home Sending scheduler request: To report completed tasks 56 15.7.2008 21:21:59 Milkyway@home Reporting 1 tasks 57 15.7.2008 21:22:04 Milkyway@home Scheduler RPC succeeded [server version 511] |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
I finished computation of wu gs_3730382_1216077095_2569343_0 but it is not in my list. Seems like it never been in list... This is most likely due to the Task Purging Daemon being set to get rid of completed tasks almost as soon as they pass validation and get assimilated. IOW's, if you aren't there to take a look at the Host Summary page within a few minutes at most of when the task gets reported, you most likely aren't going to see it. Hopefully, now that the heat seems to be off the backend with the new longer running work, they can set the daemon to let the completed tasks hang around a bit more. ;-) HTH, Alinator |
Send message Joined: 3 Sep 07 Posts: 2 Credit: 439,099 RAC: 0 |
Thanks a lot. It does make sense. But I think, this is not good, because I don`t know, if the wu was validated and if I got credit and how much. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Thanks a lot. It does make sense. But I think, this is not good, because I don`t know, if the wu was validated and if I got credit and how much. Agreed, but the project team really kind of had their back to the wall over the last couple of weeks with the Database Server grinding to a halt due to the volume of service requests made on it. It had gotten to the point where the project was coming to virtual standstill every couple of days or so, and something had to be done. ;-) Until they get the daemon set to delay purging for more than ASAP, the only workaround I know of is to set BOINC to disable network access, and then report 'manually' when you are there to monitor the Host Summary. Be advised that this isn't quite as simple to do as it sounds, and is pretty much the same PITA as having the completed tasks go poof instantly if you like tracking your hosts yourself. :-) Alinator |
Send message Joined: 2 Jan 08 Posts: 122 Credit: 69,479,692 RAC: 1,456 |
Thanks a lot. It does make sense. But I think, this is not good, because I don`t know, if the wu was validated and if I got credit and how much. @Fran, it seems you get about 5 minutes, then results are purged from the database. So upload, then quickly check the results or you miss out. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Thanks a lot. It does make sense. But I think, this is not good, because I don`t know, if the wu was validated and if I got credit and how much. If that, I was just logging completed task data for my hosts and the completed ones got purged within 2 to 3 minutes. I agree though that 5 minutes is probably pretty close to the maximum time they hang around right at the moment. So I would guess the time depends on where they end up in the purge queue, and where the daemon happens to be in the list as it works through it. Just for reference, I was talking with Travis about this a few days ago and the problem for the project was that the BOINC Server software package only allows the admins to set the purge delay in terms of days (0 to whatever you want). However, with the old work this was causing a problem because the database table of completed results would get so big that the purge daemon would start burning up so much time all the other processes ground to a virtual standstill fairly quickly. I would think since the runtimes have increase at least a factor of 30 or so, they might be able to get away with the one day setting. In any event, Travis said he was going to look into modifying the code so he could have resolution in hours rather than days when he gets a chance, but I would imagine he has his hands full right at the moment getting the run parameters zeroed in for the new work. HTH, Alinator |
Send message Joined: 29 Aug 07 Posts: 20 Credit: 2,710,089 RAC: 0 |
I thought that "day" was a float, so you can put 0.1 for a little over 2 hours. BOINC WIKI BOINCing since 2002/12/8 |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Apparently not, since when I suggested that Travis said he already tried making the purge delay less than 1 day but it didn't seem to work. I did check the official BOINC documentation, and it doesn't say one way or the other. I agree though that it doesn't seem to make much sense to have this parameter cast as an integer, but I didn't go rooting through the source to verify it and it wouldn't be the first time that something 'weird' was done in the BOINC code. I suppose one could make the argument that the only reason for the delay is so users can take a look at what their hosts are doing if they want to. So a delay of less than 24 hours wouldn't be much help there and multiples of 1 day was sufficient if a project wanted to let them hang around longer, since most folks don't sit at the console 24/7 waiting for tasks to show up on Host Summary. ;-) Alinator |
©2024 Astroinformatics Group