LHC@home

Thats the reason why I left crunching this project.

Too many "errors" in several ways to be considered "serious".

Vbox is simply "not working" for a normal user (can't stops & resume jobs with no errors) and we all have seen all kind of faulty tasks,

It's ok to see the own frontieres to help this projects.
It is not the mainstream of Volunteers with more than Years to be here and helping to reduce the Errors.

Vbox is simply "not working" for a normal user (can't stops & resume jobs with no errors)

I used to think that too. I was wrong. They stop and resume just fine now after fixing my VBox installation. In fact if you take the time to look through other users' result reports you'll see (in the stderr text for successful tasks) that their tasks pause/resume several times.

and we all have seen all kind of faulty tasks,

Not really. Just 1 kind... Sherpa... and only a small percentage of those fail.

Not true. I have had problems while using windows. Vbox even shows infame message "can't handle job"...
More:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5015

See forums, plenty of user complaining :)

---

Not true. I have had problems while using windows. Vbox even shows infame message "can't handle job"...
More:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5015

See forums, plenty of user complaining :)

Meh, just a few complainers who, like you, aren't "serious" about crunching LHC, just serious about complaining.
Again, take a look at the result reports from the many hundreds of users who are returning tasks that were paused/resumed, Linux as well as Windows. You'll see that their tasks validate. Your claim that pause/resume doesn't work is complete BS. If pause/resume doesn't work on your hosts it's because your hosts are misconfigured or you don't follow the necessary procedure.
If you ever decide to get "serious" about it you'll be able to crunch LHC too. Until then you should stick to the easy projects.

You could try updating to the latest VBox version (it's up to 6.0.8, now) which might resolve the issue you were having. Or limiting the number of cores used in your Preferences so as not to overstretch your machine, which hasn't had any tasks this year. I run only single-core tasks (when I'm not doing work for the -dev site) and have had no problem with suspending and resuming tasks.

Yes, there are some faulty tasks, and they're very annoying, but that's not a VBox issue and most run just fine.

I don't have any problem with a VB *pause/resume* and only get these once in a while out of the thousands I have done.
(but then I do make sure it is suspended before I try to reboot)

Still use versions 5.2.16 to 5.2.28 with no problems

Please increase the rsc_disk_bound for the (vbox) Theory-tasks.

LHC@home 24 Dec 19:09:32 Aborting task Theory_2279-804599-198_0: exceeded disk limit: 1938.75MB > 1907.35MB

https://lhcathome.cern.ch/lhcathome/result.php?resultid=256757335

now we are back to this nonsense:
196 (0x000000C4) EXIT_DISK_LIMIT_EXCEEDED

after 1 day 11 hours 38 min. 57 sec. crunching time. What a waste :-(

https://lhcathome.cern.ch/lhcathome/result.php?resultid=256479088

how come?

The same, big number of theory app instances failing
https://lhcathome.cern.ch/lhcathome/result.php?resultid=256633820
Annoying ....

could anyone back there please increase the disk limit, so that failures like the ones described above do not re-occur - thanks a lot!

I have been testing Theory Simulation v5.18 (vbox64_theory) windows_x86_64 for a while now without this particular problem/

The only problem I have is the typical VB needing high-speed internet just to start up the tasks in the first 3 minutes and after that it doesn't matter.

So maybe it is time to move this version over here and see how you all do with these.

Is it possible, only in VM-Theory and not in -native?
ATM 450 -native for me without this Error!

Windows Theory is from October in -dev.
Windows Theory is from November in Production.

We have to wait up to next week.

Is it possible, only in VM-Theory and not in -native?

The rsc_disk_bound of 2,000,000,000 bytes (1907.35 MB) for Theory-VBox and native is the same. Both versions are now seen as one application,
but for the VBox-version 2000000000 bytes disk space is tightly sized specially when one has to save the VM-state to disk while suspending a task.

I just got home so I decided to look through that other version 5.18 I have been running and I did see a few of these waste of time tasks that looked like they would be Valid all the times I checked them but ended up like this.

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2850450

But many,many of Valids over 30 hours of running time and almost the same in CPU time.

So I guess this version does the same if they try running that long.

BUT then this one is Valid https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2849822 over 76 hours. ( the credits are a different story as you can see)

I just got home so I decided to look through that other version 5.18 I have been running and I did see a few of these waste of time tasks that looked like they would be Valid all the times I checked them but ended up like this.

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2850450

Although it was on the dev-server, the tasks are coming from the same pool. Thanks for pointing to the result. Peak disk usage 3.48 GB without any snapshot written to disk. It must have been a lot of sherpa logging to the virtual disk to grow that big.
At least we know now that the rsc_disk_bound should at least be doubled to 4000000000 bytes, but maybe even that's not enough. I personally tend to 8000000000.

EDIT: Magic, I fetched the retry for that task:https://lhcathomedev.cern.ch/lhcathome-dev/workunit.php?wuid=1963768

===> [runRivet] Tue Dec 31 11:03:14 UTC 2019 [boinc ee zhad 43.6 - - sherpa 2.2.5 default 2000 197]

We'll see how it goes. I've already seen a lot of

Poincare::Poincare(): Inaccurate rotation {
a = (0.536749,-0.680524,-0.498785)
b = (0,0,1)
a' = (0.46357,0.714657,0.523803) -> rel. dev. (inf,inf,-0.476197)
m_ct = -0.498785
m_st = -0.866725
m_n = (0,-4.85017e-07,6.61739e-07)
}

during full optimization phase.
Meanwhile:
integration time: ( 28m 28s elapsed / 174d 11h 27m 56s left ) [11:54:39]

@Magic: Another one of yours: ===> [runRivet] Wed Dec 25 10:07:54 UTC 2019 [boinc ee zhad 200 - - sherpa 2.2.4 default 3000 198]

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2851401 -- Peak disk usage 2.98 GB

And another one: ===> [runRivet] Wed Dec 25 12:20:40 UTC 2019 [boinc ee zhad 29 - - sherpa 2.2.4 default 2000 198]

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2851452 -- Peak disk usage 2.92 GB

LHC@home 05 Jan 08:40:38 Aborting task Theory_2279-794231-202_0: exceeded disk limit: 1945.56MB > 1907.35MB

https://lhcathome.cern.ch/lhcathome/result.php?resultid=257666299

LHC@home 10 Jan 16:24:35 Aborting task Theory_2363-897726-14_0: exceeded disk limit: 1964.13MB > 1907.35MB

https://lhcathome.cern.ch/lhcathome/result.php?resultid=258964496

LHC@home 10 Jan 16:44:38 Aborting task Theory_2363-916251-14_0: exceeded disk limit: 2101.13MB > 1907.35MB

https://lhcathome.cern.ch/lhcathome/result.php?resultid=258964499

it looks like the Theory tasks have a bad run these days :-(