what did i miss ?
anyway, nice effort there Team XS![]()
what did i miss ?
anyway, nice effort there Team XS![]()
thx for the edit victor
i was speaking for myself and i dont want to insult anybody or accuse anybody of cheating, i was just commenting on the possibility of a project run to help humanity eventually beeing cheated on for fame.
wich is a very weird idea...
I know, saaya. But just in case you did, I had your rear covered.Originally Posted by saaya
![]()
DDTUNG![]()
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
You just read what you want to read DDTUNG. I am not saying I support this, neither do I know if they did this, I am just telling you that the average docking time does not seem to be a 100% reliable figure, since it is possible to influence it, like it the example of changing the time.Originally Posted by DDTUNG
Founder of [DPC]NoizyCows
It's not that it CAN be done to influence the times, the question is why would anyone in their right mind DO so unless they were trying to hide something else!Originally Posted by ParaNoiMia
This whole deal has stunk. The hoarding of the cands,the copying of nodes, all of it. Why the hell not crunch it, up it and if you got more than the other team great, if not congratulate them and get on with life!
Do it clean and then there are no questions!
Sir, you are certainly entitled to your opinion and theories, and the rest of the world can form theirs about what you are saying.Originally Posted by ParaNoiMia
I stand firm on my statement about average docking times for those who play by the rules. For those who don't, that is a whole different story.
DDTUNG![]()
Last edited by DDTUNG; 01-02-2006 at 01:54 AM.
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
yeah, thanks a lotOriginally Posted by DDTUNG
well it all sums up from what ive seen, its not only the docking time.Originally Posted by ParaNoiMia
and i dont think victor only sees what he wants to see, but hes looking at things from a certain point of view.
its just a theory and he never claimed its true, neither did i and most other people.
there are many ways to look at things, the more complex the situation the more ways of lookng at the situation may appear true and even be true.
victor and other people are just pointing out that from the details we know its possible to have a credible theory saying dpc cheated.
thats why he is requesting more details to either proof the theory or remove all doubts that the theory is wrong.
the credibility of dpc is already in question and was harmed, not intentially from what i can see though, so i dont understand why dpc doesnt provide more details to clear up the situation and restore their credibility.
well, there are some weird and shady things that result of tactics that teams use to secretly buffr some points and later unleash them all of a sudden, its part of the game, and actually the only way of making this game more fun, as a steady output is rather boring.Originally Posted by Movieman
but i do agree that there are several thigs that are dont make sense, simple tactics and buffering points dosnt explain what and how they did what they did, at least from my understanding of the situation.
but maybe its all just a solution that resulted of people beeing lazy and sticking to a method even if it doesnt make sense or actually creates more work over time... thats how humans are
humans dont make sense
but as i said, i dont understand why dpc doesnt cooperate to clear up the situation![]()
My feelings exactly.Originally Posted by saaya
I know that if I were buffering all these cands and had all these resultQueue.dat files copied to one computer to upload, then someone came around and accused me of cheating, I would just send the entire folder of files to Charles to prove my innocence, then instruct my attorney to sue
their axx off.
DDTUNG![]()
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
hahaha lol@ attorney![]()
this just gets stranger and stranger. It seems that ICA really isn't responding but other cows are speaking of wild tangents of what might have occured. One thing is about changing the clock of a pc. For the most part of the world everyone supports a form of Daylight savings time. So that shoudl put everyone on equal footing. Why on earth would to set 100's of office computers back 1 YEAR!?! or something even close. This whole thing stinks, there are too many what if's and what about's. What we are getting is an attempt to divert attention and discredit the possibility of some wrong doing.
All we want is the truth and all we are getting right now is excuses and what if's. After all we are giving you the benefit of the doubt, but your responses don't bring a favorable light to you. Stop "beating around the bush" and get to the heart of the matter. As this is tainting the whole project for many people.
*DISCLAIMER* this has been a commentary by Weaz and by no means is supported by XS or any members or bodies there of. The word "WE" refers to the D2OL community at large and the words "ICA", "YOU" and "cows" refer to members of the Dutch Power Cows.
PEE 840@3.7hz 1.4v
P5WD2 Premium
Corsair 8000UL @ DDR833 4-3-2-9 2.1v
2- XFX 6800GT
PC Power and Cooling 1k
heater918;InSanCen;mad mikee;moddolicous;perkam;[KoG]^weaZel;charlie;
WesM63;DAK1640;Daved+;AlGore;wjd0724;Icy;MrBigShot ;mag|c;Gearhead
>>> Brave words. I've heard them before, from thousands of species across thousands of worlds, but now, they are all assimilated. <<<
I think nobody will change the system clock all the time on all computers to get a lower average dockinging time. Also i don't know much about ICA, but i just gave the example to let you guys see that the average dockinging time says nothing.
its just a possible thingthat could have been happend. It also happend to me that I installed wndows on a computer, started d2ol and saw later that the system clock was some months different. So i set it back and later i saw that my average was -16min.
What if the system clock of 1 pc of their pc's was 1 or 2 years different and the set it back to the good year?
Then their average of that node will drop very much.
It's just a possible thing what also happend to me (thats why i know it can). I don't know if something like his happend, but very strange isn't this theory![]()
Proud member of the Dutch power Cows
Let's just say for a minute that your theory is possible. Then with 149 other PCS with an average of 15 to 20, and 1 with -16 like yours, the new average becomes 14.89 to 19.89. Nowhere near 12. Are you happy now?Originally Posted by emphasis
DDTUNG![]()
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
as far as the whole docking time thing goes, if the computers were set up in a lab at a school or something like that and if they were bought all at the same time it is very possible that the battieries died in them. I used to see whole labs at my HS with bad clocks cuz the network admin was to lazy to open up every computer to give ppl the right date, when the date matters little for email and web surfing.
I dont know enough of what is going on to really have an opinion on the whole cheating thing, but from what i have read it seems very fishy that ICA refuses to even offer a responce to our questions. I mean pride is one thing, but sometimes you just have to come out and explain yourself.
EVGA 780i SLI
Intel Q6600 @ 3.6 on Water
8GB Corsair DDR2-1066 5-5-5-15
2x GTX 260 SLI + 8800GTS 640 PHYSx
Corsair 1000W PSU
Antec 1200
1TB Seagate
Setting time back on the computers come on! Does that even work?Originally Posted by DDTUNG
I know resubmitting candidates affects dock time ...... I crunched 2000 (under a different accout BTW) and resubmitted the candidates ..... the dock time went down significatly from 10 seconds to 8 seconds. It was an old node with my a64 @ 2.7 ghz ...... used to have a p4 @ 2.8ghz. The p4 I believe was at a high 12 / 13 .... the athlon 64 made it go down to a low 10.
Has anyone answered why the best candidate is A) So old (4/27/05) B) So poor (-17 )? There are people who have done 1 / 10 ICA cows have done that and have much found better cnadidates.
Last edited by UCmajewski; 01-02-2006 at 07:44 PM.
could it be that the d2ol servers were down for registrations so thats why they coppied the same node folder over and over?
thats what they did right?
sorry if i got it wrong, just thougt the d2ol servers beeing down might explain some of what they did
I thought about this also but look at the age of this node and the amount thats been upped on it by ICA...Doesn't add up!Originally Posted by saaya
![]()
It's more like someone or a group of someones has a system in place where this one node just keeps being copied and copied ad nauseum
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.….If there is someone who should know about the possibilities to cheat, it should be the organization (or it would be very sad indeed). Only they have insight into all data, and have ways to detect cheaters. Accusations can be made by everyone, but only the organization will have the proof using the uploaded results. Not to offend you (edit Bio1ogics, this was in answer to XS_Duc), but I find it incredible that you’re seriously suggesting posting a list of hardware is a sufficient way of checking…
…I can assure you that it is extremely (edit Bio1ogics: no pun intended) hard to cheat within the DPC. Because of the fierce internal competetion and tight community, stuff like sudden increases in output, spreading of clients in other software and hacks WILL be noticed. Besides this, DPC is linked to an even bigger community: someone marked as cheater here will be known by the entire Dutch DC people and also through Tweakers.net by a lot of other people.
…About the saving method, which is regarded as normal here; DPC has a pretty good reputation and history in DC. This method of saving was already applied in the first DC projects in which DPC participated (btw in which projects it was not possible to cheat using this method). People are just plainly used to do it that way. Besides this, DPC is known for its megadumps…..
To make a long story even longer, an abstract:
- Push the organization so that cheating is impossible, and remove cheaters accounts
- Be carefull with accusing people when you have no proof. This regards to calling saving-methods questionable, while that same saving-method is in the blood through historical use in other projects. Besides: if a flush-method is questionable, the projectorganization should unable that method….
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.
OK then explain this .... I used a 2000 candidate sized resultqeue crunched from an athlonXP on my athlon 64 node.Originally Posted by Bio1ogics
you can see a dock time of 8 minutes pretty quick considering this node used to have a P4 on it. I assure you the 2000 did affect its dock time.
Heres an almost virtually identical athlon 64 system
So submitting candidates under a different node will affect dock time ... It did in my case or does any else have an explanation for a -2 minute dock time?
Last edited by UCmajewski; 01-03-2006 at 03:31 AM.
Thank you for your rather logical reply which befits your username.Originally Posted by Bio1ogics
![]()
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![]()
Last edited by DDTUNG; 01-03-2006 at 04:12 AM.
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
I am not making a case that submitting candidates under a different node will affect dock time, because you have shown it will.Originally Posted by UCmajewski
Maybe I was not clear enough, but I ment to say that cheating by sending the SAME buffer two or more times will not affect the average docking time. So a short docking time does not tell anything is this regard.
But was it not claimed by members of DPC that the resultQueue.dat files were copied from the buffers of the crunching machines and then uploaded from another node?Originally Posted by Bio1ogics
DDTUNG![]()
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
duelly notedOriginally Posted by DDTUNG
It is still possibleIn 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.
They continued flushing after you cried foul.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.
Unfortunately, you have made an error: 700,000 minus 690,000 is not 1,000 but 10,000. So multiplied by ten gives -5,100,000 minutesAt 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 match.![]()
DDTUNG![]()
10,350,000 minus 5,100,000 = 5,250,000 minutes
divided by 700,000 gives 7.5 minutes.
So? It is possible, yes?
edit: btw, I did not exemplefy this as being "in my favour" . The outcome of the math holds for any number.
Last edited by Bio1ogics; 01-03-2006 at 04:20 AM.
what its the same node 117289? Those are 2 different nodes .... 2 different machines. The first one I submitted a resultqeue from a different machine(whould be the same thing as resubmitting ... ur adding 2000 that machine didnt crunch). The second machine is your standard im running d2ol 24 / 7 node never messed with.Originally Posted by Bio1ogics
We've also re submitted results and got the same result on a different account. I sent the same buffer 2 or more times same result .... it lowered dock times as well. It does lower dock times .... period! I suggest you give it a try ?
Last edited by UCmajewski; 01-03-2006 at 10:12 AM.
Interesting confession you make here, btw. You could almost call it cheating.Originally Posted by UCmajewski
Please do your math. I'll offer you two ways of explanation. First the cumbersome one:The first one I submitted a resultqeue from a different machine(whould be the same thing as resubmitting ... ur adding 2000 that machine didnt crunch).
You already had candidates and a average dock time of the "first one". You took a resultfile from a diff machine, which is ofcourse completely unequal to REsubmitting. You just upload a resultfile of a - let's say - offline machine. Of course your dock time will change! if your "first one" had average DT of 15 minutes, and your other one a different average, your new average will change. Write the numbers down and see for yourself.
Easier explanation. In the result file there must be some info for D2OL to produce stats. Besides the science beside it, the resultsfile contains the number of candidates crunched and the time the machine took to crunch them. So the average dock time WITHIN that results file is fixed. So if you would REsubmit that same result file, the ave dock time is not affected.
The thing which confuses you is that multiple result files from different machines uploaded through one node does affect ave dock time. Different machines have different dock times.
I hope I've made myself clear this time. English is not my native language so I'm sometimes struggling for words.
Thank you for pointing out an error which, when corrected, goes in my favor.Originally Posted by Bio1ogics
700,000 - 1,000 = 699,000 x 15 = 10,485,000
(365x24x60) - (1,000x15) = 510,600
That gives 10,485,000 - 510,600 = 9,974,400 / 700,000 = 14.249.
I believe that follows your method exactly and is now correct. So your statement that 'The outcome of the math holds for any number.' is fallacious.Q.E.D.![]()
DDTUNG![]()
XtremeSystems - we overclock and crunch you to the ground
I left the optimized files on three 3GHz P4 HTs. Ban me.
Bookmarks