Punkty wg BOINCStats

Zaczęty przez krzyszp, 12 Grudzień 2010, 17:36

krzyszp

Zaciekawiony rozbieżnościami punktów jakie otrzymuję z serwerów, a tym co podaje BOINCStats zajrzałem na ten ostatni i nieźle się zdziwiłem...
Policzyłem średnią ilość punktów otrzymywanych przez naszych liczydłowych dziennie (dla pierwszej 30-tki) i wyszło mi 8'167'799, zaś BOINCStats podaje, że mamy ogółem 3,913,336,518.48 punktów i rac na poziomie 11,264,506.39835 punktów...

Z tego wychodzi, że cały nasz dorobek punktów uzyskaliśmy w ok. rok... Cosik nie wydaje mi się to prawidłowe...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

lolek

Nie wiem jakie są różnice pomiędzy statystykami z serwerów a tymi z BS ale co do RACu teamu i jego total kredyt to przypominam że BS RAC jest średnią z iluś tam dni (coś mi się kojarzy o 60). W tym przypadku dzielenie całego dorobku drużyny przez obecny RAC jest bez sensu. Np. według BS w październiku oscylował on okołu 9 mln, teraz około 12, x miesięcy temu wynosił on y. Żeby tego typu obliczenia miały sens trzeba by porównać RAC, a jeszcze lepiej BS RAC ze wszystkich dni i wyciągnąć średnią. I dopiero wtedy dzielić nasz dorobek przez RAC (BS RAC).

krzyszp

Nie chodzi mi o dokładne wyliczenie, ale o sam rząd wielkości...
Drużyna istnieje już ponad 5 lat, nawet uwzględniając, że RAC rośnie z każdym miesiącem, to i tak wyniki są "dziwne" (te podane przez boincstats).
Zwróciłem na to uwagę, widząc dane z dziennych utargów naszej drużyny, pobierane z serwera...
Jedynym wytłumaczeniem dla mnie jest błąd w skrypcie (gdzieś np. punkty są mnożone), lub złe wyliczenia na boincstats. Sam fakt, że czołowa 30-tka nabija 8 mln punktów (brałem pod uwagę średnią ich punktów - nie ostatni dzień), to pozostałych 6400 też powinno nabijać więcej niż 4 mln...

Po zastanowieniu jednak myślę, że mamy błąd w skrypcie, niemniej dalej wyniki raportowane przez boincstats są wg mnie zaniżane i stawiałbym na kilka milionów dziennie...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

Troll81

Boincstats nie łapie wszystkich projektów...

tito

Cytat: krzyszp w 12 Grudzień 2010, 17:36
Zaciekawiony rozbieżnościami punktów jakie otrzymuję z serwerów, a tym co podaje BOINCStats zajrzałem na ten ostatni i nieźle się zdziwiłem...
Policzyłem średnią ilość punktów otrzymywanych przez naszych liczydłowych dziennie (dla pierwszej 30-tki) i wyszło mi 8'167'799, zaś BOINCStats podaje, że mamy ogółem 3,913,336,518.48 punktów i rac na poziomie 11,264,506.39835 punktów...

Z tego wychodzi, że cały nasz dorobek punktów uzyskaliśmy w ok. rok... Cosik nie wydaje mi się to prawidłowe...

Popatrz na wykres "total credits, last months" - widać, że gwałtowny skok RAC nastąpił około lutego tego roku. Wcześniej przyrosty były niewielkie, a do 02.2009 było w ogóle cieniutko. Do tego wykres "RAC last 60 days" w ciągu 2 miesięcy RAC zwiększył się o 2kk.
Do tego nowe osoby, które do nas przeszły zostawiają punkty w swoich starych zespołach. Dlatego suma punktów poszczególnych liczydłowych nie równa się total B@P.
Dla mnie wygląda OK.

krzyszp

Zatem pewnie się mylę, ale i tak sobie posprawdzam ;)

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

Troll81

Cytatosoby, które do nas przeszły zostawiają punkty w swoich starych zespołach

to wg mnie jest główna przyczyna

krzyszp

Ale to działa i w drugą stronę...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

tito

I tam - ilość osób które do nas przeszły jest większa niż tych którzy odeszli.... :deadman:

krzyszp

Niemniej, mam powód aby dokładnie sprawdzić wszystkie skrypty, gdyż na dzień dzisiejszy rozbieżności między tym, co ja otrzymuję a rezultatami BS są liczone w kategoriach rzędów, a nie setek tysięcy punktów...
Na tę chwilę zakładam, że to JA robię gdzieś błąd, niestety, ale program pod windę (przypominam - parsuje ok. 12GB danych) nie wyrabia się w realnym czasie (a nie mam pod ręką silniejszej maszyny z WinXP), a wyników działania skryptu pod linuksem jeszcze nie rozspracowałem pod względem "wyłuskania" właściwych wartości (aczkolwiek czekam na wolne popołudnie, żeby do tego przysiąść).

Dodatkowym problemem jest fakt, że BS nie ściąga danych ze wszystkich aktywnych projektów (a my tak), co również powoduje rozbieżności w wynikach...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

TJM

Krótka piłka - pomijając nieaktywne projekty, suma punktów z BS musi się równać sumie punktów z eksportów projektów - niezależnie od jakichkolwiek dodatkowych obliczeń, RACu itp jest to eksportowane i uaktualniane co najmniej raz dziennie przez projekty. Jeśli punktów wychodzi za mało, pewnie skrypt przedwcześnie przerywa działanie.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

krzyszp

Cytat: TJM w 13 Grudzień 2010, 12:38Jeśli punktów wychodzi za mało, pewnie skrypt przedwcześnie przerywa działanie.
Cały problem polega na tym, że mi tych punktów wychodzi za dużo ;)
Np BS podaje, że wczoraj mieliśmy 294,824,499.22 punktów w Seti, a wg aktualizacji z projektu mieliśmy 344,532,243.23, przy czym zaznaczam, że nie wszystkie nasze punkty zostały dodane do bazy (program nie wyrobił się przed następną aktualizacją).

Sprawdziłem WCG:
BS podaje 108,650,416.19
Serwer projektu 113,676,785.16 (dane za wczoraj)

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

TJM

BS w tym wypadku podaje dobrze, bo mniej więcej to samo jest w XMLu - 
<name>BOINC@Poland</name>
<userid>8899113</userid>
<total_credit>294824499.220873</total_credit>

Zaraz zobaczę ile mi wyjdzie z obliczeń, ja mam prosty skrypt w php.


W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

krzyszp

Cytat: TJM w 13 Grudzień 2010, 13:07
BS w tym wypadku podaje dobrze, bo mniej więcej to samo jest w XMLu - 
<name>BOINC@Poland</name>
<userid>8899113</userid>
<total_credit>294824499.220873</total_credit>
I tu jest pies pogrzebany... Wziąłeś xml'a z teams.gz?
Ja wyliczam punkty z user.gz....

Cytatja mam prosty skrypt w php

Podzielisz się? :)

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

TJM

#14
To dziwne, bo przy zliczaniu po team_id z tabeli user też wychodzi mi 344 z hakiem, z aktualnego eksportu 344,85.
Wygląda mi to na jakieś błędy parsowania przy polach z dziwną zawartością, jak będę miał chwilę zrzucę całe wyjście ze skryptu do pliku tekstowego i zobaczę w którym miejscu coś się sypie. Czasami są po prostu takie kwiatki:

19279.658802 30201.
7028.431997 30187.
29243.664361 110071.
18867.289227..
4821234.709072 101566.
405960.992128 le/>
.
582542.855030..
38768.314728 /</url.
2052542.786608 30189.
1619469.815344 30225.
710115.773679 30190.
719570.219514 30300.


gdzie pierwsza kolumna to liczba kredytów, druga id teamu.


W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

Faktycznie dziwna ta "dysproporcja" między total_credit z tabeli team.xml a sumą punktów z tabeli user.xml

                        WCG                        Seti
team               108 715 630.67      294 824 499.22
suma z users   113 714 720.90      344 817 884.22

RAD-Poland

@buninek

spodziewałem się większej dysproporcji w końcu więcej użytkowników przybywa niż ubywa + fuzje
suma user nie będzie się równać wartości team a z czasem wręcz powiększać

punkty zdobyte przez user po przyłączeniu się do drużyny nie przechodzą do team, od tego momentu nowo zdobyte są doliczane do team, a jedynie user ma wszystkie zdobyte przez siebie punkty

wyjątkiem jest bodajże climateprediction.net gdzie punkty w całości wędrują za użytkownikiem do drużyny

EDIT: ups - sorki ale to już było wyżej w postach  :shame:

   
WCG:
PG:         YOYO:

     

buninek

Zgadza się to dokładnie. Dzięki za precyzyjne wyjaśnienie.

climateprediction.net
team.xml         77 335 392.54
suma z users.xml   77 335 911.03

TJM

Trochę lipna kwestia, bo w tym układzie nie ma jak sprawdzić czy skrypt dobrze działa. Mój jest prosty - ręczne wyszukiwanie rekordów po tagach i przesuwanie/doczytywanie pliku, a mimo to czasami coś mu odbija.
Skrypt oparty o wbudowane w PHP funkcje parsowania XML bez dodatkowego wspomagania nie działa w ogóle.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

RAD-Poland

#19
@TJM

nie wiem czego używałeś w PHP, ale najprostsze funkcje to
simplexml_load_file lub simplexml_load_string

if (file_exists($file_user))$xml = simplexml_load_file($file_user);
lub jeśli masz wczytane dane
$xml = simplexml_load_string ($dane);

jeśli spakowany plik
<?php
$max_lenght_file
=...;

if(
$fp=gzopen("$dir$filename","r"))
{
$file_binary=gzread($fp,$max_lenght_file);
gzclose($fp);
$xml simplexml_load_string($file_binary);
}
else exit("Błąd otwarcia pliku.\r\n");
?>


przy dużych plikach funkcje simplexml są bardzo pamięciożerne ~3 x wielkość pliku
jeśli to byłyby duże pliki to jeszcze będziesz musiał zmienić ograniczenia w samym pliku konfiguracyjnym php
dlatego obecnie stosuję już przeczyszczoną bazę user.gz
patrz -> skrypty by @buninek

wygląda to mniej więcej tak

<?php
$dir
=...;
$filename=...;
$team_id=...;

if(
file_exists("$dir$filename"))
{
$dane=shell_exec ('zcat ' $dir $filename ' | grep -v -E "^ <url>|^ <has_profile" | grep -B 9 -A 1 "^ <teamid>' $team_id '</teamid>" | grep -v "^--"');
$xml simplexml_load_string ("<users>$dane</users>");
}
else exit("Błąd otwarcia pliku.\r\n");
?>


potem wrzuć jakąś pętlę sumującą


<?php
$suma
=0;
foreach (
$xml->user as $val)
$suma=$suma+"$val->total_credit";
?>


jeśli test robisz jednorazowo lub dla małych plików możesz wczytać cały plik
przy częstym używaniu, poczytaj o szybszych sposobach czyszczenia w podanym wyżej temacie buninek podał wiele przykładów  :parrrty:

EDIT: dziwnie silnik forum koloruje kod php, brak pełnego wsparcia niektóre zmienne $... w "" wyglądają jak tekst

EDIT2: jeśli zdecydujesz się na cały plik to musisz sprawdzać team
<?php
foreach ($xml->user as $val
if ($val->teamid==$team_id$suma=$suma+"$val->total_credit";
?>

   
WCG:
PG:         YOYO:

     

TJM

U mnie ciężko inaczej niż tak:


$nazwa_pliku = "/tmp/user.gz";
$uchwyt = fopen($nazwa_pliku, "r");
while (!feof($uchwyt)) {
    if (strlen($tresc) < 64 *1024) {
<------>$tresc .= fread($uchwyt, 8 * 1024);
<------>$nbytes_read += 8192
    }
    $pos1 = strpos($tresc,"<user>") + 6;
    $pos2 = strpos($tresc,"</user>");
    $user_field = substr($tresc,$pos1,$pos2-$pos1);
    $tresc = substr($tresc,$pos2+2);
    if (strpos($user_field,"<total_credit>") > 1 AND strpos($user_field,"</total_credit>") > strpos($user_field,"<total_credit>")) {
<------>$pos1 = strpos($user_field,"<total_credit>") + 14;
<------>$pos2 = strpos($user_field,"</total_credit>");
<------>$credits_str = substr($user_field,$pos1,$pos2-$pos1);
<------>if (strpos($user_field,"<teamid>") > 1 AND strpos($user_field,"</teamid>") > strpos($user_field,"<teamid>")) {
<------>    $pos4 = strpos($user_field,"<teamid>") + 8;
<------>    $pos5 = strpos($user_field,"</teamid>");
<------>$team_id = substr($user_field,$pos4,$pos5-$pos4);
<------>}
<------>else {
<------>    $team_id = 0;
<------>}
<------>if ($team_id == 30228) {
    <-->    echo "$credits_str \n";
    <-->    $total_credit += $credits_str;
<------>}
    }
}
echo "$total_credit \n";
fclose($uchwyt);


Oczywiście to taki sobie szkielet zrobiony na kolanie, ale działa szybko (30s czas parsowania dla exportu SETI) i wymagania pamięciowe są minimalne (<1M).
Spokojnie można go rozszerzać o czytanie dowolnych innych pól.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

#21
Prosty sposób na weryfikację z użyciem tylko grepa.
W porównaniu z cgrepem dużo wolniejszy.
przykład dla seti
gzip -cd user.gz | grep -E '^ <total_credit>|^ <teamid>30228</teamid>$' | grep -B1 '<teamid>30228</teamid>$' | grep -E -o '[0-9]{1,}\.[0-9]{1,}'

zsumować kolumnę
... | paste -sd+ | bc
EDIT:
Cytat: RAD-Poland w 13 Grudzień 2010, 17:55
przy dużych plikach funkcje simplexml są bardzo pamięciożerne ~3 x wielkość pliku
jeśli to byłyby duże pliki to jeszcze będziesz musiał zmienić ograniczenia w samym pliku konfiguracyjnym php
To specyfika XML-a. Musi być załadowany w całosći do pamięci. Wystarczy taki ogromniasty plik podzielić na  mniejsze części.
Z bardzo szybkich narzędzi do parsowania jest http://tibleiz.net/asm-xml/
czysty asembler, mocno ograniczone funkcjonalnie
Jak ktoś zna odrobinę C++, to http://rapidxml.sourceforge.net

Wyniki testów
http://xmlbench.sourceforge.net/results/benchmark200910/index.html

simonic

Dzisiaj problem z rozbieżnościami między ilością punktów, RACem i innymi całkowicie "został" rozwiązany :) Po prostu każdy zdobył od wczoraj 0 (słownie:zero) punktów :) Mam nadzieje ze to szybko naprawia...


Tomasz R. Gwiazda

niech nie naprawiaja to zobaczymy ile osob liczy dla pkt a ile dla ideii :)

simonic

Pewnie ostro "przeczesałoby" szeregi liczydłowych :)


Tomasz R. Gwiazda

tutaj napisze bo chyba blisko...

czy cos sie zmienilo w godzinie aktualizacji statystyk na Boincstats ? (zwykle po 18:00 byly dzienne statystyki)
a drugi dzien z rzedu cos ich nie ma

WUPES

Cytat: Tomasz R. Gwiazda w 25 Luty 2011, 22:13
niech nie naprawiaja to zobaczymy ile osob liczy dla pkt a ile dla ideii :)
hm...  może ciekawa była by statystyka od kiedy ...  nie ukrywam że ja licze na czołowe miejsce w takiej statystyce bo SETI dla ideii liczę od baardzo dawna...  punktów co prawda przybywa niewiele - ale satysfakcja jest  :boing: