I noticed there re some very suspect RAC numbers in the computers list. Is anyone addressing these suspect computer numbers?

---

.....only if you point them out....

.....only if you point them out....

There is an Athlon 3800 averaging 3000someodd credits a day. Their benchmarks are 14.48k and 13.8k respectively. Even with an optimized client and overclocking the core (you can get a 3800 to 2.6 ghz) there is no way to achieve those benchmarks.

My Athlon 4800 gets around 3.2k and 10.1k benchmarks.

They cheat and it's annoying, but I guess it makes them feel special. Actually, it's not exactly cheating but it is monopolizing the top computers section unfairly and also in that it appears to be a bid for attention.

We are talking about a science project, not some sort of game. It's the workunits that count.

---

I noticed there re some very suspect RAC numbers in the computers list. Is anyone addressing these suspect computer numbers?

I took a look at your computers and wanted to point out that your pentium 3ghz has odd benchmarks. Your floating is 2300 while your integer is 1500.

---

I noticed there re some very suspect RAC numbers in the computers list. Is anyone addressing these suspect computer numbers?

I took a look at your computers and wanted to point out that your pentium 3ghz has odd benchmarks. Your floating is 2300 while your integer is 1500.

This could be caused by having a program running when BOINC performes an automatic benchmark. You can see if it repairs itself by shutting down all unecessary (non BOINC) applications, and manually running the benchmark.

that is exactly what was happening, I had it CLI to run_benchmarks on startup and then hooked to the rc.d system, This caused many benchmark problens during boot up as other things wer starting up at the same time.

---

that is exactly what was happening, I had it CLI to run_benchmarks on startup and then hooked to the rc.d system, This caused many benchmark problens during boot up as other things wer starting up at the same time.

You could try something like what I did (minor diff: I decided to run it from cron, rather than add a script to rc.d):


# crontab -u boinc -l
@reboot sleep 600; ~/BOINC/run_client 2>&1 &

# cat ~boinc/BOINC/run_client
cd "/home/boinc/BOINC" && exec ./boinc_client $@ >> boinc.log 2>&1 &


So, I'm telling it to sleep (wait) for 600sec=10min (sleep 600) and then invoke BOINC. This should give the system enough time to get done with any initial load (start daemons, process mail queue etc) and settle down, plus the CPU itself to come to some "normal" semi-idle temperature, before going to 100% speed (and temperature) to serve BOINC requirements.

10min at reboot may sound a long time, but I don't reboot often :-) BOINC has been running non-stop for almost 2 months now (I only restarted it on 18-Jan to upgrade the executable)


# uptime
02:05:11 up 64 days, 22:10, 1 user, load average: 0.99, 0.98, 0.99

# ps u -U boinc
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
boinc 27870 0.0 1.5 6792 3384 ? S Jan18 2:02 ./boinc
boinc 4888 76.1 20.7 180852 46440 ? RN Mar11 366:49 rosetta_4.81_i686
boinc 4889 0.0 20.7 180852 46440 ? SN Mar11 0:00 rosetta_4.81_i686
boinc 4890 0.0 20.7 180852 46440 ? SN Mar11 0:00 rosetta_4.81_i686

---

Best UFO Resources
Wikipedia R@h
How-To: Join Distributed Computing projects that benefit humanity

The values on the benchmark seem to vary a bit on my machine - and give the impression that it drops when other applications are actively running on the system. Which makes it even tougher to compare a highly used system on one hand to a 24/7 cruncher with highly overclocked cpu and perhaps one of the optimized boinc clients. There's those that dump a whole week's worth of data at once who get high RAC scores; and some have claimed to be able to combine one or more of their machines to generate high RAC scores.

But if the Boinc crew are looking at switching the scoring mechanism, (or Rosetta and other Boinc apps start performing their own scoring mechanism) then this should be a mute point soon.

---

The values on the benchmark seem to vary a bit on my machine - and give the impression that it drops when other applications are actively running on the system. Which makes it even tougher to compare a highly used system on one hand to a 24/7 cruncher with highly overclocked cpu and perhaps one of the optimized boinc clients. There's those that dump a whole week's worth of data at once who get high RAC scores; and some have claimed to be able to combine one or more of their machines to generate high RAC scores.

But if the Boinc crew are looking at switching the scoring mechanism, (or Rosetta and other Boinc apps start performing their own scoring mechanism) then this should be a mute point soon.

You can run a benchmark at any time you wish and then just 'update' to get it pu t in. You should? be able to edit the global preferences file to exclude further benchmarking (you'll need to know what line to use).

Einstein@home already has removed the ability to used an optimized boinc client and generate enhanced credit. For example, if you attempt to use just the pure optimization you will report scores twice as high as what you'll be given credit for.

HOWEVER, one of the two good optimizers imho for windows and linux also provides a 'calibration' .xml, which corrects your credit to that allowed by Einstein (which is an 'optimized' application).

Rosetta does not do that and it is why people are able to get away with it. On Einstein you simply can't - or at least not as easily.

The client optimization does lead to a real improvement though - it's not a fake (if you stay away from the ones that are designed deliberately to cheat). Seti actually provided the source of their project to the same guy and others creating their optimized client.

---

The values on the benchmark seem to vary a bit on my machine - and give the impression that it drops when other applications are actively running on the system. Which makes it even tougher to compare a highly used system on one hand to a 24/7 cruncher with highly overclocked cpu and perhaps one of the optimized boinc clients. There's those that dump a whole week's worth of data at once who get high RAC scores; and some have claimed to be able to combine one or more of their machines to generate high RAC scores.

My machine is not dedicated to boinc, but I do allow it to run as often as possible. It is because I use the computer frequently (and suspend I do not use run property preferences) I have continued to increase my work cache because of units that end up dying for whatever reason. I don't like BOINC using my connection either and have it's port blocked except for when I want it to contact the server.

Another issue is that I am frequently gone. Until very recently I had it set for .3 days for network contact. Because my dsl dies every once in awhile I get fairly annoyed when I come home after a week away and see that no units were done but the power was on. It's a waste of electricity and a waste of potential science time - which is the only reason I do it. I set it to 3.5 days today to avoid that problem.

As for overclocking - anyone can do it. You could - it's not as if your AMD's couldn't take it as they can all be ramped up pretty well. I run my Athlon 4800 dual cores at 2.6ghz, up from the stock 2.4ghz. This is without the use of any specialized heat sink (the one for the 4800 is about as good as a commercial add on, well not about but close. Overclocking is acceptable - it's getting the most out of your processor.

It helps that my motherbord's bios is designed with overclocking in mind. In case of system failure it's a simple trip to the bios to reset the voltage and set it back to 200mhz (200 x 12 multiplier = 2.4 ghz).

Yah, I was just noting that if you're getting benchmarks that are weird you should run them again so you get proper credit.

---

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=178583

Yikes! He's getting a benchmark of 20775.93/57953.74 for an AMD XP 2600+.

I'm getting 1073.69/1866.34 for an AMD XP 2600+ using the recommended Linux client.

He's getting 26 times as much credit as I am for the same work. :p

I dont know how to explain those high benchmarks (expecially on Athlon XP 2600, because i can well believe those on dual core processors) but i've got few guys in my team who are crunching on computers without internet connection. They just put results on the flash drives and distribute them to this computers. After procesing results travel the same way to the mashine with internet connection. So work of many computers is recognized by server as work of only one. So sometimes high RAC doesnt have to be cheated.

---

This is why a total focus on RAC alone gives a poor measure of actual system performance.

You are right for RAC. But the reported invented benchmark results are really a pain. I think the way to go is an official (and only accepted) calibrating boinc client and calibrated projects(!). That would stop some of the discussions about cheaters. Plus: the projects had to "hunt" for crunchers with relevance of their science and not with "here you get more credits per minute".

Norbert

---

The reason they're being shared isn't just that they're getting fantastic RACs.. but the benchmarks aren't normal.

My single core 754 pin 2Ghz Athlon 64 cpu gets the following benchmark on its last run on a normal Windows Boinc client:
1869 double precision MIPS (Whetstone) per CPU
3467 integer MIPS (Dhrystone) per CPU

And the X2 3800+, also a 2Ghz cpu, should be getting similar benchmarks - only being able to return 48 hours worth of data in 24 hours. (I've only run single threaded DC projects on my X2 3800+ at work.) To have identical Whetstone and Dhrystone readings is awfully suspicious.

A benchmark in the 50,000 range is likewise suspicious.

Hopefully, the new credit techniques that Boinc is talking about will eliminate this type of problem - rather than move it from the Boinc benchmark to a Rosetta benchmark problem.

---

Looking at some of the top computers shows that they may be (are!) exploiting the credit system. My computer with a standard Boinc client charges about 14 credits per hour while many of the computers in the top RAC list are charging 40 to 60 credits per hour. Is this reasonable? I think not!

In addition some of those computers appear to be doing 1 or 2 hours of work and claiming that they have done 4 to 8 hours of work thereby further inflating their credit claims.

Any fool can create a 'compile your own' Boinc client containing any number of credit exploits. All reputable Boinc projects should ONLY allow an official Boinc client - self compiled clients should be strictly prohibited. I realize that some individuals with odd computer hardware would then not be able to run Boinc projects. In such cases a review of their clients by project developers would be necessary or they would simply be forced to use compatible hardware or just not run Boinc projects.

The reason that an official Boinc client is needed is that many who now process the workunits will be discouraged by continuing credit exploitation (cheating) and simply refuse to contribute any more of their computer time. Potential new users, upon hearing about these exploits and finding that the project developers have failed to take any action, will also not contribute their computer time.

It should also be simple for any project to set a maximum credits per hour per workunit value and enforce it. I realize this is a simplistic solution and may not address all of the projects' requirements.

I find this credit exploitation offensive and the failure by the developers to take any action equally offensive. I contribute my computer time because I believe the science being done here is important. Perhaps I am the crazy one.

Looking at some of the top computers shows that they may be (are!) exploiting the credit system. My computer with a standard Boinc client charges about 14 credits per hour .....

Any fool can create a 'compile your own' Boinc client containing any number of credit exploits. All reputable Boinc projects should ONLY allow an official Boinc client - self compiled clients should be strictly prohibited. ......

I find this credit exploitation offensive and the failure by the developers to take any action equally offensive. I contribute my computer time because I believe the science being done here is important. Perhaps I am the crazy one.

So, how come you are using the truXoft optomised boinc client?

---

to Nightlord:

I do use the truXoft client enabled only for SETI - the results for all the other projects will be unmolested using this method. You might ask why I want to adjust my credits (for SETI) - this is accepted in the SETI project since I am also using an optimized SETI app on a P4HT which you may not know receives an unrealistic benchmark because of the HT. I once used the Crunch3r optimized Boinc client and do not use it now for the very reason that it is an unfair credit exploit in the other projects.

to Moderator9:

Thank you for your fair and reasonable response. I really only want to open a dialog among the Rosetta community about what IS fair and resonable. When I asked for a maximum credit cap, read carefully, I said 'credit/hour/WU'. That accounts for how long you run a WU! By the benchmark standard, which is flawed, a faster computer should get fewer credits than a slower computer doing the same (or very similar) WU. Yet that is not what is seen in the credit stats! Many of the claimed credits are plainly inflated! My computer does the same work yet these other computers are charging 4 to 8 times the credit!

A standard reference WU could be sent out from time to time to measure the actual performance of certain suspect computers. I know that this is extra work for someone in the Rosetta project but it could restore the perception of fairness by the Rosetta community.

I do realize that the project developers are ONLY interested in getting people to run their WUs. The project developers have a credit making machine in the server closet and give out credits like they were free. Well, I guess they are!

The solution for me, I think, is to just chill out - and don't look at the credits - if I really don't care. So, I won't look any more. I won't! I won't! I won't! Do you think that will work?

I made the suggestion of benchmarking a single model of each WU released for us to crunch, and give us credits based on the number of models we turn in.

i.e. run a benchmark on FA_RLXen_hom029_1enh, HB_BARCODE_30_256bA, FA_RLXlo_hom025_1louA, FA_RLXai_hom025_1aiu, FA_RLXbq_hom022_1bq9A, FA_RLXce_hom002_1cei, etc (each of the 10 new WUs for Dr. Baker's group testing new approaches, and the 20-40? other new WUs from another part of Rosetta.) Turn in 100 models of FA_FLXen_hom029_1enh, and get 100*credit computed on the test benchmark system in the Rosetta lab for that particular WU. It would totally eliminate any form of Boinc benchmark abuses; unfortunately, Boinc isn't setup to deal with that type of approach yet.
To increase your credit/day rate, you'd have to upgrade your cpu, add more ram, reduce the number of unneccessary apps draining cpu cycles, etc - or just replace it with a new system. i.e. to get more credits per day, you'll have to produce more per day.

After the major bugs are worked out ( /e starts chanting "Death to the 1% hanging bug!!!"), they've promised to work on the credits issue. And since it only took 9 days to eliminate 60-70% of the errors reported to the server.. that means we don't have long for the remaining 30-40% to be put into their graves. /e ducks as these things aren't always solved in a linear manner.

---

to Nightlord:

I do use the truXoft client enabled only for SETI - the results for all the other projects will be unmolested using this method. You might ask why I want to adjust my credits (for SETI) - this is accepted in the SETI project since I am also using an optimized SETI app on a P4HT which you may not know receives an unrealistic benchmark because of the HT. I once used the Crunch3r optimized Boinc client and do not use it now for the very reason that it is an unfair credit exploit in the other projects.

The solution for me, I think, is to just chill out - and don't look at the credits - if I really don't care. So, I won't look any more. I won't! I won't! I won't! Do you think that will work?

Fair enough.

Are you aware that turning off the calibration in the truXoft client does not remove the benchmark optomisation which is performed by that client? Your benchmarks and hence claimed credit on Rosetta will be higher than the standard boinc client would return. However, I can now see that is not your intention.

Briefly switch back to the standard client, run the benchmarks and compare to confirm if you wish.

[edit]
Be sure to back-up your boinc directory before switching clients. I accidentally just trashed a cache full of WU in verifying this.
[/edit]

---

Are you aware that turning off the calibration in the truXoft client does not remove the benchmark optomisation which is performed by that client? Your benchmarks and hence claimed credit on Rosetta will be higher than the standard boinc client would return.

Actually I think that's not accurate - the benchmark by the truXoft client will result in LOWER claims in projects not using the 'optimize' feature. This seems counterintuitive to me but that is what is documented at the truXoft site. This is evidently because the client code has a modified benchmark that is tailored to the 'optimize' feature - i.e. they work together. The code for 'claimed credit' is not the same code as in the standard client.

I've even considered going back to the standard client because of this but by my measurement there is little difference and I like the credits I'm getting from Seti.

Looking at some of the top computers shows that they may be (are!) exploiting the credit system. My computer with a standard Boinc client charges about 14 credits per hour while many of the computers in the top RAC list are charging 40 to 60 credits per hour. Is this reasonable? I think not!

In addition some of those computers appear to be doing 1 or 2 hours of work and claiming that they have done 4 to 8 hours of work thereby further inflating their credit claims.

Any fool can create a 'compile your own' Boinc client containing any number of credit exploits. All reputable Boinc projects should ONLY allow an official Boinc client - self compiled clients should be strictly prohibited. I realize that some individuals with odd computer hardware would then not be able to run Boinc projects. In such cases a review of their clients by project developers would be necessary or they would simply be forced to use compatible hardware or just not run Boinc projects.

The reason that an official Boinc client is needed is that many who now process the workunits will be discouraged by continuing credit exploitation (cheating) and simply refuse to contribute any more of their computer time. Potential new users, upon hearing about these exploits and finding that the project developers have failed to take any action, will also not contribute their computer time.

It should also be simple for any project to set a maximum credits per hour per workunit value and enforce it. I realize this is a simplistic solution and may not address all of the projects' requirements.

I find this credit exploitation offensive and the failure by the developers to take any action equally offensive. I contribute my computer time because I believe the science being done here is important. Perhaps I am the crazy one.

There really is not too much that a project can do about this. The BOINC code has been publicly released. It is very easy to compile it so it looks identical to the official version, and yet has some benchmark adjustments. Many of these adjusted clients have been made so they fall with in the normal range of credit claims, but at the top end of them.

In some cases the modifications to the BOINC client are simply taking advantage of special features of the computer for which they are compiled and are in fact producing a more accurate and legitimate benchmark for that system. The problem comes in when the project code does not use those features of the system. This causes the benchmark to be high, but the actual processing time to be slower, thus producing higher credit claims. In that case the project might be accused of not provide an application that takes full advantage of the computing power available, but they are hardly doing that intentionally, it is just difficult to have a special version for every possible special system out there.

As to a limit on the credit per Work Unit. This might work on other projects, but it will not on Rosetta. With the time setting it is possible to run a work unit from between 1 hour and days. With that level of variability where would you set the maximum credit? How would you verify it without overloading the servers? In any case you would still have to accommodate the broad range of possible credit claims made by different systems. With the time setting legitimate credit claims can average from 10 to over 2400 credits for a single work unit. Hourly claims range from 10 to around 50, depending on system speed. So this is just not a workable answer.

As far as the developers not taking action. They have deployed the standard BOINC system. While they have chosen not to use redundancy, the ability to make that choice is part of the server software. They have removed some of the more severe violations from the stats as they are identified. The project team is thinking about a variety of possible solutions to the credit issue, but right now they are focused primarily on killing the bugs in the application. Once that is done, they have stated publicly that they will return to the issue of credit claims and awarding of credits owed from a range of processing problems.

Mod, you are twisting this a bit. Regardless of an 'opimized' client a project can calibrate the claimed credits - look no further than einstein@home. They most definately adjust the credits to get rid of the use of inflated benchmarks.

As for the somewhat weak claim that people are merely doing this because boinc doesn't fully utilize their resources (which is the essence of your claim) that is a boinc issue and not a system issue. I know for a fact that AMDs are supported poorly in BOINC compilations in general. That doesn't mean I 'deserve' more credits.

Yes, the source code has been released to the public. Perhaps you should also note that the client doesn't crunch the WUs - the Rosetta application does. It has nothing to do with the project other than to enable Rosetta's app to run and to manage preferences. Rosetta controls the project and has chosen NOT to release their source (unlike SETI where optimization can occur) and has chosen NOT to offer system specific compilations to maximize cpu efficiency.

Which is neither here nor there. RAC cheating is an issue in that it seems to be a vanity issue where people feel the need to be in the 'top computer' section. Given that the run times of these WUs are known it's not exactly like you can't figure out how to adjust credits - Einstein has.

---