open Beta Test for new cmsearch VM application

[JeromeC]

All the xml editing and the fuss for nothing, after 1300 hours of computation :

Dim 9 fév 22:19:22 2014 | RNA World | Task cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-melanogaster-(fruit-fly)_AE014298.lin.EMBL_RF00028_Intron_gpI_1349111823_15120_4 is 50.93 days overdue; you may not get credit for it. Consider aborting it.
Dim 9 fév 22:19:23 2014 | RNA World | Restarting task cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-melanogaster-(fruit-fly)_AE014298.lin.EMBL_RF00028_Intron_gpI_1349111823_15120_4 using cmsearch3 version 106 (vbox64) in slot 12
Dim 9 fév 22:20:03 2014 | RNA World | Sending scheduler request: Requested by project.
Dim 9 fév 22:20:03 2014 | RNA World | Not requesting tasks: don't need
Dim 9 fév 22:20:06 2014 | RNA World | Scheduler request completed
Dim 9 fév 22:20:06 2014 | RNA World | Result cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-melanogaster-(fruit-fly)_AE014298.lin.EMBL_RF00028_Intron_gpI_1349111823_15120_4 is no longer usable
Dim 9 fév 22:20:22 2014 | RNA World | Computation for task cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-melanogaster-(fruit-fly)_AE014298.lin.EMBL_RF00028_Intron_gpI_1349111823_15120_4 finished
Dim 9 fév 22:21:07 2014 | RNA World | Sending scheduler request: To report completed tasks.
Dim 9 fév 22:21:07 2014 | RNA World | Reporting 1 completed tasks
Dim 9 fév 22:21:07 2014 | RNA World | Not requesting tasks: don't need

Only one conclusion after all this time and effort lost :

Dim 9 fév 22:35:34 2014 | RNA World | Resetting project
Dim 9 fév 22:35:34 2014 | RNA World | Detaching from project

Good bye.

[Michael H.W. Weber]

XML editing?

Michael.

[JeromeC]

No, you are right, I got confused with another project (lattice I think), no xml editing here, just loosing that WU after restarting boinc and me getting mad.

[Jacob Klein]

Maybe you can try another RNA World VM task. I know that Christian is working hard so that more and more bugs get fixed with each new application version that gets released, and one of those fixed bugs dealt with automatic deadline extensions which weren't working.

Up to you.

[ChristianB]

@JeromeC: In case you are still reading the forums. When did you update your BOINC Client the last time? What version was prior to this? It seems there is a nasty bug in the BOINC Client lately that marks certain tasks as client error on the server side. As I can see from our logfiles this happened to paparazzipeter (from the German thread) too. I will try to pinpoint the problem and report to the BOINC devs as soon as I'm a bit more healthy.

[JeromeC]

Yes yes I'm reading, don't worry I cooled down a bit (I'm from of France, Mediterranean influences)

I've been using 7.2.33 for some time, I did not upgrade it recently, however, to be completely honest, what happened was the following (and so it was partly "my fault" even though it was not) :

- my Mac wouldn't let me login anymore, it was "endlessly booting" and with a "working mouse cursor" and not getting to the user login page
- after several tries and fixes (this had happened to me in the past), I decided to restore my system and application partition from my daily system clone (so happy I have it !)
- note that my boinc data is not on the same system disk but on my data disk, where my profile is located (I used official boinc method to create an alias for boinc data and rerun Berkeley security script, I did that long ago and it's working fine)
- do to this restore I have to boot on my system clone and then restore all files from it to my normal system disk
- while doing this, ie being logued in into the system clone, with the SAME profile on the same data disk, BOINC did start (my boinc is setup as a service) and I realized too late that it decided to reinitialize all the projects !! RNA was reinitialized too, all was lost. When I saw it I stopped everything, too late
- after the restore I was then able to reboot my Mac on the normal disk (I was happy again), but Boinc refused to start (typical error on Mac OS X saying authorizations are wrong), so I reinstalled the same 7.2.33
- I also have a daily backup of my boinc data directory (done at midnight), so I decided to restore it (I don't put boinc data into the Time Machine hourly backup because it generates too long and too big backup all day long)
- at the beginning after boinc restarted, the RNA restarted normally in the state it was last night at midnight, I was very happy,
- ... and then what I have posted first happened : all of a sudden boinc decided the WU was overdue and then it terminated it...

Now you know all the long and sad story of my boinc life. Considering I never managed to finish a XXL old kind of WU, I was very happy when you decided to go for VM technology (I've been doing T4T beta testing since the early stages *) and I have been defending your approach in the AF forum (there are many crunchers "against" VB/VM boinc projects), so I was pretty much irritated when this happened.

I'll certainly give it another try... later !

(*) but I have a different problem too with T4T now, I'm quite unlucky with VB/VM projects lately !

[ChristianB]

Jerome: the server received an RPC from your host at 20:32:53 (CET) stating that the CPID changed and thus marked the in-progress result as error. Where does this fit in your list of actions? I'd like to pinoint why the CPID changed.

[JeromeC]

I really don't think it did : if you look at that page (URL via CPID) you can see my personal boinc stats that do correspond to my current activity, I have not changed this URL based on my CPID value...

In stdoutdae.txt, from the 09/02 when all this happened or even in the whole file, I cannot find the "CPID" chain at all... ?

[ChristianB]

Problem is that hosts also have a CPID. The host_cpid, which has changed in this case. I would guess there is no log output on the client about this. So basically something must have happened to your PC in the hours before 20:32 on Feb 9 that changed the host_cpid. I wonder if the restore from backup has anything to do with that.

[JeromeC]

For some strange reason I realized that my long time running CPDN WU was not lost in the process and continued to crunch after the problems, and I found out this morning that on the CPDN site I had my Mac duplicated with 2 different Host_CPID, I had to merge them by name (and it worked)... so yes, something did happen, too bad that RNA was not able to cope with it and do like CPDN, keep the bloody WU going on...

But maybe this duplication happened long ago (I didn't look at the last contact date on CPDN before doing the merge), because I see that on RNA I also have a duplicated host, but 14368 didn't have a contact with the project since October 2013, and this host is the one where all my RNA credit is affected... the 28472 where I have desperately trying to do at least one VB/BM WU is still empty :'-(

[Mouse King]

Please suggest. When my WU was creating a snapshot the load of RAM amounted up 99% (casually opened application that needed lot of RAM). After this I noticed that VM isn't creating new snapshots. I suspended and resumed the task. It was running until new snapshot was created (it created file .sav) and then suspended ("checkpoint maintenance failed, rescheduling task for a later time") In the "snapshots" folder contained two files .sav and two .vdi. I located that "Hard disk has more than one child hard disk" and found that drive in virtual drive manager with is causing error. I delete it. After that WU run again, deleted old snapshots and began work normally (several hours already). Howerer I worry that VM restore was done from incorrect saving and now computation may be wrong. Are my reservations reasonable? Or in case if task is runnig for long time it will be done correctly? (I have backup of all folders of Boinc and Virtual Box that was done 10 days ago. I can try to restore work from that moment, but there is no warranty that restore will be correct and I will not lose 240 hours)

[ChristianB]

The VM should be fine if it is using CPU time. It is possible that the computation started from the beginning. Can you send me the stderr.txt logfile of this task via PM? We recently had a similar case where the snapshot could not be performed due to an unexpected power outage. I would like to know in which phase your task failed.