It's probably "Boincstats-Willy" problem. It might have to do with the special fields that only rosetta has. BAM is still a work in progress.

For some reason when I checked the /etc/hosts file it had no entries. I had not cleared this out at all and it had a hostname set in the Network config GUI. The only thing I had done in the Network GUI config was set a static IP for use with BOINCView. Then, I put in the line 127.0.0.1 localhost.localdomin localhost (which is the exact line from another FC5 box that works fine) and rebooted the system. That still did not work. So, I went back to the Network config in Xwindows and changed the hostname completey from FC5-P3-450 to FC5-4, rebooted the system and looked in /etc/hosts and the "line 127.0.0.1 localhost.localdomin FC5-4" shows up. I do have a decent understanding of Linux and some of its config files so I know what is going on in them, but not exactly what caused the problem. Now, RALPH seems to be working properly, although there currently seems to be no work units available.

127.0.0.1  "hostname" localhost

Forgive me.. I know you're having a moment - but I'm confused, and I need your help to understand things - You're leaving because we're trying to figure out how to prevent falsification of credit data?

How can you be malicious (easily) if the core application has it's own encrypted method of 'benchmarking', the workunits have their own encrypted tags, and the results are also containing encrypted tags? I'm assuming that there are parts of the Rosetta Core application that are not available to the GP as source..

If you were to use a code (such as 512bit RSA? 1024-bit RSA enough?) that is (realistically) unhackable, then why do you think people could still alter their benchmarks if you control every step of the process?

I recon a 10% difference is good going for any credit system



My first two results for the same coputer
3,324.83 secs 7.57 credit = 439 secs for 1 credit
3,557.41 secs 9.00 credit = 395 secs for 1 credit

So we have ~11% difference between these two tasks on the same computer.
Really they should be the same time for 1 credit but that's never going to happen :-)


Is that good enough? Not a large sample though, that could only make it worse ;-)

I agree entirely with Ethan, and my position on the whole 'optimised' boinc manager situation is that it isn't in breach of the rules, but I consider it poor sportsmanship.

feet1st and Trog Dog:

We should first see what the response to the new method is and whether users would prefer it over the old. Not everyone will be happy about the final decision. I prefer abandoning the old system but that's just my opinion. Users that prefer the old system cannot use as an argument that they get more credits for whatever reason with the old system. The goal to even the playing field.

G'day feet1st

You say you presume that the old system will eventually be abandoned, but so far there is nothing from the project devs to confirm this.

Maybe I'm reading things wrong, but the official message as I read it is the old system will be kept in place and both will be reported,but the old system will continue to be exported.

You are correct, I'm reading in to their statement that they are "changing the credit system". From that I infer that eventually the new system, whether in it's initial form, or after some revisions, will be used for credit reporting. And that the dual credit system is a temporary measure as we all become familiar with the new system.

Currently there are talks at E@H for project optimization apps that will would increase the current credit per hour about 20%-30%(faster WU's more credit per hour). And SETI 5.17 is suppose to incorporate a higher muliplier to match E@H, and further optimization on SETI would allow for even a greater credit per hour.

Why keep the old system in place?

In part so everyone can see they're still being credited fairly. Once folks get used to the new system and it is calibrated to BOINC flops and credit values, I presume the "claimed credits" information would eventually be phased out.

Everyone keep in mind that the current standard boinc crediting system will still be used.

Also, minor modifications to the credit/model values will not make that much of a difference in the long run. The important thing to know is that given any credit/model value, users will be on a level playing field. I think we can all agree that this is the major drive/motivation for coming up with a new method. Making sure it closely matches the BOIINC credit values is not as important since we will still use the old system along with the new.