= 07.12.2011 = Moduly zostaja na pozimie pluginu (+) Zamiast listy wykonywanych zadan (//InExecutionList//) w metodzie schedule ma byc rejestr zadan w systemie (//JobRegistry//) (+) Agent do wysylania eventow Timer - czy na roznych warstwach moze byc ustawiony inny interwal czasu? (TAK) Pluginy - parametry metod powinny byc skladowymi klasy (pluginu) czy tak jak do tej pory agumentami przekazanymi z polityki Usunac generyki na interfejsie (zobaczyc wczesniej czy sa potrzebne) //JoobRegistry// powinien ograniczac informacje w zaleznosci od "warstwy" (+) Temperature and energy dissipation w pluginie energertycznym (+) '''Na 09.12.2011''' Wojtek - aktualizacja interfejsow (+) '''Tomek - ciastka (Ariel - belgijskie, Tomek - francuskie, Wojtek - obojetnie)''' (+) = 09.12.2011 = Zglaszanie i obsluga wyjatkow Metody powinny przyjmowac jako parametry "bazowe" implementacje interfejow Zamiast List wprowadzic obiekt //ClassList// = uspojnienie interfejsow + dodatowe mozliwosci operacji na poszczegolnych listach Jesli //SchedulingPlan// zawiera zadanie bez przypisanych zasobow to wywolaj wtedy niejawnie meteode chooseResourcesFor //ResourceUnit// - czy zastapic czyms? jesli tak to czym?, resource jako wspolny typ dla wszystkich zasobow a nie tylko dla warstw? - do przemyslenia startTimePrediction - mozliwe w module a nie w //TimeEstimationPlugin// //ResourceManager// - chooseResourcesOfType - powinno zwracac wszystkie oferty //ResourceManager// - mozliwosc laczenia statusow przy filtracji Dodac mozliwosc odpytania zasobu o jego rozszerzenia Dodac "generyki" w //ResourceManager// dla niektorych metod - do przemyslenia Integracja GPU/CPU, zadania MPI Frequency table, P-States GSSIM powinien wspierac zapewnienie korelacji miedzy speed a frequency dla CPU '''Motto prac nad symulatorem- Tomek: "Jesli robisz cos za duzo to sie to na Tobie zemsci"''' '''Na 14.12.2011''' Wojtek - aktualizacja interfejsow Wojtek - Przygotowac interfejsy Job'ow, Task'ow itp (+) = 14.12.2011 = Uogolnic metody tak aby jako parametry przyjmowayly obiekty implementujace dany interfejs - bez narzucenia klasy bazowej //ExecTimeEstimationPlugin// - metoda szacujaca czas powinna przyjmowac jeszcze jako parametr EVENT (+) Interfejs Plugin - uogolnic typ zwracany przez getConfiguration na //PluginConfiguration// (+) //ResourceType// jest typem wyliczeniowym co ogranicza mozliwosc dodawania przez uzytkownika nowych zasobow bez ingerencji w kod. Lepiej wiec zamienc na //ResourceTypeName// - Stringa //ResourceManager// - getResourceOfType(Properties properties) - umozliwi filtracje zasobow po typie, kategorii i cechach '''Na 21.12.2011''' Wojtek - Przygotowac //SchedulingPlanInterface// itp (+) Wojtek - Zdefiniowac plugin, modul, rozszerzenia = 21.12.2011 = Z zasobem zwiazany //Properties// umozliwiajacy ich filtracje i wyszukiwanie po typie itd (jak wyzej) Warstwy logiczne "agreguja" warstwy fizyczne = 03.01.2012 = Wasrtwy fizyczne a warstwy logiczne: 1. hierarchie warstw logicznych i fizycznych - OK 2. kwestia przypisania zasobu do zadania - przypisujemy do warstw logicznych czy fizycznych? a) warstwa logiczna jako rodzaj zasobu (o innym typie) - wspolny widok na warstwy momencie "brokeringu" - nie wyczerpuje wszystkich mozliwych scenariuszy b) szeregujemy na warstwy logiczne, hierarchia warstw fizycznychi ich przynaleznosc do logicznych ulatwia podejmowanie decyzji - wyczerpuje wszystkie scenariusze - ptyanie czy uztykownik nie chciably miec mozliwosci szeregowania na zasob np. node c) preferowane rozwiazanie b) ale mozna tez szeregowac na zasob fizyczny - jesli nie ma tam schdedulera to blad Odwieczna kwesta zasobow:) - dwa rodzaje: zasoby tworzace hierarchie - czyli te z ktorymi mozna skojarzyc warstwy logiczne + zasoby typu pamiec, dysk itp bedace charakterystka tych pierwszych Bycmoze umozliwic uzytkownikowi wyspecyfikowanie najnizszej warsty tzn bez narzucania //Processing Element//. W ten sposob dowolny bedzie mozna wykonac zadanie na dowolnym zasobie (domyslny //Processing Element//) '''Na 09.01.2012''' Wojtek - Zastanowic sie czy //SchedulingPlan// jest potrzebny - bycmoze wystarczy wywolac jedynie submit na zasaobie Wojtek - Przygotowac wstepny plan prac = 09.01.2012 = Rozwiazanie "c" chyba bedzie najlepsze: tzn szeregujemy na warstwy logiczne do ktorych mamy dostep z //ResourceManagera// ale mozna tez szeregowac na zasob fizyczny jesli jest z nim skojarzona scisle warstwa logiczna (posiada //Schedulera//) - jesli nie ma to blad Rozrozniamy //Resouce// - zasoby fizyczne tworzace hierarchie i //ResourceUnit// czyli alokowalne jednostki "pozostalych" zasobow (pamiec, dystk itp.) = 23.01.2012 = '''Scenariusze na spotkanie grantowe''' Zalozenia: 1) 2 poziomy (gridowy i lokalny) 2) bez wirtualizacji Na lokalnym poziomie senariusz a) losowy przydzial do wezlow - na koniec zuzycie energii (przy wszystkich dzialajacych wezlach) - konieczne "zliczanie" zyzycia, szcowanie dlugosci zadania na zasobie, rozne "pobory" przy roznym obciazeniu, scenariusz b) n klas wezlow - zlecanie do wolnych "najtanszych" energetycznie - konieczne charakterystyki scenariusz c) wylaczanie nieuzywanych wezlow - konieczne wylaczanie i wlaczanie wezlow scenariusz d) zmniejszanie czestotliwosci jak zadanie sie wyrobi przed deadlinem - konieczne skalowanie czestotliwosci scenariusz e) uwzglendnienie wymogow aplikacji (pamiec, zapotrzebowanie na procesor) - konsolidacja obciazenia (bez migracji). = 11.04.2012 = '''Opis zasobow''' schema: [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/XSSimResSchema.xsd schema.xsd] przykladowe opisy zasobow: * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example1.xml example1] - grid, tak jak w starym GSSimie * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example2.xml example2] - grid, definicja zasobow "fizycznych" i "logicznych" * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example3.xml example3] - grid, definicja zasobow "fizycznych" i "logicznych" wersja 2 * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example4.xml example4] - data center, charakterystyka zasobow * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example5.xml example5] - data center, charakterystyka energetyczna * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example6.xml example6] - data center, rozmieszczenie zasobow * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/example7.xml example7] - data center, szablony, przejscia miedzy stanami energetycznymi = 17.07.2012 = '''Przyklady opisu zasobow dla CoolEmAll''' * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/coolemall/example1.xml example1] - data center z podstawowoymi charakterystykami * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/coolemall/example2.xml example2] - data center z uwzglednieniem aspektow energetycznych i przeplywu powietrza * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/coolemall/example3.xml example3] - data center, lokalizacja zasobow * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/coolemall/example4.xml example4] - data center, szablony + energia * [http://apps.man.poznan.pl/trac/gssim/browser/xssim/trunk/src/test/rewolucja/schemas/example/coolemall/example5.xml example5] - testbed coolemall'owy