LHC@home

Hi all,

just for clarification:
When posting the things about the "extraordinarly high" credit grants below, my intent was not to "demand" anything, but just to make my personal opinion known to the powers that be and maybe elicit any reaction whatsoever on their part.

I don´t fancy myself to be sufficiently knowledgeable about BOINC´s internal mechanics to do an analysis as to how the said credit grants occurred, or whether they were the result of deliberate cheating, accidents, bugs in the BOINC code or lightning striking a cluster of virtual Higgs bosons.

My actual concern meanwhile is that nobody "in charge" seems to be interested to the extent of responding to this thread, let alone fixing the issue.
The problem was first reported about 1.5 months ago, which should be sufficient time to show at least a sign of life on part of the admins.

I remember times when the admins of this project were a little bit more interested in the concerns of the crunchers, and it kinda saddens me that this no longer seems to be the case.
That said, I´d very much like to be disabused of this opinion.

Just my two cents ...

---

Here is another.
4 wu's all rewarded with about 6,434,800 credits. The smallest runtime is only 11 seconds!

---

Credits are like money during an inflation.The more they are the less they are worth.
Tullio

Here is another.
4 wu's all rewarded with about 6,434,800 credits. The smallest runtime is only 11 seconds!

Thats me…
Im also like WTF, yesterday i saw my stats on LHC jumping off the chart in BOINC

For clarification: I am not doing anything to provoke this on purpose.
Though I must admit my name on the first place is flattering, but it loses much of its appeal if its just a glitch.


The closest thing to an explanation I have is a wild guess that something went wrong while migrating me, since I was pretty late with realizing that much has changed with this project.

I am not deep enough into BOINC or sixtrack, so I cannot investigate this on my own, however, if someone had detailed instructions…

For the time being, I will not accept new tasks from this project.

Stelf,

The problem with your RAC and total credits is not a result of an error when migrating you to Sixtrack's new location. The problem is caused by the huge CPU times for 4 results you recently submitted. Here is a list which contains the 4 results in question, they are numbered 2159845, 2159679, 2151335 and 2139853 in the lefthand column. Those 4 tasks probably didn't even exist when you were migrated but even if they did the CPU time numbers assigned to the tasks when they were created would have been overwritten (replaced) by the CPU times reported by your computer after it finished the tasks.

I am not on a witch hunt and I am not a credit cop. I couldn't care less if you and every other Sixtrack volunteer cheats. I don't want to have you banished from the project. My purpose is to determine the facts and present them as clearly as possible in order to enlighten anybody who wishes to be enlightened about credits and credit cheating.

As I said, the CPU times recorded for the 4 results came from your computer. How do I know they are not a glitch or due to a bug? Let's define glitch and bug first. A glitch is a one time event. It happens once due to a power spike, a gamma ray penetrating your CPU/HD and altering a bit/byte and other freak accidents. A bug is an error in the logic in the software that works with the data. Let's examine glitches and bugs as they pertain to your 4 results and see if we can rule out a glitch or bug as the cause of the 4 huge CPU times.

A glitch happens in an instant and then it's gone. It's totally random and unpredictable. Can a glitch happen again later? Of course it can, it can happen any number of times BUT for a glitch to happen 4 times and to affect 4 results from Sixtrack but not results from other projects and affect ONLY the CPU times and only the CPU times for YOUR results (in the case of a glitch on the server), well, that is so statistically unlikely we can say it's impossible. Glitches are not that selective.

Could it be a bug? If it were a bug then it would be affecting *many* people's results because all of our results, not just yours, are processed by the same purportedly buggy software. Of the many thousands of results from the most recent batch of tasks, this "bug" has affected only YOUR results and ignored everybody else's results. Not only that the "bug" assigned *exactly* the same CPU time to 2 different results and very similar CPU times to the other 2 results. A bug would tend to write exactly the same CPU time for all your results or it would write totally random numbers but it's obvious that neither of those is the case. If you think so then why does it not write negative numbers and why does it not write exceedingly huge numbers?

For me, the only acceptable explanation for the 4 huge CPU times is that you altered the CPU times on your computer before they were reported to the server. It's easy to do and I've done it myself so I know it can be done. Again, I don't want to see you banished from Sixtrack and I don't even care if the project admins correct the 4 errant results.

I hope you will reverse your decision to not accept Sixtrack tasks. If you don't there is no way to investigate the issue further and no way to prove it's a glitch/bug (though IMHO it's already proven it isn't).

The statistic here is seriously damaged for 2nd time and will be destroyed at all after several coming batches. The worst thing is - the project team did nothing after 1st evidence of cheating. Crunching without statistic is the same as crunching without credits. The bitter experience of Ramsey@home shows - almost nobody will crunch such project.
Black humor. Dear friends, my big "thanks" to all of You, who cried here: "The credits are too small, we want the credit averaging".

---

jujube,

as I said, i dont know much about how Boinc and this project works, I never cared that much about it, I would not even know where to look for these values.
I cannot prove that from here, so I have to accept that Ockhams Razor is working against me.
I even agree that something must be happening on my machine, though i do not know what exact exactly.

If crunching more WUs helps to identify problem, then I wil help with that. Stopping to exploit this just seemed fair towards other credit hunters.

As no one from the Project Managment is responding here I am now denying any work from LHC. I will crunch the ones already working but will kill all waiting ones.
If they do not take their project serious why should i?

Stelf, it is nice to see You here, but, PLEASE, do not crunch additional tasks from Your machine until the problem will be found and fixed - Your computer is able to violate entire statistic here to such chaos level, which may provoke the project team to reset this statistic or drop down the credits to ZERO for all participants. This will be the greatest injustice for all of us, if this will happen.

---

Personally I joined LHC to crunch work for physics and not for credits.

As a former scientist, I want to know if the higgs boson exists or not, and if I can help the teams at LHC using our 3 computers, then it gives me immense satisfaction, to know that I have helped in my small way,to contribute to the eventual outcome of the project.

Credits are fun, but they really irrelevant to the science.

Errors do occur, cheaters and hacking unfortunately are a reality of modern day life.

The project is whats important, and getting that work crunched, for the scientists to evaluate.

Charlie,

I concur with nearly all of the things you said, and till lately this was one of my favorite projects, but:

CERN does not pay my electricity bill, I do, and I´d hope that the project administration would be so appreciative of us crunchers helping them that they would at least offer some statement whatsoever as to what their intents are regarding dealing (or even not dealing) with this issue, in other words, showing some sign of caring.

What really frustrates me is their continued silence, which could be interpreted as something netiquette prevents me from stating here, but which wouldn´t be very complimentary.

So I completely understand KidDoesCrunch´s attitude ...

---

We do have a new credit system ready which depends only on the computational characteristics of the sixtrack program. This will defeat any cheating with clock or any other way of statistics distortion - both, intentional or unitentional.

It was ready for introduction after the cheat episode last year. What prevented its introduction, is the wait for the update to the latest boinc server version, that was waiting for the verification of the executable, etc., etc.

I will decouple different dependencies and make the introduction of the new credit system the highest priority.

Thank you for making your opinion known. I appreciate the shake up.

---

skype id: igor-zacharov

Personally I joined LHC to crunch work for physics and not for credits.

As a former scientist, I want to know if the higgs boson exists or not, and if I can help the teams at LHC using our 3 computers, then it gives me immense satisfaction, to know that I have helped in my small way,to contribute to the eventual outcome of the project.

Credits are fun, but they really irrelevant to the science.

Errors do occur, cheaters and hacking unfortunately are a reality of modern day life.

The project is whats important, and getting that work crunched, for the scientists to evaluate.

And because this we just ignore that?
If they hack your bank account, it is ok when your bank ignores it? and you just pay the bills. Great.

I have a little bit different view to this. If someone is not trying everything possible to go against this then the business behind this is not serious.

Yes, credits are not that important. But anyway, I can not ignore the ignorance of the Project Managers.

We do have a new credit system ready which depends only on the computational characteristics of the sixtrack program. This will defeat any cheating with clock or any other way of statistics distortion - both, intentional or unitentional.

It was ready for introduction after the cheat episode last year. What prevented its introduction, is the wait for the update to the latest boinc server version, that was waiting for the verification of the executable, etc., etc.

I will decouple different dependencies and make the introduction of the new credit system the highest priority.

Thank you for making your opinion known. I appreciate the shake up.

Thanks Igor!
That is an acceptable explanation and I feel no longer Ignored. I feel I can continue crunching. :-)

Igor,

thanks from me too for finally responding, what you wrote sounds good to me ;-)

Nonetheless, what´s still unanswered is whether you will "correct" the unruly high credit grants that already happened (Nov 2011 and Jan 2012).

If you would be so kind as to elucidate this (one way or the other), I personally would be completely happy again ;-)))

Kind regards
Kai

---

I am very glad to see - the project team knows the problem and is ready to fix it.
Thank You, Igor, for Your reply.

---

The new credit system is in place. Will monitor how it goes.

I have corrected the host and user tables in the sixtrack data base. This is not a simple action, as this may impact the consistency of the data base. I have recalculated the value of total_credit in these two tables. If you know more places, where values should be corrected - let me know.

The correction has been done for both cheating episodes, last november and in january. However, for november I have reset only the user, who generated the huge claimed credit values. The reason not to update other host/user tables affected by the huge credit claims, is that it is not obvious how to recalculate the contributions. This is also why we did not do it immediately then. This time however, I felt that it must be done even at a risk of some inconsistencies.

I hope this will resolve the issue. Thank you.

---

skype id: igor-zacharov

Igor,

first of all, a heartfelt "Thank You!" for making the effort ;-)

The new credit system is in place. Will monitor how it goes.

I have corrected the host and user tables in the sixtrack data base. This is not a simple action, as this may impact the consistency of the data base. I have recalculated the value of total_credit in these two tables. If you know more places, where values should be corrected - let me know.

This and this workunit still seem to be unchanged.

The correction has been done for both cheating episodes, last november and in january. However, for november I have reset only the user, who generated the huge claimed credit values. The reason not to update other host/user tables affected by the huge credit claims, is that it is not obvious how to recalculate the contributions.

One idea that seems fair would be to grant the claimed credit to the users/hosts with reasonable claims.

This is also why we did not do it immediately then.

This time however, I felt that it must be done even at a risk of some inconsistencies.

I hope this will resolve the issue. Thank you.

Once again, thank you very much!

---

Igor Zacharov
А почему не использовать идею которую тут уже высказывали раньше - просто пометить все задания с завышенными кредитами (их не много, всего около десятка по обеим эпизодам как я понимаю) как сбойные(например не прошедшие валидацию)?
Что должно привести в том числе к обнулению зачисленных кредитов по этим заданиям всем участвовавшим в кворуме штатным методом (стандартными серверными скриптами BOINC) без "ручной" правки базы данных с риском повредить структуру данных.
Побочным эффектом будет повторная высылка и расчет этих заданий, но т.к. таких заданий мало потери процессорного времени несущественные.

Или с теми заниями которые уже набрали кворум и прошли валидацию это уже не срабатывает?

However, for november I have reset only the user, who generated the huge claimed credit values. The reason not to update other host/user tables affected by the huge credit claims, is that it is not obvious how to recalculate the contributions.

I have few ideas. For exaple:
Why just in this case (for users who are not involved themselves in cheating, but simply were his wingmans on same WU) do not subtract from total_credit the all result for the "failed" day? I hope they do not take offense for any loss of few tens or hundreds of CR (which they may be got for normal WUs at that day).
Or replace the results of the "cheat" day on their average day score (RAC):
new_total_credit = total_credit - cheat_day_result + RACÑ…N
(N=1 оr more if we want to see the possible small errors in calculations were in favor of the affected users, a kind of "compensation")

Who exactly was affected in November - all are listed in this thread.
Results for appropriate day can still be found in the databases. If this information is not saved in Sixtrack database, we can use third-party projects collecting and storing BOINC statistics, such as boincstats.com.
For example, user MrOctane received a huge boost in the credits, when hitting a a quorum with the "cheater" Bartonn in November 2011.
Open MrOctane's stats on boincstats.com: http://boincstats.com/stats/user_graph.php?pr=lhc&id=110149
Clearly visible the day when there was a faulty credit boost: 11/20/2011
And the number of received "abnormal" credits at this day: 983 738
Possible correction: new_total_credit = 1090135 - 983738 + 681 = 107078 Cr
Аctual cheat value in this exapmle was 983 069 (as can see in this post http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3400&nowrap=true#23722) corections so that calculations are obtained quite accurate (calculated correction is 983057)

Or instead of RACÑ…N we can use the "best day results" (with the exception of the "cheater" days - best of "normal" days):
Possible correction: new_total_credit = 1090135 - 983738 + 4513 = 110910 Cr

P.S.
If you are too busy to look through statictic for yourself, you can simply ask crunchers to help. I think there will be willing to check the statistics, and lay ready links to all of "bad" results.