Souhlas. Mohlo by to byt nastavitelny. Treba to casem pribyde do dalsi verze BS core jako nastavitelny parametr. Nemyslim, ze by to znamenalo moc velkej napor na scheduler kdyby se ho snazil boinc core kontaktovat treba 3x denne. Uvidime, jestli se vubec najde nekdo kdo se vyvoje BS core ujme.Higgi píše:....
Jenom fakt nechápu, proč boinc odkládá komunikaci o tejden. Kdyby o 24 hodin, tak jo, ale tohle je fakt moc.
Scheduler interval
Moderátoři: zdespi, Moderátoři
Scheduler interval
Private (old) + CCU stats.
-
vejpuste
- BOINC Guru
- Příspěvky: 954
- Registrován: čtv čer 16, 2005 11:00 am
- Bydliště: Praha Zbraslav
- Kontaktovat uživatele:
Re: E@H jede
Jsme sice dost mimo, ale to nemas k tem pocitacum vzdaleny pristup?Higgi píše:Potvrzuji, o5 běží. Škoda, že se ke 3 kompům, co mám mimo, dostanu až ve středu. ale aspoň na jeden jsem se dnes dostal a dal jsem tam RCN, tak zas prospěje jinde
.
Ja jsem si pro ucebny udelal maly batak, ktery se spousti schedulerem ve woknech. Ten projde vsechny pocitace a da jim update projektu. Co si nastavis, to udela. Nemusis mit na ten pocitac ani pristup a bude to delat sam porad.
Libor
To ale popisujes nejakou planovanou feature ne? Koukal jsem se do sched_reply*.xml asi 10 projektu a krom tagu <request_delay> jsem tam nic jineho nenasel. Ale to je pri normalnim provozu a je to min. cas za ktery muze core o5 kontaktovat scheduler. To co by chtel Higgi i ja je presne opacny parametr vymezujici opacnou mez toho intervalu. A v tom pripade by bylo asi lepsi, kdyby byl uzivatelsky nastavitelny a scheduler mohl pripadbne jen urcit min. interval pokusu o kontakt v pripade vypadku.Honza píše:Bubak - ono by take slo, aby scheduller projektu urcoval, za jak dlouho jej muze masina kontaktovat v pripade vypadku...proste takovy servnicni rezim (pr beznem provozu to funguje a kazdy projekt ma tento interval jiny)
Omlouvam se za OT. Asi by jsme se meli presunout do BS threadu.
Private (old) + CCU stats.
Souhlasim s oddelenim tematu od puvodniho E@H aktualni stav.
Chtel jsem rici, ze ten request_delay jde pouzit..aby mel projekt urcenu hodnotu pro bezny provoz (kuprikladu 50 vterin) a jinak nastavnou hodnotu pro pripad vypadku databaze, kdyz se odporoucej disky, projekt je bez prace a podobne pripady, kdy je jasne, ze je zbytecne scheduler kontaktovat drive nez za hodinu.
Reseni, ktere navrhujes - jestli spravne chapu tak min a max intevral je zdanlive elegantnejsi. Asi vyzaduje zasahy do vsech boinc core i serveru vsech projektu, coz je vyvojarum pochopitelne chtit nebude a proto se nejdriv hledaji cesty, jak vystacit s tim, co je k dispozici nez zavadet novinky vyzadujici upgrade vseho mozneho.
Nebo jinak - nevim, jestli je dobre mit moznost overwrite na sched_replay.
Tak nejak mam pocit, ze je lepsi, aby si toto ridit server, protoze vi nejlepe, co je dobre - kolik hostu se na nej obraci, kolik ma max kapacitu, kolik ma prace nebo kdy bude dalsi atp...tohle vsechno boinc core nevi, pokud mu to scheduler nerekne.
Tak jako tak by to fungovalo pouze v pripade, ze scheduler pobezi. Kdyz je project off-line (spadne linka, podela se firewall, spadne sql nebo web server atp.), tak si musi vystacit boinc core se svou 'inteligenci'.
Osobne bych se klonil k max hodnote kontaktu na hodnotu odpovidajici stavu, kdy dojde prace (tj. work cache). Myslim, ze takova hodnota ma urcitou logiku.
btw, nereseruje se ten interval v pripade resetu projektu?
Chtel jsem rici, ze ten request_delay jde pouzit..aby mel projekt urcenu hodnotu pro bezny provoz (kuprikladu 50 vterin) a jinak nastavnou hodnotu pro pripad vypadku databaze, kdyz se odporoucej disky, projekt je bez prace a podobne pripady, kdy je jasne, ze je zbytecne scheduler kontaktovat drive nez za hodinu.
Reseni, ktere navrhujes - jestli spravne chapu tak min a max intevral je zdanlive elegantnejsi. Asi vyzaduje zasahy do vsech boinc core i serveru vsech projektu, coz je vyvojarum pochopitelne chtit nebude a proto se nejdriv hledaji cesty, jak vystacit s tim, co je k dispozici nez zavadet novinky vyzadujici upgrade vseho mozneho.
Nebo jinak - nevim, jestli je dobre mit moznost overwrite na sched_replay.
Tak nejak mam pocit, ze je lepsi, aby si toto ridit server, protoze vi nejlepe, co je dobre - kolik hostu se na nej obraci, kolik ma max kapacitu, kolik ma prace nebo kdy bude dalsi atp...tohle vsechno boinc core nevi, pokud mu to scheduler nerekne.
Tak jako tak by to fungovalo pouze v pripade, ze scheduler pobezi. Kdyz je project off-line (spadne linka, podela se firewall, spadne sql nebo web server atp.), tak si musi vystacit boinc core se svou 'inteligenci'.
Osobne bych se klonil k max hodnote kontaktu na hodnotu odpovidajici stavu, kdy dojde prace (tj. work cache). Myslim, ze takova hodnota ma urcitou logiku.
btw, nereseruje se ten interval v pripade resetu projektu?
2 Honza: Je to nejaky neprehledny (a kdyz k tomu pricteme mou bidnou vyjadrovaci schopnost....). Dal se bavme jen o tom, co by se melo dit v pripade nedostupnosti scheduleru a jak toho dosahnout.
Soucasny stav: Pokud je scheduler nedostupny, tak se odklada komunikace po kazdem pokusu o delsi interval, az naroste na desitky dni. Pokud scheduler bezi, tak neni problem, at si klidne urcuje min. interval pro dalsi request.
Moje idea: Power user by si mohl editaci souboru nastavit kam az muze ten cas odkladu narust. Predstavoval bych si to tak, ze nepujde nastavit min nez 8 hodin. To by nemelo delat problemy provozovatelum jednotlivych projektu. Pokud je scheduler mimo provoz, tak to ani nepoznaji a postupny najezd vsech PC behem 8 hodin po vypadku by mohli zvladnout. Pripadne pokud by se v dalsi verzi BOINCu pridal dalsi tag do komunikace scheduler-> core (napr. <offline_rerequest_min> - urcite ti napadne lepsi nazev) ktery by prepisoval tech mejch navrhovanejch 8 hodin dle prani provozovatele konkretniho projektu tim lepe. Mam za to, ze starsi verze core ignoruji tagy, ktere neznaji, takze s tim by nemel byt problem.
V prvni fazi bych to spis videl jako patch do nejake neoficialni modifikace BOINC core (cti BS, ostatni jsou asi mrtvy). Takze, mas nejake aktualni info jestli uz sehnali nekoho kdo bude pokracovat ve vyvoji?
Soucasny stav: Pokud je scheduler nedostupny, tak se odklada komunikace po kazdem pokusu o delsi interval, az naroste na desitky dni. Pokud scheduler bezi, tak neni problem, at si klidne urcuje min. interval pro dalsi request.
Moje idea: Power user by si mohl editaci souboru nastavit kam az muze ten cas odkladu narust. Predstavoval bych si to tak, ze nepujde nastavit min nez 8 hodin. To by nemelo delat problemy provozovatelum jednotlivych projektu. Pokud je scheduler mimo provoz, tak to ani nepoznaji a postupny najezd vsech PC behem 8 hodin po vypadku by mohli zvladnout. Pripadne pokud by se v dalsi verzi BOINCu pridal dalsi tag do komunikace scheduler-> core (napr. <offline_rerequest_min> - urcite ti napadne lepsi nazev) ktery by prepisoval tech mejch navrhovanejch 8 hodin dle prani provozovatele konkretniho projektu tim lepe. Mam za to, ze starsi verze core ignoruji tagy, ktere neznaji, takze s tim by nemel byt problem.
V prvni fazi bych to spis videl jako patch do nejake neoficialni modifikace BOINC core (cti BS, ostatni jsou asi mrtvy). Takze, mas nejake aktualni info jestli uz sehnali nekoho kdo bude pokracovat ve vyvoji?
Private (old) + CCU stats.
> co by se melo dit v pripade nedostupnosti scheduleru a jak toho dosahnout
Jednoduse bych zvolil work cache jako max interval.
Kdyz ma nekdo cache na 10 dni, mel by BOINC poznat opetovnou funkcnost serveru drive - pri uploadu souboru.
> V prvni fazi bych to spis videl jako patch do nejake neoficialni modifikace BOINC core (cti BS, ostatni jsou asi mrtvy). Takze, mas nejake aktualni info jestli uz sehnali nekoho kdo bude pokracovat ve vyvoji?
Bohuzel.
Jednoduse bych zvolil work cache jako max interval.
Kdyz ma nekdo cache na 10 dni, mel by BOINC poznat opetovnou funkcnost serveru drive - pri uploadu souboru.
> V prvni fazi bych to spis videl jako patch do nejake neoficialni modifikace BOINC core (cti BS, ostatni jsou asi mrtvy). Takze, mas nejake aktualni info jestli uz sehnali nekoho kdo bude pokracovat ve vyvoji?
Bohuzel.
Vis to jiste? Ja tedy ne. A rekl bych ze pokud je odlozena komunikace se schedulerem, tak core ani neuploaduje soubory.Honza píše:> co by se melo dit v pripade nedostupnosti scheduleru a jak toho dosahnout
Jednoduse bych zvolil work cache jako max interval.
Kdyz ma nekdo cache na 10 dni, mel by BOINC poznat opetovnou funkcnost serveru drive - pri uploadu souboru.
Co v pripade ze nekdo pocita CPDN?
Private (old) + CCU stats.
Jiste to nevim.
Ale usuzuji z toho, ze upload ci download server muze byt (a take byva) uplne jinde nez scheduler - ze se proste jedna o jiny server s jinou konektivitou (trebas zminovane CPDN, ale i Einstein).
Usuzuji z jednani scheduleru a uploadu pri pocitani Proteins - tam jsou uploady velke, navic mi u masiny hrozi "reach daily quota". Pri zapnutem FUP a stahovani obcas neprojde upload nebo download, reach daily quota odlozi komunikaci na dalsi den (spravne), ale uploady se snazi dal (doufam). Jsou uploadovany, ale zustavaji nereportovane, pokud si dobre vzpominam.
S pripade CPDN je scheduler kontaktovan kvuli tricklum, obcas se do toho primota i upload, takze tam pozadavky na komunikaci obcas take jsou. No a kdyby ne - zde potize z prodleni nehrozi...pokud nedojde prace.
Scheduler v novejsich verzich ale dava docela pozor na vybalancovani, aby masina praci mela a pritom nebyla overcommited.
Tedy - neni-li spojeni mezi funkcnosti upload serveru a scheduleru projektu, muze byt triggerem komunikace bud cache size nebo udalost, ze bude s praci na suchu (finished jednotky se do cache nezapocitavaji).
Pak jsou zde jeste moznosti slozitejsich obezlicek.
Napriklad zmenim profil na projektu A a masina 1 jej aktualizuje i na projektu B. Masina 2 ma problem kontaktovat projekt B, ale mohla by v ramci budouci podpory bitorrentu kontaktoval masinu A. Pripadne to muze delat lokalne BS ci BV nebo se to muze dozvedet z AMS (BAM).
O lokalni komunikaci mezi hosty se da uvazovat - at jiz z duvodu setreni trafiku na download nebo scheduleru serveru. Zde by se asi nejaky min_interval (pak staci pouze lokalni synchronizace) a max_interval (expirace profilu) hodil.
Ale usuzuji z toho, ze upload ci download server muze byt (a take byva) uplne jinde nez scheduler - ze se proste jedna o jiny server s jinou konektivitou (trebas zminovane CPDN, ale i Einstein).
Usuzuji z jednani scheduleru a uploadu pri pocitani Proteins - tam jsou uploady velke, navic mi u masiny hrozi "reach daily quota". Pri zapnutem FUP a stahovani obcas neprojde upload nebo download, reach daily quota odlozi komunikaci na dalsi den (spravne), ale uploady se snazi dal (doufam). Jsou uploadovany, ale zustavaji nereportovane, pokud si dobre vzpominam.
S pripade CPDN je scheduler kontaktovan kvuli tricklum, obcas se do toho primota i upload, takze tam pozadavky na komunikaci obcas take jsou. No a kdyby ne - zde potize z prodleni nehrozi...pokud nedojde prace.
Scheduler v novejsich verzich ale dava docela pozor na vybalancovani, aby masina praci mela a pritom nebyla overcommited.
Tedy - neni-li spojeni mezi funkcnosti upload serveru a scheduleru projektu, muze byt triggerem komunikace bud cache size nebo udalost, ze bude s praci na suchu (finished jednotky se do cache nezapocitavaji).
Pak jsou zde jeste moznosti slozitejsich obezlicek.
Napriklad zmenim profil na projektu A a masina 1 jej aktualizuje i na projektu B. Masina 2 ma problem kontaktovat projekt B, ale mohla by v ramci budouci podpory bitorrentu kontaktoval masinu A. Pripadne to muze delat lokalne BS ci BV nebo se to muze dozvedet z AMS (BAM).
O lokalni komunikaci mezi hosty se da uvazovat - at jiz z duvodu setreni trafiku na download nebo scheduleru serveru. Zde by se asi nejaky min_interval (pak staci pouze lokalni synchronizace) a max_interval (expirace profilu) hodil.
Tak jsem udelal takovy pokus - vcera vecer jsem si na jedne masine zakazal pristup na net a dneska po obede zakazal pristup i dalsim 3 masinam. Do te doby se mi nafrontovalo cca 150 mega na upload. Zapnul jsem si FUP, tedy 256/256 ci kolik a k tomu jeste pustil torrent - v tomto stavu mi BOINC nestiha z masin uploadovat...
Doufal jsem take, ze zacne na me masine doplnovat zasobu prace a vycerpam daily quota (nejlepe udelat fake na 1 CPU na dual-core...jenze se tam vmestnal LHC, ktery ma zrovna praci (tam navic diky letitemu bugu generovani stale nove masiny pri kazdem kontaktu daily quota nenastane). Proste jsem si to ne dostatecne osetril, takze jsem se nedostal na nejaky vyssi communitacion deffered.
Presto mi i pri kratkych defferals pripada, ze upload a download bezi nezavisle na stavu scheduleru...a pripadne skonci chybou a bude postupne naskakovat retry interval.
No asi bude lepsi na podobne testy nejaky mene spolehlivy projekt - treba SETI s pravidelnymi vypadky se zda byt dobrou pomuckou.
Alespon jsem si overil, ze BS sice dava prednost uploadu, ale obcas pusti i download, aby nedoslo k tomu, ze nebude prace kdyz nestiha uploadovat.
Doufal jsem take, ze zacne na me masine doplnovat zasobu prace a vycerpam daily quota (nejlepe udelat fake na 1 CPU na dual-core...jenze se tam vmestnal LHC, ktery ma zrovna praci (tam navic diky letitemu bugu generovani stale nove masiny pri kazdem kontaktu daily quota nenastane). Proste jsem si to ne dostatecne osetril, takze jsem se nedostal na nejaky vyssi communitacion deffered.
Presto mi i pri kratkych defferals pripada, ze upload a download bezi nezavisle na stavu scheduleru...a pripadne skonci chybou a bude postupne naskakovat retry interval.
No asi bude lepsi na podobne testy nejaky mene spolehlivy projekt - treba SETI s pravidelnymi vypadky se zda byt dobrou pomuckou.
Alespon jsem si overil, ze BS sice dava prednost uploadu, ale obcas pusti i download, aby nedoslo k tomu, ze nebude prace kdyz nestiha uploadovat.
-
Pav Lucistnik
- Mírně pokročilý
- Příspěvky: 144
- Registrován: ned črc 16, 2006 1:02 pm
- Bydliště: Praha
- Kontaktovat uživatele:
Moje pozorovani z behu Einstein@home na jednou denne pripojovanem GPRS:
- file transfers jsou nezavisle na komunikaci se schedulerem
- prenosy jsou provadeny presne v poradi, v jakem "vznikly". tj pokud mas frontu na upload, v ni 40 resultu, pozadas o novou praci a dostanes jeden soubor na download, tak nejdriv projde vsech 40 uploadu a az potom download, bez ohledu na to, ze uz klientu dosla veskera prace
- kdyz prenos selze, zaradi se retry opet na konec fronty
- file transfers jsou nezavisle na komunikaci se schedulerem
- prenosy jsou provadeny presne v poradi, v jakem "vznikly". tj pokud mas frontu na upload, v ni 40 resultu, pozadas o novou praci a dostanes jeden soubor na download, tak nejdriv projde vsech 40 uploadu a az potom download, bez ohledu na to, ze uz klientu dosla veskera prace
- kdyz prenos selze, zaradi se retry opet na konec fronty
Stale se mi zda, ze druhy bod plati za predpokladu, ze pri upload nedojde k chybam.
Stala se mi vsak jina kuriozita - nahodil jsem po delsi dobe Leiden...chtelo se mi stahnout cca 30 tasku, ale zrovna projekt vychcipnul. Takze zustaly v downloading...retry atp., ale work tab prazdny.
V takovem pripade backup project nezachrani, protoze o praci nezada.
Stejne tak by se asi delo, pokud mate nastavenu dostupnost site jen na nejake hodiny. Na odesilani se nafrontuji desitky tasku...a pokud se to pri uploadu zabrzdi, scheduler si sice rekne o dalsi praci z non-backup projektu, ale dostane ji jenom, pokud se upload zadari (nebo pri nem dojde k chybe a pritom download pobezi?).
Stala se mi vsak jina kuriozita - nahodil jsem po delsi dobe Leiden...chtelo se mi stahnout cca 30 tasku, ale zrovna projekt vychcipnul. Takze zustaly v downloading...retry atp., ale work tab prazdny.
V takovem pripade backup project nezachrani, protoze o praci nezada.
Stejne tak by se asi delo, pokud mate nastavenu dostupnost site jen na nejake hodiny. Na odesilani se nafrontuji desitky tasku...a pokud se to pri uploadu zabrzdi, scheduler si sice rekne o dalsi praci z non-backup projektu, ale dostane ji jenom, pokud se upload zadari (nebo pri nem dojde k chybe a pritom download pobezi?).