1) Message boards : LHC@home Science : Black hole question (Message 20625)
Posted 5 Oct 2008 by PJ
Step 1. Put a black hole in a lab.

Step 2. Do some tests.

Step 3. See if results match expected. If not, then you\\\\\\\'ve discovered something new or at least discovered that your assumption may have been incorrect.

Well. My electrical bill is already steep as of now. So I won´t be investing into that.

So sorry, that answer is impractical for me.
2) Message boards : LHC@home Science : Black hole question (Message 20605)
Posted 3 Oct 2008 by PJ
In a discussion about the LHC and worlds near end (Ha!) I came across the question what forces a black hole can actually exhibit?

The corresponding formulas mention Mass, Angular Momentum and the electric Charge as factors in the equation describing a Black hole.


The question that came up was if the Black Hole actually exhibits an attracting force on particles of the opposite polarity (and correspondingly a repulsing force on particles of equal polarity) beyond the Event Horizon?

I think that, as photons are transmitters of information and forces within electromagnetic fields, that the information that the particular charge is there can not possibly go through the Event Horizon and therefore, beyond it, no forces on charged particles through the charge of the black hole are exhibited.

I expect that the energy of the charge actually contributes to the mass of the black hole and that this is the whole effect measurable beyond the Event Horizon.

Can someone enlighten me please? :D
3) Message boards : Number crunching : When will the Pending WUs with 0 credit claim be deleted? (Message 20604)
Posted 3 Oct 2008 by PJ
... they clutter some of the pages unnecessarily.


4) Message boards : Number crunching : Very short Intel computation vs. normal AMD (Message 19476)
Posted 18 Apr 2008 by PJ

anyone seen this before:


My AMD Quad core computed the WU in a "normal" amount of time whereas the Intel based systems ran very short successfull outcomes.

I think that results need to be scrutinized as this looks weird to me.


5) Message boards : Number crunching : Initial replication and missing workunit (Message 19183)
Posted 7 Mar 2008 by PJ
Hello !

2 questions for the same thread :

1) Is an initial replication of 5 really useful when you need a quorum of 3 ?

Rather than set short deadlines, this project tries to ensure fast turnarounds by using IR > Q. This decision has caused some controversy amongst crunchers, but the admins have said they will look at it again when they upgrade the server code.

Aren't the last 2 results a waste of CPU time ?

Yes. And because the server code is such an old version, the server can't ask clients to abort the unnecessary WUs. :-(

Otoh if a workunit is already in progress aborting it would be a waste, too. If the "faster" units did not error out the additional result is not really helpful, that I agree.

But if the "fast" units error out a "slow" workunit on a different architecture might still finish and give needed data.

So unless IR >> Q (say more than two surplus workunits) a little surplus of IR is making sense imv.
6) Message boards : Number crunching : granting less credit than claimed? (Message 19046)
Posted 21 Feb 2008 by PJ
Seti used to rely on the Boinc Client integer and floating point benchmarks to determine what credit to assign to a certain amount of CPU time. The more opeations per second your computer could generate the more valuable the time of that computers CPUs was.

The BOINC client benchmarks were and are not really indicative of how the distributed applications would utilize the execution command sets particular to the CPUs being used in a PC.

Optimized clients were introduced which were optimized in the way that they could produce a higher benchmark score due to the utilization of CPU specific command set enhancements, etc. These clients were claiming a lot more credit per time than the not optimized ones.

So for example the standard boinc client would claim that during the two one minute benchmark computation sets it could compute, say, 1000 integer ops and 500 floating point ops per second per CPU.
The optimized client could on the other side execute, say, 2000 integer and 1200 floating point ops during the test because it used different commands/registers than the standard client.
The optimized boinc client would claim 100% more credit in an integer only situation and even 140% moe cedit in a floating point operation situation.

The applications utilized in Boinc projects are usually not optimized in that way, so that each and every architecture is utilised at an optimum. So the inflated benchmark scores were not really reflective of the actual contribution of the particular machine running the optimized client. Only in conjunction with an equally optimized application the claims are relative to the contribution.

With the standard BOINC client a similar situation arises when looking into different CPUs or even different configurations of the same CPU (Win32, Win-x64, Linux, etc.). Not every application workload executes equally on different CPU architectures, as here differing execution command sets come into play again. And the BOINC client benchmark is only one (actually one integer and one float) possible workload scenario.

So, no wonder you get differing credit claims. Afaik the "new" SETI applicions count the amount of actual operations per work unit and that is used to calculate the credit claims. That is how they actually accomplish that usually each claim is within 0.02 points of each other. ( You see if someone uses a 4.x client as that differs considerably in credit claim from platform to platform.)

HTH & Cheers
7) Message boards : Number crunching : What's with the tiny work units? (Message 19003)
Posted 9 Feb 2008 by PJ
We have had million turn studies over the years that run the ranges of sizes from 30 credits =3hrs to these type and an even longer version 150 credits=20 hrs on the same type technology.

The million turn studies rarely crash into the collider hence no 0 claims here.

Rare, perhaps, but not entirely unknown. WU 2139867.

Maybe the meaning was that if it runs past the initial minutes it will likely finish?
8) Message boards : Number crunching : Is the user base/project participants growing a bit too large, for our server? (Message 14491)
Posted 6 Aug 2006 by PJ
Now, who has not?

©2024 CERN