LHC@home

If units failed due to timeout you put other users job in waste bin as they lost their already executed tasks due to your timeout I think. Admins, correct me if it's not like that.

No, users don't loose their Tasks. The WU will be sent out again to a different user, but the Project Needs it urgent back and they have to wait for this and wait and wait. Not good for the Project because it Needs the results in a short mannor

---

Supporting BOINC, a great concept !

32 tasks is the limit for my host. 32 tasks enduring ~80s (like this) would terminate in 320s. A great number reduces the probability of getting only flash-tasks. Is there a method to know how much time will a task (before running) get?

Another reason is also because I've often seen there are not many available tasks. Although I do a little "bunker", I'm finishing work before deadline (except that time).


P.S. the other machine (ID: 10356455) errors is cause of win8 failure after update, so no chance to cancel them. ;)

[/OT]

Setting a weeks worth of work is too long really, as you discovered when you got more 8hr WUs. I usually set a cache of 3-4 days.

The only way I know to see how long a WU is going to take is to look at the time 'remaining' in the tasks list. So no you can't 'cherry pick' the longer WUs.

And yea LHC often runs out of WUs, that's normal ;), which is why I have it running alongside other projects.

---

Team AnandTech - WCG, Uni@H, F@H, MW@H, Ast@H, LHC@H, R@H, CPDN, E@H.
Main rig - Ryzen 3600, MSI B450 Gm Pro C AC, 32GB DDR4 3200, RTX 3060 Ti 8GB, Win10 64bit
2nd rig - i7 4930k @4.1 GHz, 16 GB DDR3 1866, HD 7870XT 3GB(DS), Win7 64

32 tasks is the limit for my host. 32 tasks enduring ~80s (like this) would terminate in 320s. A great number reduces the probability of getting only flash-tasks. Is there a method to know how much time will a task (before running) get?

I am afraid not; the point of these studies is to find out whether the particles
will circulate for a long time or not.

Another reason is also because I've often seen there are not many available tasks. Although I do a little "bunker", I'm finishing work before deadline (except that time).


P.S. the other machine (ID: 10356455) errors is cause of win8 failure after update, so no chance to cancel them. ;)

[/OT]

Don't worry too much, it is just that as already discussed, cancelling WUs slows down the study because of rerun tasks going to the end of the queue.
Eric.

---

new host generates inconclusives, mostly 2-10 seconds
http://lhcathomeclassic.cern.ch/sixtrack/results.php?hostid=9934863

Grubix and this is yours
http://lhcathomeclassic.cern.ch/sixtrack/results.php?hostid=9874961&offset=0&show_names=0&state=3&appid=
lets see what could we do about it

14 errors for me on this host apparently caused by CMS-dev. Sixtrack wu fails with LHC@home 1.0 | Aborting task.....exceeded disk limit: 6860.42MB > 572.20MB before it gets a chance to start.
CMS appears to run fine and I'm not seeing any debris left behind after it finishes.

Hi Costa, thanks for the hint. I have also seen it last night and I was very surprised. Yesterday I could not do anything, because the computer is not at my home. This morning I have turned the computer off for a few minutes. The error has remained.

The invalid tasks have almost not a "pni" nor a "sse". The tasks with "pni" or "sse" are valid.

Eric, if the host is interesting for your diagnostics, feel free to give me appropriate instructions. But I have only Weekdays access to the host.

Bye, Grubix.

check that you have enough space
check there are no other cpu-consuming tasks
after Eric replied to you you might also reset project, reinstall BOINC, etc.

Other CPU intensive tasks shouldn't cause any errors.

---

Team AnandTech - WCG, Uni@H, F@H, MW@H, Ast@H, LHC@H, R@H, CPDN, E@H.
Main rig - Ryzen 3600, MSI B450 Gm Pro C AC, 32GB DDR4 3200, RTX 3060 Ti 8GB, Win10 64bit
2nd rig - i7 4930k @4.1 GHz, 16 GB DDR3 1866, HD 7870XT 3GB(DS), Win7 64

Hi Ray; it seems more than a coincidence that at least one, maybe
two other clients, have reported the same error. Seems to be
cross talk with CMS or CMS dev............. Eric.

---

half inconclusives, quarter invalids, only 10% valid
http://lhcathomeclassic.cern.ch/sixtrack/results.php?hostid=10137504

I have noticed that when CMS finishes, it doesn't quite do a full cleanup and leaves a disk image .vdi in the slot. I guess that Sixtrack tries to use that slot, thinking it is empty but finds the .vdi which pushes it over the permitted size, causing the error.
I have reset LHC 1.0 just in case anything else may have become corrupted but I'll need to wait for the next batch of work to see if that fixes it. Until a fix can be found I'll only let CMS and sixtrack run when the other isn't and will delete the relevant slot to clear the debris. Where I did this on one machine this morning after a CMS wu finished, Sixtrack is running fine again.
For now, the two projects don't seem to play well together so I will keep them separated.

Thanks Ray; I have forwarded your message to admins. Eric.

---

See Message 27392 from Ray and my reply. Eric.

---

Thanks Magic; somehow missed the significance of your message.
I had rather a busy time when it arrived. Ray confirms. Eric.

---

Thanks Magic; somehow missed the significance of your message.
I had rather a busy time when it arrived. Ray confirms. Eric.

---

Thanks Magic; somehow missed the significance of your message.
I had rather a busy time when it arrived. Ray confirms. Eric.

---

Thanks Magic; somehow missed the significance of your message.
I had rather a busy time when it arrived. Ray confirms. Eric.

Any time Eric,

I did wonder if anyone would catch that and just now remembered to check back here.

As far as those .avi's hanging around in the VB that also happens often with Atlas tasks but since I am used to that I clean it up every day since I run Atlas/VB and vLHC/VB 24/7

I did run some CMS and the first 3 tasks worked but started to mess around with all my other tasks (except the vLHC for some reason)

Then with a new wrapper the next 2 CMS tasks failed when I started them with my other tasks running so I decided to stop testing CMS for now but it does appear that CMS will run if you aren't running other tasks like I do.

When I stopped running CMS I was still getting other Atlas tasks and even GPU's to crash and what I ended up doing to fix that was a complete remove of all files connected to CMS on this pc and after that it all went back to normal and in fact I added some LHC tasks (since this is an 8-core) and ran those at the same time and it was all back to normal.

(I guess you have to email me to get me to stay up to date sometimes )

---

Volunteer Mad Scientist For Life

Thanks AGAIN, and especially for the additional info.
I was just too lazy/busy to mail you personally... :-)
Will do so in future. Eric.

---

Thanks for a hint. Wiill be trying this in a few days as now overloaded with work. Strange, CPU Bios setting are the same. but will try. Machine now is all 64 bit including apps. Will try compat settings. Hope it Works and will get back to you with results.

---

William C Wilson
São Paulo Brazil