Main

Protokoll 3

Protokoll vom 07.10.2013, 13:00 Uhr - Teammeeting:

Hauptthema: Diskussion von Systemvorschlägen

1. Frage: Wie wird das Endprodukt aussehen?

Ausgabemechanismus integrieren (NAS), um große Datenmengen auszuschließen. Uneffektive Methode! System muss noch gefunden werden. Webbasierter Zugriff?

C-Connector oder JDBC als Connector? Eher C-Connector, da wir in C++ programmieren? Welche Datenbank wird benutzt? MySQL? Da großes OpenSource und daher wahrscheinlich gut funktionierend. Oder MariaDB: OpenSource (LGPL), kompatibel mit MySQL, quasi selbe DB. Installation von einer DB löscht die andere.

2. Diskussion des Systemsvorschlags von Philip:

- leider kein Protokoll vorhanden -

3. Diskussion des Systemsvorschlags von Vergil:

Priority-Queue, Nutzerverwaltung? Registrierung? Mit vorheriger Anmeldung. Entscheidung wird getroffen von Prof. Röttger und uns? Wie wird das Projekt weitergeführt? Flexible Programmierung? Neuanmeldungen gehen wie von statten? Wie soll Registrierung ablaufen? Vorwarnsystem für Restnutzungsdauer von Festplatten integrieren, um Ausfallsicherheit zu garantieren.

Linux soll selbstständig Threads an Rechner aufteilen. Manuell ist zu aufwendig, besonders Cycles.

4. Diskussion des Systemsvorschlags von Mathias:

Intuitive Oberflächenbedienung für Nicht-Techniker! Rechner verteilt selbstständig (Threads) an Rechner.

Inwiefern ist es möglich Restarbeitsdauer (ETA) der Rechner einzuschätzen? Alternativen?

Grobe Schätzung vor Jobbeginn auf 1% runtergeschraubt ausgeben an Kunde (Vorschlag)

Preview ausgeben, welcher Frame, Datenmenge mit Eigenschaften als Benutzeroberfläche ausgeben. Interface-Ergänzung: Vorschlag. Hohe Wartezeit oder sonstige Faktoren in Priorität mit einbeziehen?!

Transport der Daten: Selbst abholen oder zuschicken?

Einbauen (GUI): Rechner haben entweder nur CPU oder CPU / GPU. Unterschiede in Performance feststellen und ausbessern. Skalierbarkeit der Rechner, d.h. über den Tag weniger Leistung, d.h. leiser

5. Diskussion des Systemsvorschlags von Dominik:

Zwischenspeichern auf Servern. Rein nach Priority Queue an Rechner weiterleiten. Inwieweit kriegen User Nachrichten über Status der Rechner und deren momentane Belastung

Vorschau um Fortschritt begutachten zu können! Live nicht, fertig gerendertes Bild wird auf der Preview angezeigt und zum Server geschickt. Neues Bild laden. Jedes Bild, da Belastung minimal ist!

Daten aus Renderfarm abholen?!

  • Abholen (USB), Problem: Rechner nicht frei zugänglich!
  • VPN-Download: bei kleinen Jobs
  • One-Click-Hoster: Server kriegt gerenderte Bilder und lädt sie gleich hoch. Oder nur nachts, um Belastung einzugrenzen. Intervall von Bildern hochladen um kleine Mengen downloadbar zu machen.
  • Festplatte einbauen, die hochschulinterne Downloads ermöglicht. VPN-Zugang. Einzelne Jobs passwortgeschützt, das per Mail zugeschickt wird und immer neu generiert wird.

Problem: Rechenzentrum Achtung: Bei Ausfall vom Server Backup sichern und bei Software sicher gehen, dass erkannt wird, dass Server ausgefallen ist!

Allgemein: Alle Jobs sollen nicht nur auf einen Server verschoben werden, um Ausfall / Verlust vorzubeugen.

6. Diskussion des Systemsvorschlags von Adam:

Software: Master-Slave-Architektur. Software entscheidet, ob Master oder Slave gebraucht wird. Immer 1 Master.

Collision: Besten Punkt bestimmen um sicher zu gehen, dass nur ein Master existent ist.

Im Webbrowser wird ausgegeben, welche Rendermethode zum Rendern benutzt wird. Master muss ständig wissen, welcher Slave wann welchen Job macht.

7. Allgemein

Vorschlag: Versuch eines unabhängigen Systems mit austauschbaren Elementen, falls das erforderlich wird + Plan B.

Feste Komponenten:

  • Webinterface (intuitiv, Benutzerverwaltung)
  • Server (CGI, CMS)
  • DaBa (MySQL / MariaDB / QSQL )
  • Speicher (NAS / Domi-Festplatte / Rechner)

Oberfläche: Login-System: Jobs reinstellen Aufgabe: Verbesserungen nötig

8. Weitere Aufgaben:

  • DB Konzepte entwerfen
  • NAS Server oder Rechner umrüsten mit Hardware um Geld zu sparen → Prof. Röttger fragen
  • Ideen verschmelzen zu einem Vorschlag

-Protokoll verfasst von Philip

Options: