To my knowledge there is presently no screening. Since we DO have a new credit system, I'll not comment on your other question. Perhaps you could rephrase it if there are questions there. Under both credit systems, the "optimized" client's credit claims are accepted as within any such limits.

OK then, with no screening what is to stop someone writing a new optimised client that claims even more than the current batch do, or writing a script that increments a hosts benchmarks?

To my knowledge there is presently no screening. Since we DO have a new credit system, I'll not comment on your other question. Perhaps you could rephrase it if there are questions there. Under both credit systems, the "optimized" client's credit claims are accepted as within any such limits.

Keep in mind that the hypothetical 10x claim is pretty easily screened and omitted from the averages as well.

You will need to manually rebench between the switch (H.T. to non- H.T.) to make a valid conclusion.

Is it enough to just set use max cpu to 1 or do I have to completely disable HT in the bios?

Disable in bios.

I realize it isn't simple; but I wanted enough data points to show the effect of the new credit system on P4s.

Graphing with enough data points shows that the credit system seems to be working - as I was showing here: link


That should help, Trog Dog.. Thanks.

You will need to manually rebench between the switch (H.T. to non- H.T.) to make a valid conclusion.

Does someone have a viewable system that they run 24/7 with a 512 Meg P4 running at 3Ghz with HT off? One with HT On? (With 2 or 3 hour WU run times selected).
So we can see the difference between old and new systems with Windows using a P4 with HT off, Windows using a P4 with HT on, Linux using a P4 with HT off, Linux using a P4 with HT on?
All systems preferably dedicated crunchers, not being left running Zoo Tycoon all night until the animals all croak.

What are suggestions for typical Macs? (High end, medium, low end)?

Here's an example of why it's difficult to cheat the system:

After 10,000 models the average credit is 10 per model. Enter Mr C who changed his client to claim 10 times as much as he earned. He submitts 10 models and wants 1,000 instead of the 100 credits.

1,000 + 100,000 / 10,010 = ~10,09

By overclaiming 10 times he increased the average per model from 10 to 10.09 at a very early stage of the run.

The reason the average credit doesn't go down from the change of the system is that to the project it doesn't matter if one user claims 20 credits and the other 60, or both of them claim 40 credits. The total is still 80.


And even though it should be obvious: Faster systems still get more credit. They get the same amount of credit per model, but by virtue of being faster they do more models per hour - hence more credits.

I`m at WCG which like most operates a quorum (how many I know not). My points are all over the place, here maybe a reason.

If WCG hasn't changed latetely, they use Boinc only to distribute work. Their credits are calculaded by points their own SW would have given times a fixed factor.

Norbert
PS: Their factor used to be a bit to the high side (a share of 75 for WGC and 100 for other projects gave equal RAC for me) but seems to be adjusted lately.

I will not prove you wrong, or try to counter your devious ideas. The suggestion I made just takes one extra reason OUT of overclaiming. It doesn't prevent every single cheat you can come up with.

In the current system, overclaiming gives you extra credit, and MIGHT make a difference on your next WU or your teammate's. But YOU are the main beneficiary.

In my suggestion, the first reason is gone. What remains is you MIGHT get more credits on your next WU or your teammate's.

So, I still think that it could be implemented, and probably very easy :

Cuurent system : Calculate a new rolling average, then assign average points

My idea : assign averige points, then calculate new rolling average.

Maybe, maybe not. I would have to do some longterm calculations on this, but point is that you will probably not gain much yourself. By the time you get the next WU from the same batch in, the effect of your previous claim will have diminished. Especially if the WU has had a lot of results reported already. Chances that some of your teammates gain anything are slim, too. And even if you do gain anything, fact is that other members/teams will have a higher chance of benefitting from you, unless you're in a team that is over half the active participants. So, you might be winning in actual points, but other teams will be winning more. So you're actually helping your opponents more than you help yourself.

Having said that, there's a loophole in that when someone reports their work in large batches (like 10 WU's). In that case, 9 out of the 10 would benefit (assuming that no ther WU's are sent by other members inbetween yours). Still, much more than 9 following your contribution would benefit....

Besides, your reasoning goes for the current system as well - and more so, because you gain immediately no matter what the effect on your next or teammate's WU.

Trog Dog, for someone to do anything, there has to be a motivation to do so. If someone hasn't already switched to using an optimized boinc core client, when you actually got whatever you claimed, then I don't think there's much motivation to switch to one now. 90% + of the active attached hosts are using standard boinc clients. Remember only the first few results returned of a new wu could be granted substantially higher claims, even when averaging. I doubt there's much incentive to switch to one now.

Yes, this might be a loop hole, but it's a SMALL one that might be exploited. Should it be addressed/considered? Yes I don't think it's much to get worried over though.

In Ralph, we discussed "cherry picking", however, from my own results I see no way that I could pick and choose which gave more. I think by the time enough results come in that "cherry Picking" might be possible, they'd be issuing a different wu and it wouldn't matter.

Looking at your post, there might be a very easy solution : people get the running average, BEFORE their claim is taken into account. This would make it useless to overclaim, in fact it would NOT give you more credits, but it WOULD give more credits to those that report WU's after yours. How's that for discouraging optimized clients? You would only benefit from overclaiming if you were actually the first to report a certain WU (what are the odds?). In all other cases, overclaiming would give more credits to everyone behind you - but not yourself, thus you would not get higher in the ranking - the opposite would be true.


Example : first guy reports, claims and gets 100 credits. You report, claiming 300, getting 100, setting the running average to 200. Third guy reports, claims 100, and gets 200, running average goes down to 166, etc....

Hi TrogDog,

David Kim mentioned in a deleted thread, that he is able to spot grossly overclaiming hosts, flag them, exclude them from the credit calculation and award them a low 2 credits/model ratio. That would at least solve the problem of manually edited XML-files.

For optimized clients which overclaim modest (within 500% of the standard client) your conclusions are right theoretically but the question is how it will affect reality in practice. I think Rosetta is big enough that overclaiming hosts are in the minority and don't really affect the granted credit much, if compared to the whole user base. The incentive to use the optimized client is also minimized, while it will push up the granted credit for all gradually it won't give you an edge over the competition. But your reasoning is yet another argument to wait with establishing the credit/model ratio until many different hosts have returned results.