Message boards :
Theory Application :
Tasks run 4 days and finish with error
Message board moderation
Previous · 1 . . . 3 · 4 · 5 · 6 · 7 · 8 · Next
| Author | Message |
|---|---|
 Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7  
|
The following comment is a personal one, not a moderator's comment. More than what is is now. I get Theories with a 10 day deadline, which can end up with a 10 day limit. That requires 24/7 running with the task starting instantly I download it. Not going to happen. It was fine before - 4 day limit, 10 day deadline. And Theory only, or Theory + ATLAS, Atlas doesn't have long runtimes as far as I've seen. They start out saying they need 8 hours then usually finish in 4 hours. or LHC beside other projects (at what relative priority per project)? Doesn't matter. Once Boinc has a timer it knows will be close to the deadline, it engages panic mode so the Theory task will run all the time. Beside that individual runtimes per task can't be estimated beforehand. That's why I think they should be given a fairly short runtime limit of say 2 days to get 99.9% of them done, then those that don't complete on time can be handed out separately with a much larger runtime and deadline. And as I suggested with a tickbox so enthusiasts with computers running all the time can do those ones. NOGOOD wrote:Yes, tickbox on web preferences - superb idea. Why would the code need to be changed? In my LHC web preferences I can choose to do Sixtrack, Sixtrack test, CMS, Theory, Atlas. Why not have another one like the Sixtrack test, but for Theory? Call it Theory large or something. It would be treated as a seperate app, opt in for those who wanted to do it, and you could have different runtimes and deadlines for it. In addition: Well I don't know how these results are used. Do the scientists need every single result back or just most of them? What are they currently doing with ones that need a month to run? Are they run on LHC's own computers? Might be a good idea to also check the mcplots failure rate: Not sure what I'm looking at there. Are you saying that those of us who run a lot of Theories are failing 6% of them? I'd call that not very good. I thought you said 99.9% were ok? Sorry, don't want to disappoint you. We shall argue with you until you see the light ;-) 
|
|
Send message Joined: 18 Nov 17 Posts: 119 Credit: 51,774,188 RAC: 22,126  
|
Really, all of that to get a bit more than 99.9%? Oh... I'll repeat: if successful tasks running many-many days is not especially valuable for the Project, I give up. No reasons to continue this discussion. |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
Really, all of that to get a bit more than 99.9%? I don't see why the admins find this so difficult. Presumably they're not interested in results over x days. So they should set the limit at that, and the deadline suitably longer so we can actually get it done, then if it fails it fails. If they need every single one completed, then those longer ones need to be done in another way, perhaps on their own fast computers, or handed out again with different deadlines and time limits.
|
|
Send message Joined: 18 Nov 17 Posts: 119 Credit: 51,774,188 RAC: 22,126
|
Support this questions. Actually, my activity is the way to find out the same. |
 Send message Joined: 15 Jun 08 Posts: 2401 Credit: 225,179,573 RAC: 123,967 |
More than what is is now. Unspecific? Where can "more" be set? ... Boinc has a timer it knows will be close to the deadline ... No. That's exactly what BOINC does not know in case of Theory. Are you saying that those of us who run a lot of Theories are failing 6% of them? It's the mcplots perspective (per computer), not the BOINC perspective. 99.9 % return rate (mcplots total) within 2.32 d runtime, but not all of them succeed. |
|
Send message Joined: 15 Jun 08 Posts: 2401 Credit: 225,179,573 RAC: 123,967 |
Just change your view. Scientists define thousands of parameter sets that they want to be simulated. At that time they don't know how the tasks generated from that parameter sets behave. Most of the tasks deliver valuable results. A few don't and scientists check if the successful tasks answer their questions. If not they will investigate why and modify the parameters or applications and generate new parameter sets. |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
More than what is is now. The deadline is set at LHC. Yours is 10 days, Universe is 14, Rosetta is 3. ... Boinc has a timer it knows will be close to the deadline ... Of course it does. There's a limiter at which point the task gives up . This was 4 days and now is sometimes 10 days. After the task has taken more than the average time (or something else tells Boinc it's now a long task, not sure what makes it change over), the "time left" Boinc reports jumps to 4 or 10 days. Boinc knows the deadline too. If the time left will go past or close to the deadline, Boinc runs that task on high priority. Are you saying that those of us who run a lot of Theories are failing 6% of them? Sorry, I have no idea what that means.
|
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
Just change your view. It's not a view, it's a question we were both asking. It seems to be very difficult to find out what scientists actually do with these task results. Do they need them all back, do they only need most of them, does it matter if some fail? Do those that failed get run elsewhere on your own computers? Do they get broken down into smaller tasks?
|
|
Send message Joined: 18 Nov 17 Posts: 119 Credit: 51,774,188 RAC: 22,126
|
Just change your view. Exactly. If they do not need them all back, we should set runtime limit of mentioned 2.32 days, feel ourselves useful and do nothing more. |
|
Send message Joined: 16 Jun 06 Posts: 10 Credit: 3,245,056 RAC: 1
|
I have five Theory processes running, all with an expected duration of ten days. This is a difficult commitment because I find if I reboot then the virtual machines don't recover and I lose the jobs.  |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
I have five Theory processes running, all with an expected duration of ten days. This is a difficult commitment because I find if I reboot then the virtual machines don't recover and I lose the jobs. Strange. That computer has returned 25 good theories recently in just over an hour on average. It's odd that you now have 5 that are all taking that long. I usually just get the odd one that's a long runner. Mind you, you have 11 errors returned in about 13 minutes each. Do you know what happened to them? Was the computer being rebooted at the time, or computation paused for a game, or tasks swapped to run another project?
|
|
Send message Joined: 16 Jun 06 Posts: 10 Credit: 3,245,056 RAC: 1
|
Strange. That computer has returned 25 good theories recently in just over an hour on average. It's odd that you now have 5 that are all taking that long. I usually just get the odd one that's a long runner. I must admit I'm rather new to running LHC@Home on virtual machines, starting only a month ago. I have had errors since then, as my logs show. At first it was due to this being done on a new PC needing reboots, and whenever I rebooted I would find a mess of aborted machines on the VirtualBox which wouldn't clean themselves up, and I seem to remember problems with the following jobs until I went in and manually logged the machines out and removed them all. Even now, LHC@Home thinks I am running three ATLAS jobs I don't have, and when I look at the VM console for the first Theory job I get this:  I assume the rest are the same. Forgive my ignorance, but is there any point letting this apparently crashed process sit on my system, pretending to be using up a hyperthread? Or is the error non-fatal? The error looks like it is due to a network problem, in which case the job could complete successfully if re-run. |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
I must admit I'm rather new to running LHC@Home on virtual machines, starting only a month ago. I have had errors since then, as my logs show. At first it was due to this being done on a new PC needing reboots, and whenever I rebooted I would find a mess of aborted machines on the VirtualBox which wouldn't clean themselves up, and I seem to remember problems with the following jobs until I went in and manually logged the machines out and removed them all. All I can think of is to make sure you're running the latest Virtualbox and Extension Pack (Boinc doesn't always supply these, I get them straight from the Oracle site - launch Virtualbox from the start menu and you should get prompted to update, or it's in a menu somewhere). I've always used the latest version and never had a problem. Very occasionally a Theory won't continue after a reboot etc, but mostly they just continue like any other task. Those that won't, just say "computation error", and it starts another. I don't get them jammed and have to intervene. Even now, LHC@Home thinks I am running three ATLAS jobs I don't have, and when I look at the VM console for the first Theory job I get this: Not sure what that error means, looks like it can't download something from the CERN server. Hopefully an admin in here can explain.
|
 Magic Quantum Mechanic Send message Joined: 24 Oct 04 Posts: 1115 Credit: 49,647,963 RAC: 9,770 
|
[quote]NG You might want to update your VB version since I think you are still running a 2019 version and Oracle tends to do lots of updates to fix the usual problems. (VirtualBox 5.2.34 (released October 15 2019) Peter Hucker I have always used the latest version and never had any problems. (damn this thread is faster than the server) Yes Peter I knew you had been up to date and that was for NOGOOD and I figured he would see that I said that to NG and go from there. |
|
Send message Joined: 16 Jun 06 Posts: 10 Credit: 3,245,056 RAC: 1
|
NG You might want to update your VB version since I think you are still running a 2019 version and Oracle tends to do lots of updates to fix the usual problems. (VirtualBox 5.2.34 (released October 15 2019) The latest version of VirtualBox available is 6.1.8. Mine is 6.1.6, but to upgrade it I would have to end my LHC jobs.  I've even wondered if the recentness of my VirtualBox is a problem, since BOINC recommends the older version they distribute with the BOINC package. It is possible that my network was down at the moment my latest five jobs were issued, but not very likely. Plus it would be nice if the software would try again. So I take it I can abort these five jobs and save three days of imaginary crunching? |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
The latest version of VirtualBox available is 6.1.8. Mine is 6.1.6, but to upgrade it I would have to end my LHC jobs. I didn't have to end mine. I exited Boinc manager and ticked "stop tasks". Then I upgraded Virtual box. Then I restarted Boinc. The tasks continued where they left off. I've even wondered if the recentness of my VirtualBox is a problem, since BOINC recommends the older version they distribute with the BOINC package. No idea why they say that. With LHC anyway, the latest one always works fine. It is possible that my network was down at the moment my latest five jobs were issued, but not very likely. Plus it would be nice if the software would try again. So I take it I can abort these five jobs and save three days of imaginary crunching? Are they using your CPU time in the task manager? If not, abort them. If they are, you could wait and see if a couple are long runners that finish within the time frame, but it's not likely.
|
|
Magic Quantum Mechanic Send message Joined: 24 Oct 04 Posts: 1115 Credit: 49,647,963 RAC: 9,770
|
TRUE I have been running them for over 9 years now and to do the VB/Extension Pack update I just *suspend* my running tasks and do the VB update and reboot and restart the tasks. But make sure they are *suspended* by first checking your VB Manager (and as far as what running tasks are doing you can always check the task logs in the VB Manager) OH and I never go by "BOINC recommends the older version" since they don't update as often as Oracle VB....... they tend to update more than Windows 10 does  That is basically still there for new members. |
|
Send message Joined: 12 Aug 06 Posts: 418 Credit: 5,667,249 RAC: 7
|
TRUE I wasn't sure about doing that, especially since I have ticked "leave in memory while suspended", since that's meant to make them more likely to be able to continue if Boinc suspends them for playing a game, or to run another project. And anyway I wasn't sure if "suspend" actually closed Virtualbox. OH and I never go by "BOINC recommends the older version" since they don't update as often as Oracle VB....... I don't see any point in recommending an older version.
|
|
Send message Joined: 16 Jun 06 Posts: 10 Credit: 3,245,056 RAC: 1
|
Until you asked I hadn't noticed I could expand the BOINC tasks apart in Task Manager (Windows isn't my primary OS) and I see only Rosetta and WCG using my CPU:  So I will abort the LHC jobs. Thanks for all the help. |
|
Send message Joined: 16 Jun 06 Posts: 10 Credit: 3,245,056 RAC: 1
|
I'm getting very good at aborting defunct jobs on BOINC manager and deleting the corresponding machines (which don't clean up by themselves) on VirtualBox. I wonder if I am the only one being afflicted by ~80% of the jobs I receive stalling in an error? In this image I am referring to the second job, which claims to be running on BOINC manager but isn't actually working. It is wasting a thread, and will continue to waste a thread until I manually delete the job. Not only is this tedious to keep doing, it is wasting a good fraction of my computer's processing capacity on an ongoing basis because I usually have ten such defunct jobs at a time..  Both BOINC manager (version 7.26.7) and 64 bit VirtualBox (version 6.1.12) are up to date, running on Windows 10 Pro. Everything is stock. I don't know what to fix to get jobs to work, assuming everybody else's jobs are working. |
©2024 CERN