1) Message boards : Number crunching : Contact (Message 10240)
Posted 17 Sep 2005 by Profile Markku Degerholm
Post:
<blockquote>A message to admin because of this fault could you please stop pending credit in my account and give me either zero credits or somecredits for doing the work.</blockquote>

We have done manual "dead result harvesting" now and then but we don't want to do it too often because manual database updates have a nonzero possibility to generate some more or less nasty side-effects. A proper system for doing this is on the TODO-list...

2) Message boards : Number crunching : Maximum daily WU Quota (Message 10239)
Posted 17 Sep 2005 by Profile Markku Degerholm
Post:
<blockquote>
IIRC, and please correct me on this one, If a given user continually and consistently returns bad results such as those which complete in seconds (or less) and report 'client error' isn't their maximum daily WU quota supposed to be reduced by a certain factor of "x" per bad result per day? I came across this user today while reviewing my ever-growing pending queue. He has 3 successful results out of 80 yet his quota is set for 100/day.

Is there a time delay (in days/hours/etc) before a user would be penalized? It looks like the user in this example is new and has only been crunching since 14 September, however shouldn't that have already been enough time for the quota to be reduced by some number?
</blockquote>

The download quota is the same for everybody, currently it's set to 100 results (result = instance of workunit) per day. If an user has problems it can happen that all the 100 results fail immediately, but it's not a big problem. The server just generates more results and sends them to other users. The only drawback is that the server has to do bit of extra work. In other words, we are not very concerned about this as long as it's not too common.
3) Message boards : Number crunching : LHC@ Home emailer needs a slight update.. (Message 10107)
Posted 12 Sep 2005 by Profile Markku Degerholm
Post:
Thanks for info, it's fixed now.
4) Message boards : Number crunching : Intel compiler version for x86 Mac OS X? (Message 10106)
Posted 12 Sep 2005 by Profile Markku Degerholm
Post:
The biggest problem is that the Fortran compiler we use is proprietary software and does not support Mac OS X.
5) Message boards : Number crunching : Contact (Message 10104)
Posted 12 Sep 2005 by Profile Markku Degerholm
Post:
<blockquote>They did have a problem with an over eager file deleter and this may be a manifistation of that bug again, or since a valid quorum has already been reached the validator is not revisiting that wu. I doubt if you will ever be granted credit, but it would be good if one of the project admins could acknowledge it.
</blockquote>

I think the result failed because of upload problems. It seems the result file never reached us. Unfortunately there won't be credit for this one, sorry.

Why the upload failed is another question - but very hard one to answer. Maybe it was overloaded server, maybe it was a network problem, maybe it was a client problem - who knows? The cause of failure doesn't show up in the server logs.


6) Message boards : Number crunching : Was The Problem of how "0" reported On Different OS's Ever Solved? We never Did Hear.. (Message 10102)
Posted 12 Sep 2005 by Profile Markku Degerholm
Post:
Chrulle knows better but I think we never found the actual reason. However, we have worked around the problem so far by not using the newest BOINC API with the Windows client.
7) Message boards : Number crunching : When Will LHC Server Be Updated to Handle BOINC 5.1.*? (Message 9919)
Posted 4 Sep 2005 by Profile Markku Degerholm
Post:
We are waiting to get another server which we will use for backup and testing purposes. We will install BOINC5 and MySQL4 on that and start alpha-testing. But I don't know when this will happen.

Anyway, we are not in hurry with BOINC5. We let other projects experiment with it for a while and see how they are doing:)
8) Message boards : Number crunching : Bug in the Credit addition (Message 9504)
Posted 20 Aug 2005 by Profile Markku Degerholm
Post:
<blockquote>Sorry for asking, Marku, but aren't these two parts contradictory to eachother?

<blockquote>Too much differing results are granted zero credits. </blockquote>
<blockquote>We like to grant credit based on the CPU time dedicated to the project.</blockquote>

What if 4 computers have returned the result correctly, but their time amounts differ greatly? Say it's a 10,000 turns WU and the run times are 2,000 .. 4,000 ..6,000 and 8,000 seconds. That's all a lot of time, but they should be considered invalid according to your first statement. The second statement says they should be valid.

All on a non-cheating basis. </blockquote>

I'm not sure if I got your point. Anyway, by "too much differing" I meant difference in the result, not in the processing time. So in your example all the validated results should get the same amount of credit because they have all completed the same work unit.

With "based on the CPU time" I meant that people who donate CPU time to the project should be granted credit (dependless of possible small errors computation may produce. How much credit to get per donated CPU hour, that's an another matter.

I hope this answered your question - If I understood it incorrectly, please restate it:)
9) Message boards : Number crunching : Bug in the Credit addition (Message 9492)
Posted 19 Aug 2005 by Profile Markku Degerholm
Post:
Having said that, I must confess that it's only how it's supposed to be. There really is something odd with the validator. The validator is based on the BOINC validator template and modified to do some LHC@home-specific tricks. Probably the BOINC part does something unexpected. Need to investigate more...

EDIT: A bug found and killed. Let's hope there aren't too many left.
10) Message boards : Number crunching : Bug in the Credit addition (Message 9487)
Posted 19 Aug 2005 by Profile Markku Degerholm
Post:
<blockquote>
What is the current project policy regarding invalid results?
</blockquote>

Partially invalid results are granted one half of the credit granted to the canonical result.

Too much differing results are granted zero credits.

<blockquote>
If so, are these credits realy granted, or just some cover up for not granted?
</blockquote>

Partial credit is granted just like full credit.

<blockquote>
My opinion:

Invalid is invalid is 0.00 credits.
</blockquote>

We like to grant credit based on the CPU time dedicated to the project. If there is minor computation error yielding a partially differing result, we think it is most likely not the user's fault. For those people trying to fake results, getting the results anywhere near the correct answer (and thus, earning fake credit) is too hard to be worth it.

<blockquote>
Lot's of invalid mean, that this CPU/OS setup is not suitable for this projects needs. I can either fix it, or leave. That's fine, no harm done (as is imho with fake credit).
</blockquote>

I admit there should be better way to see how many results have been invalid for a certain user. Let's see if we can do anything about it.
11) Message boards : Number crunching : 64-Bits, Help or Hinderance (Message 8537)
Posted 14 Jul 2005 by Profile Markku Degerholm
Post:
> Win32 operating systems. However I don't know if sixtrack currently uses SSE
> or if it could even benefit from using SSE instructions in the first place.

SSE could yield performance increase but it's disabled because it has seen to cause numeric differencies on different platforms. Sixtrack is extremely sensitive to numeric accuracy - for a certain double precision floating point operation, all platforms must give the same answer, in all the 80 bits, or the simulation may give very different end-results.
12) Message boards : Number crunching : What is the screen saver? (Message 8504)
Posted 14 Jul 2005 by Profile Markku Degerholm
Post:
> Can someone explain to me what it shows? I see green particles clumping and
> unclumping? What are the particles and what are they doing?

It's kind of show of protons going through the accelerator tunnel, but in reality it has nothing to do with the actual simulation. We have plans to show details about the actual simulation but they are still in the design phase.
13) Message boards : Number crunching : sign up now! (Message 8502)
Posted 14 Jul 2005 by Profile Markku Degerholm
Post:
> Wouldn't this thread belong in the Café?)

Yes.
14) Questions and Answers : Sixtrack : Current size of active hosts and out of work problems? (Message 8298)
Posted 4 Jul 2005 by Profile Markku Degerholm
Post:
You have a point there. But there isn't much we can do about the BOINC core client behaviour. Furthermore, it's very hard to predict when new work is available next... It's up to so many persons with very busy schedules.

There is an option "Connect to network about every NNN days" in the user preferences ( http://lhcathome.cern.ch/prefs.php?subset=global ). Setting a higher value should prevent a dial-up connection from being made too often. But I haven't tested this.

Current active user base is about 2000 users and 4000 hosts. So it's true we have lost about two thirds of registered users, but this was predictable. And even the current user base is draining the work out off the server quite fast.
15) Questions and Answers : Sixtrack : MD5 computation error? (Message 8297)
Posted 4 Jul 2005 by Profile Markku Degerholm
Post:
> wjun2A_v6s4hvpac_mqx__5__64.251_59.261__10_12__6__65_1_sixvf_boinc5845.zip: file was not found on server

This is due to a job submission error on server. The problem is being fixed.
16) Message boards : Number crunching : Error Downloading...file not found on server. (Message 8293)
Posted 3 Jul 2005 by Profile Markku Degerholm
Post:
> wjun2A_v6s4hvpac_mqx__5__64.252_59.262__10_12__6__35_1_sixvf_boinc5907.zip:
> 404
> 3/07/2005 12:43:30 AM|LHC@home|Giving up on download of
> wjun2A_v6s4hvpac_mqx__5__64.252_59.262__10_12__6__35_1_sixvf_boinc5907.zip:
> file was not found on server

It seems there was a job submission problem. Probably two scripts were submitting same files at the same time. There was a mechanism to prevent this, but it was broken. It's fixed now... But some workunits remain undownloadable. Let's see if we can fix that.
17) Message boards : Number crunching : sugestion for downloading BOINC from LHC website (Message 8276)
Posted 2 Jul 2005 by Profile Markku Degerholm
Post:
Yes, there's a point in what you say. We have considered that. However, SETI usually updates their server and client side much more often than we update our server side, thus resulting in possible incompability between the new client and old server.

Maybe we could add a link to SETI download page. But at least we will update our client distribution soon.

18) Message boards : Number crunching : new work is here!!!! (Message 8275)
Posted 2 Jul 2005 by Profile Markku Degerholm
Post:
> BUT: Boinc told me something of 9 hours and 45 minutes of completion, my (1st)
> CPU finished in 2:30 to 3 hours. so i got only 3 or 4 WUs :-( (BOINC 4.45)
> On wich CPU the time is 9:45h ? => pentium 100 ??

Chrulle is running a program which does statistical survey on run times. So soon we well have better estimates on the run time.
19) Message boards : Number crunching : New work soon (Message 8241)
Posted 30 Jun 2005 by Profile Markku Degerholm
Post:
Some clarification on terms: job = workunit and workunit = X results. Currently X is 5, meaning that each workunit makes five results that are sent to the clients. So, to be precise, the Server Status should say "NNN results". But for a first-time user "result" is a bit misleading - after all, it means something already done. So we chose to use "workunit" which isn't that far from the truth.

"result" is a database term. In BOINC database a result is a "result" even before it's computed. But because it's used in database, it's used in the BOINC jargon generally.
20) Message boards : Number crunching : New work soon (Message 8187)
Posted 28 Jun 2005 by Profile Markku Degerholm
Post:
Our physics dep. promised to give out new work soon. They said "a lot", let's see how much is that:)


Next 20


©2020 CERN