LHC@home

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
This might be a good starting point to understand why it is not a good idea to work with reduced precision.

Well, 64 bit floats still give you rounding errors but they tend to be way out there past the decimal points. :)

Today I have been getting only Theory on my main cruncher. It has been now accepting work from all subprojects except sixtrack. Yesterday it had all subprojects selected and it got only sixtrack tasks. So no CMS for me although it has also been selected for a couple of days now.

The search function might be your friend since this has been explained a couple of times in this message board.

The server fills it's ready to send queue from a couple of upstream processes each representing one of the subprojects.
Now the server's shared memory holds a list of "results" in random order.
In addition large projects like LHC@home spread the load over a couple of servers which are contacted in random order (DNS based load balancing).

Your client generates a request to get x seconds of work and the server that answers your request will send you the n first "results" from it's shared memory list.
- n is calculated based on the sum of the estimated runtimes.
- server side quotas will be respected.
- results from deselected subprojects will be skipped^*).

Under certain circumstances this leads to a situation where one of the servers has no tasks (=result) from your active subprojects in it's queue and you will get a "no tasks available" message although the server status page show lots of available tasks.


*) This might lead to the situation that the next client who has this subproject checked will get the skipped "results".

We had an outage of some IT services at CERN yesterday, so task submission for some applications stopped for a while. Back to normal today. Hopefully SixTrack users will submit a new batch soon too.

Thanks for your contributions and happy crunching!

I've got 4 CMS tasks that have run for quite some time without failing, so I think they might have fixed everything :-)

That would be useful, if they ever get it really fixed. You never know.

I just downloaded a native ATLAS.
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=133600650

Note: my computer is currently processing 10 CMS tasks which are erroring due to the server problems. Is that causing me to get limited in downloading more tasks?

The maximum number of tasks is twice the number of the cores.

You could email everyone if there's something urgent - we all have the option to tick (or not) the thing that says it's ok for admins to email us. Then we'd see it quicker.

Are you aware that you can subscribe to MB threads or get them via RSS feed?
The way this works can be configured on the MB pages and on this page:
https://lhcathome.cern.ch/lhcathome/edit_forum_preferences_form.php
It's far more than simply allow an admin to send you a mail.

"My smaller three desktops produce a lot of errors when running virtual machine LHC (they're only 8GB RAM with old processors)" 4gb ram on 9 year old cpu still working fine for me with LHC.

Although couldn't the Boinc server have been told not to hand out any CMS?

It sometimes happens that the BOINC server doesn't immediately stop sending task envelopes, especially when the subtask shortage is not very long.
In this case Ivan sends out an NNT info.
This ensures a faster CMS restart when fresh work is available.

Ok, although chances are most people won't see that message for a day or so. I usually don't even notice them at all.

Yeah, sure, but I have to do my best. The problem is that when no jobs are available, then the BOINC task will return an error. Your BOINC manager will flag that as an error, and reduce the quota of tasks you can request per day, until this gets down to unity. The quota will only increase when you run a successful task. So if you don't set NNT then your machine gets reduced to one task request per day, until new jobs are available, allowing a task to complete, thus increasing the per-day quota. So, it takes several days to ramp up to full production again if you allow your machine to deplete its quota.

Although couldn't the Boinc server have been told not to hand out any CMS?

It sometimes happens that the BOINC server doesn't immediately stop sending task envelopes, especially when the subtask shortage is not very long.
In this case Ivan sends out an NNT info.
This ensures a faster CMS restart when fresh work is available.

Your client requests a task from the BOINC server. That task creates a CMS-VM on your machine and that VM requests CMS-jobs from another server and that's out of jobs or unreachable.