LHC@home

I just noticed I must have received 38 LHC WU's Today, it must have took all of 5 min's to do them all ... What the heck were they about ... hehe ... :P

My Computers are pretty much just sitting here Idling & patiently waiting for more LHC WU's. I've given up on most of the other Projects. Pirates & BURP have no Work to send. Predictor seems to be having problems I don't care to get involved in.

CPDN has raked me over the coals the last few days with several thousand credits lost due to software changes & or server problems. So that only leaves Seti & Einstein & I don't want to get loaded up with their WU's & then have LHC release theirs. Then I would have to get rid of the Seti & Einstein WU's by some devious manner ... hahaha

Anyway my CPU's are getting a well deserved rest & running nice & cool for a change ... :P

------
Actually, P@H didn't chance which version of the BOINC client they're recommending, just the version of the P@H application (MFOLD)
------

Where exactly did I mention the BOINC core client?

------
Predictor seems to be having problems I don't care to get involved in.
------

P@H have reverted to their 4.28 client. It is running fine.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

> Please stop now bad mouthing!

Please stop misunderstanding!
:)
Actually, I'm not bashing LHC or any LHC folks. It was just a simple two line comment ending with :) "a smile".

> This timezone can't be explaned with legacy science.

No, it can't and neither should it be, because we have all entered the "BOINClight zone..." (To the theme of The Twilight Zone).
:)

and just in case someone misses it :) :) :)

> Well, once again we are stumped.

Thanks for the update Chrulle.
I wish I could offer some suggestions, but I have no real ideas.

How do the Alpha results compare? I have NT box there returning results and only ask because win2k and winXp are supposedly built on NT technology...

Are you using the same compiler and compiler options?
perhaps MSDN lists something about sp1 and floating point changes.


> Well, once again we are stumped.
>
> On the XP sp1 and XP sp2 and 2000 sp 4. The results we get back are strange.
> The numerical value of the results are the same, but while we on other
> platforms the representation of 0 is 15 digits and a E on the afore mentioned
> platforms we get 16 digits and a e. This is not really a problem because the
> value is the same just the representation is different. So we simply have to
> change our post processing checks to actually parse the results instead of
> just running diff.
>
> We are worried though, because we do not understand why this is happening, and
> although we have not seen it affecting any of the real numbers yet it might
> still happen. We are doing static linking so there should be no reason for
> this to happen.
>
>
>

Thanks for update!
Is there a difference between AMD and INTEL??

> :)
>
Ahh the 2 liner..

But now seriousely, there is work from LHC right NOW.

Now in term of now (17:21) local swiss time and thats what the clients are getting NOW are 100'000 turnes

What a feeling!

The long valey of suffering is passed.:)

The other miracle is, the clients running 4.44 dev versions are also getting work.
(Now I'm happy and quiet)

Thankyou LHC!
___________________________

(NT=never trust)

> I just noticed I must have received 38 LHC WU's Today, it must have took all
> of 5 min's to do them all ... What the heck were they about ... hehe ... :P

grrr. You'll get yours. I'm a firm believer in "What goes around, comes around." ;-)

May all the EMP activity in your area accidentally get concentrated over your head.
<*<>8-> While you're scrambling for cover and replacement parts, we'll be eating up those wu's... just you wait... hehe.

grrr. You'll get yours. I'm a firm believer in "What goes around, comes around." ;-)
==========

hahahahahaha ... I guess your right, I must have returned them so fast the server has decided to give me a couple of hundred WU's on each of my computers ... tomorrow must have come ... :P

> hahahahahaha ... I guess your right, I must have returned them so fast the
> server has decided to give me a couple of hundred WU's on each of my computers
> ... tomorrow must have come ... :P

Admins, since my EMP wizardry appeared to fail, may I humbly request a wu quota of 15 per CPU be imposed on PB, with immediate effect. :)

(I know this belongs in the cafe, but starting another thread just wouldn't do. If anyone feels especially adverse to this innocent banter, please advise.)

I got a work unit ! Didn't run for very long though. The WU names seem to be even longer than the previous ones.
http://lhcathome.cern.ch/workunit.php?wuid=257786

---

I got a small stack of 100,000 turn work units... Just to get them back faster ... suspended all but LHC@Home ... I want nothing to stand in the way of us getting more work built up ... :)

---

Well got a couple dozen wu, something is better than nothing, Happy crunching all!!!!!

---

Yep, got two as well. Man, these things have names that are a code on itself.
But the running guestimate of 1h25m is a tad on the long side. On my machine they take around 26 minutes.

---

Jord

BOINC FAQ Service

I was lucky enough to get 23 WU's. Estimated time 54 minutes, crunching time 17 minutes.

---

> Thanks for update!
> Is there a difference between AMD and INTEL??

I realize your question is more aimed at "are the winNT clients on both Intel and AMD platforms experiencing this issue or is it one or the other or not cpu related at all?" .. Intel and AMD are different- I can't quote the doc that I read about the fpu differences a year ago but for example's sake, if you were to send to the FPU on an Intel 1/3 = .33333~ 2/3=.66666~ and 3/3=1.00001 and AMD would be 1/3=.33333~ 2/3=.66666~ and 3/3=.99999~ (I could have the numbers backward but the example is still the same either way). There are plenty of ways around these numerical differences and LHC has used a new math library that gets around earlier problems between platforms.

Your question is a very good one though. :)

---

As I understood chrulles post, the problem is that on some platforms zero is represented in the output in different ways, ie...

000000000000000E00
0000000000000000e00

... both are clearly zero, but if the output files are being compared with a diff command, they will report the files differ. The printed representation of zero would be software dependent, not hardware, zero is zero on Intel or AMD. It is true that real numbers might be represented differently, but zero is one things most people can agree on.

A simple substitute pre-processor will correct this problem, but as he states, the "problem" may not be a problem at all, rather, a symptom of something more sinister. Therefore an explanation is required.

Unfortunately, chrulle's post does not give enough information to suggest ways forward. He says XP SP1, SP2 and 2000 SP4, the implication is that these OS/SP combinations provide different results from the same OS's with different SP's - in which case we are looking at a service pack issue. It could, however, be that he was simply giving examples of Windows versions which differ from *nix for example.

It would also be an assumption that this was coming from Fortran code, but he does not state the I/O descriptor he is using, E or G etc., or the variable types *4, *8 etc., or the compiler and it's options.

If the output is coming from C/C++ code, the same questions arise, although the details differ somewhat.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.