E@H-Aktuální stav projektu

[vejpuste]

Nema nekdo zpravy, kdy se zase plnohodnotne rozjede Einstein?
Server_status nic, na strankach nic, ve foru jsem nic nezahlidl.
Skoda tak uspesneho projektu.
Libor

[Musacek]

Nema nekdo zpravy, kdy se zase plnohodnotne rozjede Einstein?
Server_status nic, na strankach nic, ve foru jsem nic nezahlidl.
Skoda tak uspesneho projektu.
Libor

to netusim, ale kdyz mi to hlasi project down tak po chvili(cca pulhodky) to zase beha v pohode, dneska v naprosty v pohode odeslani i prijimani dalsi prace, po vikendu jsem musel po odeslani pulhodky pockat a pak to bylo v naprosty pohode

[JardaM]

Jo, moderátoři dělají mrtvé broučky. Tak si aspoň něco přečtěte.

[Higgi]

A přece něco

February 20, 2007
Einstein@Home has been having serious problems with database server load. We are working hard to try and find the source of the problem. You will likely continue to have problems connecting to the project and may get messages like "project down" or similar until we fix the problems at our end.

Your patience and support of the project is greatly appreciated and we will try to do a better job of keeping you informed about the status of the project in the future.

[Honza]

To skorem vypada, ze uz na Einsteinu nasli, cim to je.
Budou muset projekt ruzne vypinat a zapinat, aby to dali do poradku...takze treba ted zrovna nejde.

[Garbaty John]

Tak dneska jsem se konečně dostal na stránku Server status. Snad už jim to pojede stabilně.

Zajímavý je také výpis zpráv v Boinc managerovi:

23.2.2007 22:33:56|Einstein@Home|Reporting 3 tasks
23.2.2007 22:34:01|Einstein@Home|Scheduler RPC succeeded [server version 509]
23.2.2007 22:34:01|Einstein@Home|Deferring communication for 1 min 0 sec

Toho označení Server Version jsem si dříve nevšiml. Bývalo to tam vždycky?

Edit:
Taky je změna když se stahne nová práce tak už tam není napsaná aplikace Einstein 4.24,
Ale je tam "Faster all-sky pulsar search 4.24"

[Mr4k]

To server version tam bude od nejaky verze 5.5.x, tam uz jsem to videl.

[azor666]

imho je tam jen pridana kolonka user_friendly_name nebo jak tomu rikaji. Aplikace by mela zustat stejna.

[azor666]

Bruce napsal na EAH fórum co bylo příčinou problémů.

Dear Einstein@Home volunteers and contributors,

I thought I would post a description of what went wrong and how it was fixed.

(1) Project performance problems. These were due to our database getting overloaded. It was processing an average of 950 queries per second, with peaks of up to about 3000 queries per second. Ultimately, these were due to the way that the BOINC locality scheduler works and the fact that our new analysis run did not have many low-frequency workunits. Einstein@Home is the only project that uses the locality scheduler, which is designed to send many workunits for the same data file, only sending a new data file when there is no work left for the previous data file. What happened was that many hosts that had low frequency files (because they were slower than the majority of hosts) requested work for these files, or NEW workunits also for low frequency files. When the project ran out of work for these files, the locality scheduler would then perform an extremely database intensive 'crawl' through the database looking for more work. So the slowest 20% of hosts were generating very large numbers of database queries looking for non-existent low frequency workunits. I fixed this by modifying the algorithm that searches for new work. Anyone interested in the details can look at BOINC CVS next week when I check in the modified code.

The database is now averaging about 60 to 80 queries per second, and the database server and project servers are once again snappy and responsive.

(2) File server problems. Our project uses three file servers, each of which has about 8TB of RAID-6 disk space. The file servers use Areca 24-port SATA controller cards, and Western Digital WD4000YR disks. For a number of months we have been experiencing problems in which a disk would apparently drop from the array and then reappear a few seconds later, prompting a RAID array rebuild. In the end we sent one of our server boxes (approximately 80 kg, worth about 10kUSD) by express mail to Taiwan, and the Areca engineers looked at it more closely. (Many thanks to these engineers, who have given us first-rate support!) It turned out that our problems were due to a hardware problem with the WD4000YR drives. They have a SATA interface chip which (in some revisions of the WD4000YR) is incompatible with an interface chip used on the Areca RAID controller. This incompatibility is only triggered by issuing NCQ commands. So by disabling NCQ on the RAID controller, the problem was fixed. Our two remaining file servers have now been working without issues for more than two weeks.

These things were further exacerbated by my move to Germany with my family (our kids are 2.5 and 6 years old) which meant that I couldn't give these issues enough attention until now.

Hopefully these problems are behind us! I am grateful to everyone for their patience, and apologize for how long it took to track these things down and deal with them.

Cheers,
Bruce Allen

Je to dlouhý jak Lovosice, tak to beru jen velmi stručně. Zhruba tam píše:

1)Projekt měl problémy s výkonem. Z důvodu přetížené databáze. Ta zpracovávala v průměru 950 žádostí za sekundu, nárazově až 3000.
Zapříčinil to způsob jakým pracuje BOINC scheduler a fakt, že při zpracování nové analýzy (S5RI poz. přek.) není mnoho jednotek s nízkou frekvenci. EAH je jediný projektem používajícím "locality scheduler" (jak to rozumně přeložít "místní scheduler"? ) disajnovaný na rozesílání mnoha WU z jednoho datového souboru. Odesílá nový datový soubor jen když nezbývá žádná práce z předchozího. Co se stalo: Mnoho pomalých PC se soubory dat z malých frekvencí (jejichž zpracování je rychlejší) žádalo práci pro tyto data, i když veškerá tato práce došla ascheduler se jí snažil dál úporně hledat. Prolézání celé databáze způsobilo její extrémní přetížení. 20% pomalých PC tedy generovalo obrovské množství přístupů do databáze při hledání neexistujících jednotek s nízkou frekvencí. Opravil jsem to (Bruce) pozměněním algoritmu na vyhledávání nové práce. Každý kdo se o to zajímá může se podívat příští týden na BOINC CVS .kdy zkontroluji upravený kód.

Zatížení databáze je nyní 60-80 žádostí za sekundu. Databázové servery a servery projektu jsou opět přístupné

2) Problém s file serverem. EAH využívá tři file servery, každý s kapacitou 8 TB diskového prostoru v RAID-6. File server užívá 24-portový SATA řadič Areca a Western Digital WD4000YR disky. Po několik měsíců jsme měli problémy. Disk se odpojil z pole. Když se po několika sekundách znova připojil vyžadoval obnovu diskového pole. Nakonec jsme jeden ze serverů (vážící 80 Kg o ceně 10K$) poslali expres poštou na Taiwan, kde se inženýři z Areca na problém důkladně podívali. (díky inženýrům za jejich prvotřídní podporu) Problém byl v HW-rový s disky WD4000YR. Jejich čip SATA rozhraní není (u některých revizí) kompatibilní s řadiči Arcea. Nekompatibilita se projevuje jen při použití NCQ. Problém byl tedy vyřešen vypnutím NCQ. Zbylé servery již jedou 14 dní bez problému.

[vejpuste]

Parada. Obcas se holt spoji 2 nezavisle chyby a nadelaji peknou paseku.
Ale je dobre, ze na to prisli a muzeme jet spokojene dal. Obavam se, ze na nekterych projektech by to dal vyhnivalo, tady to vyresili.
Treba se EAH zase brzo vrati povest nejspolehlivejsiho projektu.
Libor

[Musacek]

Ano problem s odpojovanim disku nema jen WD ale i ostatni firmy, u rady YS to resily novym firmware..... nevim jak u rady YR

vice na http://cdr.cz/a/20401

[azor666]

Jsem si procetl trochu EAH forum, abych byl v obraze co se deje.
Az dojde prece S5RI (nebo S5R1 nebo jak se to menuje lol). Tak se bude pokracovat fazi S5R2

podle toho co se pise dal na foru. Bude i nova app. Tedy soucasna app, ale dale vylepsena "vycistena" a optimalizovana. Mela by byt i nativni 64b app. Kolik vykonu to muze na EAH zatim nechapu. Nezapomene se snad ani na PPC a ostatni platformy SPARC....
vychazim z http://einstein.phys.uwm.edu/forum_thre ... true#65364 http://einstein.phys.uwm.edu/forum_thread.php?id=4629

[Bubak]

Uz se zacaly posilat WU S5R2, asi par testovacich WU. App pro S5R2 maji cislo 4.13 - 4.16 podle OS.
Zaroven ted generuji vsechny zbyvajici WU S5R1.

Podle vyjadreni na foru prijde po S5R2 jeste S5R3, takze kdo cekate na S6, tak se dockate nekdy pristi rok. Mozna

Edit: procitam forum, tak doplnim, ze WU z varky S5R2 se pocitaji vice jak 5x dele nez WU S5R1 a vypada to, ze za ne bude pouze 2,2x vetsi credit nez za S5R1.

Edit2: Tak nevim, jestli maji ty S5R2 a S5R3 nejakej smysl. Me to spis prijde, ze zaplacavaj diru mezi S5 a S6 nejakyma vypoctama jen aby se nereklo a aby nestratily crunchery.... fyzik nejsem ale neprijde mi, ze by hlubsi analyzou tech dat dokazali existenci gravitacnich vln....

[Necroman]

jen doplnim, WU S5R1 uz dosly, je hotovo

[Bubak]

jen doplnim, WU S5R1 uz dosly, je hotovo

Jen doplnim, ze nedosli, jen jsou vsechny vygenerovane a cekaji. Koukni kolik WU je "unsent" proste je vygenerovali aby mohli pripravit S5R2.