No, hypoteticky ano, ale jak to vypnout to ochutnávání nových a dojídat původní?forest píše: ↑pát 07 zář, 2018 06:18 Je to myslím naprogramováním Scheduleru. Vždy zvažuje v prvé řadě to, aby vše stihnul dopočítat a odevzdat před deadline. Do toho bere ohled na nastavení o udržovaném množství zásoby. Běžně BOINC funguje tak, že si po změně natáhne práce bohužel moc, tedy převyšuje nastavené limity. Je to dáno tím, že ještě nemá žádnou informaci o těch nových jednotkách, na které jsi přehodil koleje. Když to zjistí (tedy po dokončeném natažení první jednotky, její odhad délky výpočtu a s ohledem na celkově stahovanou zásobu) ztratí hlavu. V panice se vrhne na tu novou práci aby zjistil, jak moc je aktuální stav pro něj špatný, tedy aby zjistil skutečnou délku nových jednotek. Toto by někdo musel umět vypnout. Pokud ale ty starší jednotky mají kratší deadline, měl by se k nim za krátký čas vrátit. Bohužel zase nechá rozpravované ty novější jednotky.
Druhou z věcí která se stává je, že nové jednotky mohou mít kratší deadline a proto je neopustí ani po dokončení vzorových prvních kousků, nebo nějaké části (TS). Prostě co se má odevzdat dřív, to počítá, což je logické.
Deadline sieve jsou 4 dny, Culler má 15 dní. To je hafo času na rychlý stroj 24/7.
Respektuje se nastavení cache, tj. stáhnul se pouze jeden Cullen LLR task, stejně tak sieve jednotky nejsou nadbytečné. To je dobré znamení. Kdyby natáhnul moc, znamenalo by to, že podcenil délku výpočtu a pak zmatkuje.
A tady to bylo zrovna o tom, že nové jednotky mají delší deadline - nejprve sieve, pak LLR.
A právě to, co se mělo dopočítat s kratší deadline, zůstalo rozpočítané.
Tady nemá o čem zmatkovat - výpočet jednotky v 99%, necelá minuta do konce, natažena další jednotky s dealine 15 dní, stroj jede 24/7, žádné další projekty, jednoduchý share.
Co by scheduler mohlo mást, že mixování multithreaded a klasických jednotek.
Snad používám korektně avg_ncpus tag, aktuální verzi BOINcu, kde by to mohlo být doladěné.
No, každopádně je to flustrující...