Dpc Responds

[DDTUNG]

Where to start, where to start…
Greetings from a DPC’er (not ICA, not even D2OL) and congrats with the first place. Well done.
I got personally interested in this cheat-story, so this is by no means official DPC stuff. I have read both DPC and XS forums regarding this.
May I give a recap on this thread?

First it was the one node, which got explained by XS members themselves. Your current #4 member Windforce, also uses 1 node I noticed, (link) and with that many candidates I speculate that he/she also uses more than 1 puter. If so, maybe Windforce can further explain you the bennies of using 1 node.

Then it was the question of the number of PCs involved; this was answered.
DDTUNG then asked the question: then why only 700,000 candies when they could have produced so much more in that time?
While your math is ok, you reasoning is based upon these PCs are crunching 24/7. Ergo…
Plus, if it was cheating, why then stop? Why not keep it going to keep ahead of you? Like it was stated by ICA, their goal was to keep DPC at #1 for 2005. All of DPC knew we were losing this one. As it was, DPC barely reached #1 2005, I think a couple of hours in the new year and you passed us.

Then the rather silly remarks about why hoarding the cands and copying of nodes, it must be cheating right?
I’m afraid this is somewhat of a culture clash. As has been explained by Floppus (page 2, link) but sadly not posted here by Entity_Razer, I’ll quote


I hope this sheds some light on the background of the why.

Now, sadly, which is probably also one of the reasons most teams regard D2OL as a dead project, D2OL organization is not able to check if people cheat or not (link). This also ties in with DDTUNG’s request to send all result files to Charles. If Charles can’t determine cheating in the uploaded files, he will also not be able to to determine this in the files ICA would send. They’re the same right?

One thing I do find encouraging of DDTUNG’s request is that he acknowledges that ONLY D2OL can prove cheating. So why not direct your time and energy to push D2OL into enabling detection of resent buffers.

That leaves the docking time. Wake up those math skills ;-)
First, it’s not the most stable parameter in D2OL, to say the least. Several people on this thread have given plausible ways of showing docking time is as reliable as the weather forecast. I find it a bit disappointing (or maybe you did not read it) that you did not respond to Lo$t PrOPhEt, mad mikee and Bloody_sorcerer on this thread. All show simple examples of how docking time means nothing (respectively, responses 14, 26 and 49).

AVERAGE docking time it is, right? So the the time needed to crunch them divided by the number of candidates.
Lets start an new account: 0 candidates
Suppose you have a buffer of 2,000 candidates with total dock time 30,000 minutes: upload it
Your results would be 2000 candidates, total dock time 30,000 minutes, average docking time 15 minutes.

Let’s go cheat and upload the same buffer which contains 2,000 candidates with total dock time 30,000.
Your results will now be 4000 candidates, total dock time 60,000 minutes, average docking time 15 minutes.

So reloading buffers will NOT shorten your average dock time.

If you look at the D2OL stats pages, the average dock time of a member is plainly calculated by dividing the the total dock time by the number of candidates. As the number of candidates can be checked, the wobbly number here is the time.
You want to know how wobbly?
Take 100,000 candidates, of which 99,999 have average crunch time of 15 minutes
That’s 1499985 minutes
Take ONE PC with similar crunch power (so 15 minutes per candidate) and let it crunch the remaining candidate but set the systemclock back one year. Yes I know it’s ridiculous, but for this example it’s valid.
365 x 24 x 60 = 525600 minutes. So the total dock time for this candidate is -525600 + 15 (actual crunching)
So – 525585.
Upload your results: What does D2OL get?
100,000 candidates with total docking time 1499985 – 525585 = 974400 minutes.

This makes average docking time 974400 / 100,000 = 9.744 minutes.

Hardware docking time: 15 minutes.
D2OL docking time (due to ONE candidate): 7 minutes 45 seconds.

Can you at least IMAGINE that D2OL docking time is NO proof whatsoever?

I’ll finish by saying to DDTUNG that I hope what you stated on the Free-DC forum was in jest (link) , because I think the crunch power you have can be put to very good use, and it will be a loss if you decided to retire from DC.

Any flaws in reasoning are enterily on my account, and are mostly due to lack of coffee.

Which i will now get.

Thank you for your rather logical reply which befits your username.

You will note that I have made my own analysis of the advantages as well as the disadvantages of using one common node, elsewhere herein, and this point was not my primary complaint.

In my paragraph regarding the number of PCs used, I estimated the plausible range of outputs from 150 P4 3.0 machines for a period of 75 days, without taking into account those of the 600 acknowledgedly slower machines run for a much shorter period of time. That showed the actual output of 700,000 was within the plausible range, a scenario well explained by your suggestion that the PCs might not have been used full time. What I contended as inconceivable was that somehow these PCs, under the circumstances, produced sets of results which invariably ended in multiples of 10. Yes, at least 750 sets, plus all the completed 2000 cands sets, ending almost all in 0.

Why stop? Because they had already achieved their stated goal, and to continue much further after I had cried foul and attracted the attention of the DC community would have been too risky. This is of course only my personal contention.

At no point in my analysis did I suggest that uploading the same resultQueue.dat more than once would decrease the average docking time. What I did suspect, and still do, is that the sets of results which were uploaded were produced on a faster machine than the P4 3.0 claimed.

Now we come to the arithmetic part. If you make the very, very reasonable assumption based on the fact that the 700,000 cands were produced by around 700 machines, an average of 1000 or more cands were produced per machine(to give ICA_COWS the benefit of the doubt), since some of them were slower and also used for much shorter time, you will have the following results:

Take 700,000 cands, of which 690,000 had average docking time of 15 minutes. That's 10,350,000 minutes

Your other machine, with its clock set back 1 year, average docking time of 15 minutes, and 1,000 candidates crunched, would give a figure of -510,600 minutes using your same calculations.

That would have given 9,839,400 minutes, or an average of 14.05 minutes.

Sir, it was a valiant effort, but you have illustrated a hypothetical situation which was clearly designed to be overwhelmingly in your favor, but wholly unrealistic, and flawed. Unfortunately you have met your intellectual match.

DDTUNG