LHC@home

I've started running LHC@home on my new HP 635 laptop with AMD E-450 CPU and SLES 11 Linux from SuSE. Let's see what it does. The APU unit has graphic capabilities that are not exploited on this project bur maybe Einstein@home can use them.
Tullio
It does not use much CPU: about 50%. How come?
Sorry, mistake, That was LineVeto in Einstein@home.

Thanks for the feedback, Eric. I'm amazed that only 50 out of 25,000 hosts seem to have problems. Presumably these rejected results don't validate, or are there additional checks? Good work, all.

John.

Eric,

If batches are taking too long to run then you might have someone take a look at any limitations that have been set for the maximum number of Tasks a client can run in any one day. At one time, there were so many number crunching farms out there that as soon as a batch of tasks appeared on the server they got sucked up by these farms and people who wanted to participate but were running only one or two systems never got anything. I have notice in the past few days that if I try to "pump" the Project I will eventually get a message that I have gotten the maximum number of Tasks for the day. I'm not saying open it up to no limit but if one exists then it may need to be tweaked a bit to get the batches done across more BOINC clients.

I don't think it is a good idea to totally eliminate validation. SETI use to do three and dropped it to two which seems to be the best approach. That way if the validation fails the Task is fed to a different BOINC client for re-crunching.

BTW, I wish I could figure out how to make things work better when running T4T@Home along with other Projects. Since T4T runs outside of BOINC it doesn't play well with others. I'm also seeing a limit in the number of cores that I can use. Don't know why but it seems to have happened with the most recent update to BOINC (7.0.28). Any ideas... anybody?

Tom

Well I am doing my best,but we have some limitations on the
user side at CERN. Also we have to introduce some new elements
(physics) in he next few days, generate an sse4 executable, fix
the MAC executable etc etc.

However, since "you" are delivering the equivalent CPU capacity
of the entire CERN computing centre, but really "only" 50%, since
we run every task twice, I shall make a further effort.
As suggested here on the Message Boards I am submitting work in batches.
I shall try increasing the number of batches.

Incidentally, Igor has just reported some interesting numbers which I
hope he will pass on. Basically, if I remember well, we are rejecting results from
something like 50 hosts out of 25,000 (he will correct), which means I am rather
confident about numeric portability. I am also planning to send a test to these only 50
volunteers. In fact, Igor had the idea of including a test of a few turns in each
Work Unit. If this worked I could then run each case only once, with
perhaps a few random duplicates, in order to double the capacity! :-)
Well it is perhaps a dream. This would be easier than programming GPUs
as SixTrack is Fortran.

However, the main thing at the moment is to document, maintain the quality
of service to both users and volunteers, and get on with the studies of the
various LHC upgrade options. Eric.

Tom, I am running T4T alongside 6 BOINC projects on my SUN WS and am now trying it on my new HP laptop with Einstein and LHC, all on Linux.
tullio

Tom; food for thought here. I'll make sure we discuss these issues
at the next occasion we can and get back to you. Eric.

---

Tom, I am running T4T alongside 6 BOINC projects on my SUN WS and am now trying it on my new HP laptop with Einstein and LHC, all on Linux.
tullio

Tullio,

What setups are you running on the various Projects and on BOINC Manager?

I'm on WIndows7 (x64), Intel i7-2600, 16GB RAM.

Thanks.

Cheers,
Tom

Well is that really so surprising. I would hope most systems
would work correctly! I rely on validation; bit for bit identical
results from two work units after some number of Gigaflops!).
I also rerun some cases and cross check and finally we once found an
outlier point in the physics that was clearly wrong, but that was before
the validation using our old in house CPSS. I even found a failing
machine in the CERN Computer Centre.
I have more work to do here as I cannot prove that I have solved
all the numeric issues, but I think I have :-) Hope to publish sson and I
hope the paper will be of some interest, funnily enough to Computer
Games programmers at least. Eric.

---

Thanks for adding 60k+ tasks ... I hope it will be enough to feed us for the week end ...

Doing my best :-) I have another study of about the same size
lined up. It is rather exciting actually as this a serious look at
the effect of beam-beam in the planned LHC upgrade and is
also comparing the two numerical methods of computing the
error function of a complex number.

Some may be a bit short as we are searching for the limit of the
region of beam stability. Eric.

---

Thanks Eric.

I do not remember seeing more that 84k tasks ready to send. :-)

---

Warped

If batches are taking too long to run then you might have someone take a look at any limitations that have been set for the maximum number of Tasks a client can run in any one day.

Is there such a limit? I don't think there is but I might be wrong. There is certainly a limit on tasks in progress (currently 4 per CPU core) but as soon as a finished task is returned, it seems to be able to be replaced without limit during the day as long as there are tasks 'ready to send' on the server. I haven't noticed any host being told that it has reached a 'daily quota'.

At one time, there were so many number crunching farms out there that as soon as a batch of tasks appeared on the server they got sucked up by these farms and people who wanted to participate but were running only one or two systems never got anything.

I think this is a misunderstanding of what happened in those days. At the time that 'farm bashing' started happening, batches of work were small and the gaps between batches were weeks and months. Nobody got much work to do. The way BOINC is designed, if requests for work are unsuccessful, the gap between requests will lengthen to the point that the client may not initiate a work request for as long as 24 hours. If a small batch of work suddenly appears, the lucky hosts will be those that just happen to ask for work at the right time. It has nothing to do with whether any particular host is part of a farm or not.

I am sure that those individuals (whether owing a single host or a farm) who wanted work desperately enough, could arrange for any particular host to bypass the BOINC backoff and so have a much higher chance of requesting work at the fortuitous moment when new tasks first appeared. I suspect enough people were doing this to deplete the batch so quickly that hosts in extended backoff didn't stand a chance.

I have notice in the past few days that if I try to "pump" the Project I will eventually get a message that I have gotten the maximum number of Tasks for the day.

The message actually says

This computer has reached a limit on tasks in progress.

which is fine since hosts are being prevented from caching such large numbers of tasks that others would be prevented from getting their share.

---

Cheers,
Gary.

Tom, I am running T4T alongside 6 BOINC projects on my SUN WS and am now trying it on my new HP laptop with Einstein and LHC, all on Linux.
tullio

Tullio,

What setups are you running on the various Projects and on BOINC Manager?

I'm on WIndows7 (x64), Intel i7-2600, 16GB RAM.

Thanks.

Cheers,
Tom

Tullio,

Disregard. I managed to fumble my way into getting a lot more work. :)

Cheers,
Tom

Wow, one of my 3.75GHz AMD boxes finished one that took 24 hours... and the wingman is a 1.6GHz Pentium-M that will probably take 3 times longer...

Does this mean the equations are turning out more and more relevant data???

:)

http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=2493244