LHC@home

Only BOINC wide teams are accepted.

Is there a how to section on adding virtual box on Linux pc's for newbie's? I am running Ubuntu 14.04 and in the Synaptic installer there is no virtual box for Boinc listed. It comes with Boinc on some of the Windows installers.

Download VirtualBox directly from the VirtualBox homepage.

Here you find the main packages for linux hosts:
https://www.virtualbox.org/wiki/Linux_Downloads

Be sure you download the package that fits to your OS and computer architecture (32bit/64bit).

You also need the Extension Pack:
https://www.virtualbox.org/wiki/Downloads


If you are new to the combination linux + BOINC + VirtualBox + CERN projects I recommend that you start with the subproject "Theory Simulation" and run only one WU at the same time. You may uncheck other subprojects on the CERN website.

Thanks.

Jim

As mentioned already on this thread: Virtual box is NOT needed if you only wish to run the default application, Sixtrack.

If you also wish to run other applications and opt in for these in the BOINC preferences, you will need VirtualBox.

We have tried to get rid of the message from the server, but so far without success. Investigations are continuing with the BOINC developers.

Even if you do not allow other applications than Sixtrack in your BOINC preferences, the BOINC scheduler issues the message "Virtual Box is not installed" from time to time.

If you are happy to crunch Sixtrack and classic BOINC only, you may safely ignore this message.

Thanks for your understanding and happy crunching on LHC@home!

The simplest of questions - there are some Sixtrack WUs currently available but they are not downloading - applies to 3/4 BOINC applications. Have I done something wrong settings-wise? Can anyone help, please? Rogerp

Well, first SixTrack is a Fortran application. There are medium/long term plans
to use C/C++ but for now we are Fortran. Nonetheless some colleagues have
created a GPU version which shows some encouraging results. We have been stuck
now for a couple of years trying to build Windows executables. The Intel ifort compiler
for Windows does not provide correct floating-point arithmetic. We are trying gfortran
which would seem to be appropriate for a volunteer system like SixTrack/BOINC.
The numeric results are just fine, but we are having great difficulty building the
BOINC api (Fortran) static libs. We used to do this on cygwin, and we are trying
MinGW but no luck so far. More news on all this when I can report some progress.
I agree it is a shame we can't use GPUs right now, but we must first solve the really
basic problems with Windows executables. (I also have a MacOS executable ready
to go.) We are also looking at ARM. We also have to adapt to some major changes
to the CERN infrastructure. I know, excuses, excuses but we are largley volunteers
as well. Thanks for your feedback. Eric.

That's Checkmate for Phil then, Mikey?

New Work?

When, everything will work?

If I had as many computers as you Mikey I would have got 1000 WU's

(not that we have that many here very often)

the server says there were 83 WU's and I have an idle PC, yet still no work.

I examined a couple of work units. The downloaded files (zipped) are about 349 KB, while the uploaded result files (not compressed) are about 44 KB. Simple zipping of the results reduces the size by almost 75%.

Zipping and unzipping take so little computing time that I think compressing the results for transfer would be justified.

You might make that suggestion to the Boinc discussion group and they could perhaps include in the next version so ALL projects could use it.

Is this what you mean?.

I NEVER win these threads, so I wont post.

I examined a couple of work units. The downloaded files (zipped) are about 349 KB, while the uploaded result files (not compressed) are about 44 KB. Simple zipping of the results reduces the size by almost 75%.

Zipping and unzipping take so little computing time that I think compressing the results for transfer would be justified.

Well the 50th post came and went and a few more days have come and gone, so it must be time for me to be

<<<WINNING>>>

Ah, yes. Good ole' Dagorath. He once called me a fool, so I now have him completely blocked.

initial replication 3

No, don't worry about that. It's a well-known terminological inexactitude (mistake) in the BOINC server code.

Two tasks were sent out on 30 Oct 2012, an initial replication of two.

When they failed to agree, a third instance was created and sent out on 3 Nov 2012, to make a current replication of 3.

BOINC updates the number, but it doesn't update the word.

Sort of...YES 2 were initially sent out, but the 1st unit errored out the same day and the 3rd unit was sent out 2 days AFTER the 2nd unit was returned to the Project. 2 units were sent out 30 Oct, 1st unit returned the same day, 1 unit returned 1 Nov. The 3rd unit was sent out 3 Nov and returned 4 Nov. This could be due to VERY slow Server responses or a Server 'glitch' that ended up causing the current situation. The replacement unit SHOULD have been sent out immediately after the 'inconclusive' unit was returned, NOT 3 days later.

COULD this be a part of the problems of not sending the bad units to another user? Is the Server NOT recognizing the invalid or inconclusive units properly and therefore NOT resending the units?

Sorry, not true (if we're looking at the same workunit). Both of the first two tasks returned 'success' status, so no problem could possibly be detected until the second report was received at 1 Nov 2012 | 6:44:33 UTC, and the validator was able to detect the mismatch.

After that, the third - tie-breaker - task 9891207 was created at 1 Nov 2012 | 6:44:48 UTC. 15 seconds for task creation isn't excessive: the delay between creation and distribution is a queue function, as we've discussed elsewhere.

It's just a very, very busy project. They maintain a 'high water mark' of around 300,000 tasks ready to send, and turn over about 60,000 tasks per hour - so the end of the queue is never more than five or six hours away.

That sounds simple enough that it could be made to work here too. The trick is having the code to do it and setting the high/low water marks appropriately. For example, if Eric has a batch of 179,249 tasks, just to pick a nice not-round number, then he ought not to dump all 179,249 into the queue at once. There needs to be a high water mark of say 2,000 and a low water mark of say 1,000. The batch starts with the feeder, splitter, or whatever its name is, dumping 2,000 tasks into the queue. When there are only 1,000 tasks left in the queue the feeder/splitter/whatever dumps all the resends into the queue and follows those with enough tasks to fill the queue to the high water mark. Eventually all 179,249 tasks have been put into the queue with all the resends sprinkled in as well at the beginning of each top-up. There should be only a short tail which won't matter anyway because even if Eric creates another big batch the tasks in the tail will go into the queue first before tasks from the new batch.

Now the milllion dollar question is.... Is there server code available that does that? Is that code already installed? If so what are the names of the options/config items that make it happen?

The keywords to look for are 'Work generator' (as used at Einstein) or 'workunit generator'. 'Splitter' is a specialised version of a WU generator used at SETI: 'feeder' is a different animal altogether, and doesn't belong in this list.