I feel the quorum of 3 is a very effective measure against cheating. It does not stop every cheater but it's good enough. However, I think if a quorum of 2 is all that is necessary to validate results with an accuracy acceptable to the research team then it is a dreadful waste of CPU power to use a quorum of 3 just to stop cheating. There is a better way to stop cheaters.



Yes, I can list a few optimised clients as well as calibrating clients and tell you how they can be configured to be fair. I can also tell you how to configure them to cheat. But I won't say anything because I want the current benchmark based system to be thrown out as soon as possible. Recommending and promoting optimised clients (or even calibrating clients for that matter) is an influence that tends to delay the death of that stupid, useless, ill conceived and poorly implemented dinosaur called the benchmark based credit system.



It is evident that someone (either the WCG techs or the research team) can make fairly accurate estimates of the FLOPs required to crunch the WUs. Let them categorise the WUs into 2 or 3 or 4 different sizes (eg. small, medium and large) and award a fixed number of credits for each size. Obviously this would not be 100% accurate but neither is any other proposed system. All proposed credit systems, including the current benchmark based system, rely on the notion that inaccuracies will tend to average out over a large number of WUs. The system I am suggesting will average out the inaccuracy of FLOP estimation as well as any other system. And it is OS independent.



Indeed we have and I believe one of the facts that came out of that discussion was that client-side FLOP counting, though it seems like a good idea, would take a huge amount of work to implement, it might turn out to be very inaccurate and it may introduce errors into the results. I would also add that client-side FLOP counting, if it is implemented, will surely be cracked and then the cheating will start all over again. Futhermore, it is OS dependent. So let's forget about that idea once and for all.

Rosetta discarded the system they recently adopted? And what is a BY-WU predetermined credit?

FLOP counting was my suggestion, and I think I gave the cons as well as the pros. Despite the disadvantages, I see it as the only totally fair method. But for it to work, you still need a quorum. This allows you to include the FLOP count in the validation process, and discard any fake claims. This will actually give ZERO to cheaters. While there may be a few ways they could game the system to get a rare massive score (if all three quorum members are in on the game), the frequent "nil points" would discourage that.

Adding a FLOP estimation is difficult, but not impossible - although it is going to depend entirely on the project. It's not a task for code monkeys, but fortunately WCG employ nothing but code poets. I'm convinced it is possible. Not by counting every instruction, you understand, but by counting discrete chunks or function points. For example, suppose Rosetta has (I'm completely making this up) a test for total folding energy that it runs in 10 different positions for each flex of the protein... and each arm is flexed until it meets a threshold or until a maximum is reached. There will be a counter already, to prevent it from going over the maximum, so you just multiply them all together to get an estimate. This is textbook stuff. Once you have an estimate, you can validate it by correlating the estimate with the actual CPU time on a known configuration. Finally, you can convert it into Cobblestones (actually a completely precise conversion, since the Cobblestone is based on a theoretical ideal reference computer performing at 1000 MIPS).

And on the quorum theme: the quorum is guaranteed at 3 by WCG for the project scientists' benefit. This is purely about scientific rigour, not about "acceptable accuracy".

Without a way of validating the FLOP claim, I see no hope for quorum-less projects. A fixed credit eliminates credit-hounds, but not cheats. Cheaters can send in any old garbage in exchange for points. Sad but true.

Okay, took the bull by the horns, hooked up and processed a few at R@H. The end result was, that my always Stock benchmarked machine Stock WOS/Hardware, now on 5.6.0, has claimed only fractions less of the credit awards. Its next to exact money for work performed, however fast done....with a small tip.



Researched the R@H New BY-WU credit / Sliding Averaging Method, ....the algorithm they've come up with is close to non-plus-ultra ... better than lowest / highest out of WCG.....why is it that virtually always when crunching HDC i get equal or more, sometimes significant (we know the various explanations), and less on FAAH.... think latter quorum is often determined by lesser spec'd machines, which are much easier impacted during benchmarking when other activity is ongoing simultaneously......

So before i said, i'd nothing to add, well why re-invent the wheel if a solution is on offer......talk to Dr.Baker.....Mr PF. This is barring of course if the FAAH crunches particularly as a longer term project or HDC's are fundamentally different in build....then Flop counting is maybe the better thing.

As an important ingredient to those with Linux whose Whetstone's for to me unknown reason are drastically lower on benchmark, the R@H system does not favour any OS and from testimony over there, the Torvald fans are happier than before.

ciao

PS, the R@H progress profile is not much different from what we see at WCG, checkpoints and saves at material distances!

Does not work quite like that, as there is a 'decoy' (target i suppose) reference for the varying WU's.