LHC@home

We have been doing alpha testing of the new clients and it seems to be going well. At least zero CPU time and progress indicator problems have been resolved.

We continue testing of the clients until our physicists are ready to generate more work.

---

Markku Degerholm
LHC@home admin

thanks for keeping us updated. We really appreciate that.

---

> thanks for keeping us updated. We really appreciate that.
>
>
>
WE CERTAINLY DO... Thanks Markku!!! :-D

---

> We continue testing of the clients until our physicists are ready to generate
> more work.

The lazy bums ... they should have been making more work already!

Could it be Cherenkov radiation that, um, that made them lazy?

---

> thanks for keeping us updated. We really appreciate that.

I agree.
And THX to the CERN-team for the hard working over the past weekend!
(If not; we hadn't such much work to test at the LAN-party!)

greetz littleBouncer

Markku, Thank you for the news. My soul can rest now.

tony

Cool....thanks ace!

---

Paul
(S@H1 8888)
BOINC/SAH BETA

since April 4th about 185 LHC (produktiv) WUs found the way to *my* clients.
Some are still pending and a small amount is still to be processed by the clients.(Result offset =200)

I went trough, found only 4 "strange" results returning a "0":
ALL of them had an execution time of only a few seconds


resultid=38810
CPU time 0
stderr out
Validate state Valid
Claimed credit 0
Granted credit 0.0429765904437008
application version 4.64


resultid=388193
CPU time 0
Validate state Valid
Claimed credit 0
Granted credit 0.0165617483638138
application version 4.64


resultid=38819
CPU time 11.546875
Claimed credit 0.023762991622237
Granted credit 0
application version 4.64

resultid=389183
CPU time 20.03125
Claimed credit 0.0800060458069565
Granted credit 0
application version 4.64

A headache creating "long running" WU, returning "0" could not be found

success!

About 10 Users, attached to the LHC Alha project, got work yesterday,
my modest contribute was about 60 WUs (appl.ver 4.66) from there. (offset=60)

There no one had the "zero" returning

success nr2!

so far it looks great!

keep on.

> since April 4th about 185 LHC (produktiv) WUs found the way to *my* clients.
> Some are still pending and a small amount is still to be processed by the
> clients.(Result offset =200)
>

ric, you make me jealous.... I got NONE!!!! :-(

---

After short examamination of your results : they are all s18_!

IMO:
For me: s16_ and s18_ are the most 'critical' WU's, they will finish very fast ( between 0 sec and 5 min. )

what do I mean with s18_?

explan:
v64boince6ib1-19s18_20645_1_sixvf_23940_0

I have a 'stats' about this over about the same # of WU' as you....:-)
or you take a look here!
(I still have to crunch:-))

greetz littleBouncer

---

sysfried, no need to feel jealous,

an other time you will get your part to do and I will have "nothing"

And the number are not high, used to see a little more.


There are so many nice and beautifull stats sides, one of them is the
boincsynergy

Take a look to, even if it's a view in the past(like all stats), it shows that many users got work.

look here



and LB, I have seen your provided informaions, in short, this means,
as lower the s_xy number is, as loger they would/could/should run?

so hurry to crunch your part down, the validation for the pendings waits...

have a good time

> and LB, I have seen your provided informaions, in short, this means,
> as lower the s_xy (corr. sxy_) number is, as loger (corr. longer) they would/could/should run (add.: the simulation)?

Yes (see also the corrections in parentesis) , I made a table in that thread.
Meanwhile I have exacter #'s, but if you unterstand the system you can adapte on your results.

BTW: Take s4_ as base (als Basis)or 'normal-run-time' or 100% ,( your avg. CPU-time for such (s4_) WU's).

I crunch 'full steam' here (just s---day)

greetz lB:-)
[EDIT] @ Chrulle; as I predict, the other statement was only to explain this table.
[/EDIT]

the number in s(number) like for example s16 is the amplitude of the starting conditions, the higher the amplitude the more likely it is that particles will be lost.

---

Chrulle
Research Assistant & Ex-LHC@home developer
Niels Bohr Institute

> the number in s(number) like for example s16 is the amplitude of the starting
> conditions, the higher the amplitude the more likely it is that particles will
> be lost.
>
>
>

Thanks for the information. I'm sure it will be useful whenever more work is made available.

---

So far no probs here (Win 2000 PROF, AMD Athlon)

---

Well, Trouble in Disneyland ...

84619
84143
84620

What is especially painful is that I know at least one of these ran for close to the full 10 hours ...

---

> Well, Trouble in Disneyland ...
>
> 84619
> 84143
> 84620
>
> What is especially painful is that I know at least one of these ran for close
> to the full 10 hours ...
>

They were chrunched using app. ver. 4.64 or am I misstaken.
The bugfix is in app. ver. 4.66, right???

---

> They were chrunched using app. ver. 4.64 or am I misstaken.
> The bugfix is in app. ver. 4.66, right???

Great! How the hell did I get work for the broken client?

---

> > They were chrunched using app. ver. 4.64 or am I misstaken.
> > The bugfix is in app. ver. 4.66, right???
>
> Great! How the hell did I get work for the broken client?

Bad luck I guess. The first unit I got yesterday used 4.64 and the next used the new 4.66.

---

> > > They were chrunched using app. ver. 4.64 or am I misstaken.
> > > The bugfix is in app. ver. 4.66, right???
> >
> > Great! How the hell did I get work for the broken client?
>
> Bad luck I guess. The first unit I got yesterday used 4.64 and the next used
> the new 4.66.

Same here. But fortunately it was just a single v.4.64 WU. I only noticed 1 0 CPU time WU with v.4.66 (in alpha test) and am still uncertain what caused it.

Happy crunching,

---