LHC@home

The title says all? What performance do you have? My linux is currently broken, but if you have more performance on Linux like on the CPND client, I'll probably reinstall it. So tell me your experience!

> The title says all? What performance do you have? My linux is currently
> broken, but if you have more performance on Linux like on the CPND client,
> I'll probably reinstall it. So tell me your experience!
>
>

Yes I currently have two boxes on Linux with LHC. They are running at about the same speed as Windows but you only get half the credit for the same amount of time crunching. They did said they would try to fix it.

> The title says all? What performance do you have? My linux is currently
> broken, but if you have more performance on Linux like on the CPND client,
> I'll probably reinstall it. So tell me your experience!

Works like a charm over here. WU time is about 40 minutes (Athlon XP 1800, Gentoo Linux, Kernel 2.6.6). Claimed credit seems to be a bit low (3,5 per WU) in comparison to an Athlon XP 2600 (30 minutes per WU, average 7,5 credits, W2K SP4).

Had some problems with existing S@H WUs on startup (ran into errors, trashed two - not yet startet - WUs) but everything seems to be ok now.

WU times are as expected (even a few minutes shorter), Linux version of sixtrack runs well, everything's ok so far.

Just give it a try, it's worth it IMHO

scsimodo

> Yes I currently have two boxes on Linux with LHC. They are running at about
> the same speed as Windows but you only get half the credit for the same amount
> of time crunching. They did said they would try to fix it.

My observations are the same.
Celeron 2000 MHz did it in nearly one hour with 3.5 credits.

:puts on linux zealot hat:

As you can see 'here' http://lhcathome.cern.ch/workunit.php?wuid=118358 the linux machine/client returned a result FIRST!
And is therefore superior!

:takes off linux zealot hat:

Life is good.

______________________________________________________________
Did your tech wear a static strap? No? Well, there ya go! :p

I have had my linux box attached for a while and was surprised to see it suddenly crunching sixtrack today. But I have run into a slight problem it seems. I just noticed that both sixtrack and seti@home are running at the same time on a single CPU machine! This wasn't happening earlier. Upon further inspection, logs showed something else:

2004-09-28 03:17:06 [SETI@home] Pausing result 06my04aa.15945.20145.711070.141_0 (left in memory)
2004-09-28 03:17:06 [LHC@home] Starting result v64lhc1000pro9s6_8560.03_1_sixvf_92575_1 using sixtrack version 4.46
2004-09-28 03:17:36 [LHC@home] Result v64lhc1000pro9s6_8560.03_1_sixvf_92575_1 exited with zero status but no 'finished' file
2004-09-28 03:17:36 [LHC@home] If this happens repeatedly you may need to reset the project.
2004-09-28 03:17:37 [LHC@home] Restarting result v64lhc1000pro9s6_8560.03_1_sixvf_92575_1 using sixtrack version 4.46


Not sure if this is a BOINC problem or a project problem. It could be that either seti@home or sixtrack just ignored BOINC's "pause" request or it is possible that BOINC got confused and told both of them to run. Anyone else seen anything like this yet?

EDIT: I just restarted BOINC and it is only running sixtrack now. Will continue to monitor.


--------------------------------------
A member of The Knights Who Say Ni!
My BOINC stats site

>
> Yes I currently have two boxes on Linux with LHC. They are running at about
> the same speed as Windows but you only get half the credit for the same amount
> of time crunching. They did said they would try to fix it.

This is now stated in Known Bugs. But as it reads there, that is a BOINC client problem and we can't do much about it.


Markku Degerholm
LHC@home Admin

Hm, are there more details towards what Linux Kernel Versions are affected ?
(e.g. what is the "minimum required" Version, based on knowledge about the failures so far? )

Unfortunately all I have running are 2.4.19 to 2.4.22 Kernels, and one of them is a Dual CPU System (talk about possibly being out of luck) :p
I'll just have one machine take a shot at it first, and then work my way around my Linux boxes.

Note :
I think I've read that the other Projects operating Linux Clients did implement something like a corrective Factor concerning Claimed Credits as a 'quick workaround' for the known, Linux vs. Win32 Benchmark related issue. (not sure though)

--- edit ---

Okidok, attached 5 Linux Hosts including the Dual CPU Machine.
All seems to have worked well, HOWEVER...

Performance seems to be, ehm, "less than stellar" ?!...

An Athlon64 3000+ is predicted to take some 7 hours.
Dual AthlonMP 2000+ predicts ~9 hours (1 CPU).
AthlonXP 2500+ also predicts ~9 hours...
AthlonXP 2400+ predicts ~7 hours...

Since all those are more than 10 Minutes into their respective Work, the figures appear to be for real (no calculation error).
(the 5 Boxes are running 4 different Distributions/Kernels, so I'd say the Problem is not my machinery, which works with normal performance in other Projects)

Under Win32, my Athlon64 3200+ does them in ~25 Minutes.

As a rough estimate, I'd say the Performance observed for now is about at 10% of where it should be.
It almost looks like they might be getting the "old" WorkUnits doing 1000000 Cycles vs. the new 100000 ones ?!)

-=-=-=-=-=-=-=-=-=-=-=-=-=

more stabilized Figures after exactly 25 Minutes into their Work :
(some variation is natural, but the general runtime dimensions are obvious)

CPU | Kernel | CPU Time | Remaining
-----------------------------------
Athlon64 3000+ | Linux 2.4.20-20.9 | 00:25:00 | 06:27:43
AthlonXP 2500+ | Linux 2.4.22-1.2129.nptl | 00:25:00 | 07:26:56
AthlonXP 2400+ | Linux 2.4.20-20.9 | 00:25:00 | 06:55:30
AthlonMP 2000+ | Linux 2.4.21-0.13mdksmp | 00:25:00 | 08:26:08

The first Units completed by the 2100+ and 2500+ were quick however, 30min and 10min respectively (I deem those just were "quickies")
The 2100+ has timesliced to other work, so I can't get the data of it right now.

--- edit 2 ---

After ~50 Minutes into work (figures have proven stable within known, normal limits), it really looks like they are working the full 1000000 Cycles, otherwise I have no explanation for it (?)

--- edit 3 ---

Okidok, 1000000 Cycles (long WU's) those are.
I've cross-checked the most recently downloaded WorkUnits for my other Windows Clients, and those show the same expected (Factor 10x increased) runtimes.

So all in all, looks like the Linux Clients are working perfectly fine on the 2.4.19 to 2.4.22 Kernels, including the Dual CPU machine :o)

(no Idea about what Credits those will claim yet of course, I'll recheck tomorrow)
___________________________________________
<p>Scientific Network : 36200 MHz «» 8204 MB «» 815.0 GB </p>

Okidok, got my very first LHC Linux result validated :

http://lhcathome.cern.ch/workunit.php?wuid=83320

On the Credits issue, that's 3.19 Linux claimed vs. 6.65 Windows claimed.
53% less, that matches up with the lower Linux Benchmark scores.

Seems a "correction Factor" is needed for granting Linux Results, otherwise we'll hog down our Windows companion's Granted Credits.

Not sure, but I could swear I've read another Project (SETI ?) actually does that.

--- edit ---

A few other Linux Results got validated by now, and all are claiming ~50% lower Credits, indeed dragging down fellow Windows Cruncher's Credits consequently :/
___________________________________________
<p>Scientific Network : 36200 MHz «» 8204 MB «» 815.0 GB </p>

Compiling the linux client yourself improves the performance a lot.
The benchmarks improve by about 50% and consequently so does the claimed credit.
The binary distribution has been compiled with little or no optimisations hence the poor performance.
Compile it yourself and it improves a lot, although your credit will be dragged down by those who are running the unoptimised binary.

Athlon XP 2400

Version 4.09 linux client
CPU benchmarks
2004-09-29 03:49:55 [---] Benchmark results:
2004-09-29 03:49:55 [---] Number of CPUs: 1
2004-09-29 03:49:55 [---] 1042 double precision MIPS (Whetstone) per CPU
2004-09-29 03:49:55 [---] 2519 integer MIPS (Dhrystone) per CPU
2004-09-29 03:49:55 [---] Finished CPU benchmarks

Client compiled from source code
CPU benchmarks
2004-09-29 03:55:19 [---] Benchmark results:
2004-09-29 03:55:19 [---] Number of CPUs: 1
2004-09-29 03:55:19 [---] 1923 double precision MIPS (Whetstone) per CPU
2004-09-29 03:55:19 [---] 3013 integer MIPS (Dhrystone) per CPU
2004-09-29 03:55:19 [---] Finished CPU benchmarks

WU's seem to be taking around 28 mins.

Hm, that would be about right :)

I've read over on the SETI Page that (so far) the developers always encountered Problems of the Linux Benchmark taking off excessively or even having its benchmarking loops being removed by their compiler (?) , thus they couldn't fix the Benchmarking issue so far...

If you could post your Compiler and Flags used into the BOINC Bug report or their Suggestions Forum, it might help them getting this Bug fixed :)
___________________________________________
<p>Scientific Network : 36200 MHz «» 8204 MB «» 815.0 GB </p>