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...
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).
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...
Boincstats nie łapie wszystkich projektów...
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.
Zatem pewnie się mylę, ale i tak sobie posprawdzam ;)
Cytatosoby, które do nas przeszły zostawiają punkty w swoich starych zespołach
to wg mnie jest główna przyczyna
Ale to działa i w drugą stronę...
I tam - ilość osób które do nas przeszły jest większa niż tych którzy odeszli.... :deadman:
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...
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.
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)
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.
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ę? :)
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.
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
@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:
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
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.
@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 (http://www.boincatpoland.org/smf/projekt-miesiaca/jak-sa-sprawdzane-punkty-w-projekcie-miesiaca/msg63977/#msg63977)
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";
?>
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.
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/ (http://tibleiz.net/asm-xml/)
czysty asembler, mocno ograniczone funkcjonalnie
Jak ktoś zna odrobinę C++, to http://rapidxml.sourceforge.net (http://rapidxml.sourceforge.net)
Wyniki testów
http://xmlbench.sourceforge.net/results/benchmark200910/index.html (http://xmlbench.sourceforge.net/results/benchmark200910/index.html)
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...
niech nie naprawiaja to zobaczymy ile osob liczy dla pkt a ile dla ideii :)
Pewnie ostro "przeczesałoby" szeregi liczydłowych :)
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
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: