1) Message boards : News : Status 12th August (Message 24578)
Posted 12 Aug 2012 by Mad_Max
Hmm... Yes, seems my short deadline WU is resend. But i do not see why it was sent to me? - this WU have 2 good result already. I am 3rd.
If second result was reported after deadline(and after resend to me), then BOINC usual mark such tasks as "too late to validate". But it marked OK now...

it low credit too: ~40 hours - 260 Cr
2) Message boards : News : Status 12th August (Message 24571)
Posted 12 Aug 2012 by Mad_Max
Think i get one of this "long units with low credits" too:
42 hours @ 3.5 Ghz Phenom II and 316 Cr (~3 times lover if compare to average from "normal" relative short WUs)
and second long WU is running right now (~40 hours too)

No problem for me if it just 1 or 2 Wus. But certainly better to fix it.

And one more - this long Wus have much shorter deadlines than short WU.
So they run in high priority mode.
This is by design or a glitch?
3) Message boards : News : Server status (Message 24404)
Posted 21 Jul 2012 by Mad_Max
2 Eric Mcintosh

What "PNI" version means? Generec (non-optimized, standart x87 FPU)?
If so - then what is the difference from the normal version (without specifying a modification) and "PNI" version?

I get a wild mix of versions - simple, "PNI" and "SSE2".
http://lhcathomeclassic.cern.ch/sixtrack/results.php?userid=193270SixTrack v444.01
SixTrack v444.01 (pni)
SixTrack v444.01 (sse2)

In general all except correct for my CPU - SSE3 :)
The problem with the work of SSE3 code on AMD CPU has not been solved yet?
(My main CPU AMD Phenom II X6)
If so sheduler must send SSE2 - it work and validate OK. Why it mix versions?

Speed comparation of versions (actualy not speed but Cr/hour ratio, but i read before that credits in project are awarded now in proportion to the volume of real work done, not the CPU time * CPU benchmark)

standart 22.7 Cr/h (hour = CPU time, not runtime)
PNI - 34.08 (average from last 9 tasks, 126k sec total)
SSE2 - 37.71 (average from last 6 tasks, 42k sec total)
4) Message boards : Number crunching : Faulty Computers or Modified BOINC ?? Huge Credits (Message 23840)
Posted 14 Jan 2012 by Mad_Max
That's right, it all is these. Barton's "сheat" machine produced 4 "cheat" WUs, these 4 users were affected as wingmans on these 4 WU.

The exact excess CR values ​​are(based on WUs data recorded in this post: http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3400&nowrap=true#23722 + boincstats.com):
wdsmia - not sure cuz exact value not recorded, estimate is near 515k (533k @ cheat day minus ~15-20k normal CR/day in november for this user)
Galeon 7 - 406,388
MrOctane - 983,069
Jnargus - 615,194

By the way what happened in the project 06/26/2007 (or may be day before - 06/25/2007)? When checking the statistics, noted that almost all the "old" users (who was involved in the project at this time) have abnormal large results for that day.
5) Message boards : Number crunching : Faulty Computers or Modified BOINC ?? Huge Credits (Message 23835)
Posted 11 Jan 2012 by Mad_Max
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

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.
6) Message boards : Number crunching : Faulty Computers or Modified BOINC ?? Huge Credits (Message 23834)
Posted 11 Jan 2012 by Mad_Max
Igor Zacharov
А почему не использовать идею которую тут уже высказывали раньше - просто пометить все задания с завышенными кредитами (их не много, всего около десятка по обеим эпизодам как я понимаю) как сбойные(например не прошедшие валидацию)?
Что должно привести в том числе к обнулению зачисленных кредитов по этим заданиям всем участвовавшим в кворуме штатным методом (стандартными серверными скриптами BOINC) без "ручной" правки базы данных с риском повредить структуру данных.
Побочным эффектом будет повторная высылка и расчет этих заданий, но т.к. таких заданий мало потери процессорного времени несущественные.

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

©2022 CERN