Systeme 1 Kapitel 9.1 Betriebssysteme auf aktueller Hardware

Präsentation zum Thema: "Systeme 1 Kapitel 9.1 Betriebssysteme auf aktueller Hardware"—  Präsentation transkript:

1 Systeme 1 Kapitel 9.1 Betriebssysteme auf aktueller Hardware
Interaktion von Hardware und Betriebssystem Linux-Kernel und x86 Systeme WS 2009/10

2 Letzte Vorlesung Beispiel: Hash-Tabelle
1 2 3 4 5 10 15 20 25 30 35 Hash Table Searches per Microsecond # CPUs „ideal“ „global“ Bei diesem einfachen Beispiel hat das Hinzufügen von weiteren CPUs sogar negative Effekte. In diesem Beispiel wird hauptsächlich lesend auf die Tabelle zugegriffen, dennoch muss dieser Zugriff vor potentiell (seltenen) schreibenden Zugriffen geschützt werden. Frage: Wie kann man solche Zugriffsmuster ausnutzen ? Quelle: Paul E. McKenney „Exploiting Deferred Destruction: An Analysis of Read-Copy-Updates Techniques in Operating System Kernels“, Dissertation Oregon State University, July 2004. WS 2009/10

3 Read-Copy-Update (RCU)
Read-Copy-Update (RCU) verbindet die Idee von nichtblockierender Synchronisation und symmetrischer Synchronisation. Erlaubt lesenden Zugriff ohne Synchronisationsoverhead: Ohne Locks Ohne atomaren Instruktionen Erreicht damit nahezu ideale Skalierung für lesenden Zugriff. WS 2009/10

4 Read-Copy-Update (RCU)
Vergleich des Overheads zwischen Reader-Writer-Locks und RCU WS 2009/10

5 Read-Copy-Update Synchronisationsoverhead ausschließlich beim schreibenden Zugriff: Schreibender Zugriff auf eine Datenstruktur (Update) erfolgt in drei Schritten: Entferne alle Referenzen auf Daten, so dass keine neuen lesenden Zugriffe mehr möglich sind. Warte bis alle lesenden Zugriffe beendet wurden. Wenn keine lesenden Zugriffe vorhanden, lösche nicht mehr referenzierte Daten. WS 2009/10

6 Read-Copy-Update (RCU)
Schreibender Zugriff (Update): Für den lesenden Zugriff gibt es keine Synchronisierung, somit muss sichergestellt werden, dass es zu keinem Lesefehler kommen kann. Zeiger Version 1 Ausgangssituation Alte Version bleibt erhalten solange noch lesende Zugriffe stattfinden. Update auf Version 2 Zeiger Version 1 Version 2 WS 2009/10

7 Read-Copy-Update (RCU)
Schreibender Zugriff (Update): Zeiger Version 1 Alte Version bleibt erhalten – noch lesende Zugriffe. Update auf Version 2 Version 2 Zeiger Version 1 Alte Version bleibt erhalten – noch lesende Zugriffe. Update auf Version 3 Version 2 Version 3 WS 2009/10

8 Read-Copy-Update (RCU)
Schreibender Zugriff (Update): Zeiger Version 1 Keine lesenden Zugriffe mehr. Alte Version bleibt erhalten – noch lesende Zugriffe. Aktuelle Version Version 2 Version 3 Zeiger Alte Version bleibt erhalten – noch lesende Zugriffe. Aktuelle Version Version 2 Version 3 WS 2009/10

9 Read-Copy-Update (RCU)
Problem: Wann sind alle lesenden Zugriffe auf einer bestimmten Version beendet? Lesende Zugriffe sind synchronisations- und kommunikationsfrei Voraussetzungen für den lesenden Zugriff Kein lesender Thread/Prozess darf während des Zugriffs auf RCU geschützte Daten blockieren. Kein lesender Thread/Prozess darf während des Zugriffs unterbrochen werden. Wenn auf allen CPUs ein Context-Switch durchgeführt wurde, sind garantiert alle lesenden Zugriffe der letzten Periode abgeschlossen. (Quiescent State) WS 2009/10

10 Read-Copy-Update (RCU)
Wegen der speziellen Voraussetzungen für den lesenden Zugriff ist RCU besonders für Betriebssysteme interessant, da innerhalb des Betriebssystems diese Bedingungen garantiert bzw. kontrolliert werden können. Skalierung wird für Betriebssysteme immer wichtiger. Moderne PCs werden praktisch nur noch als Mehrkernvariante verkauft. In Betriebssystemen kommen lesende Zugriffsmuster sehr häufig vor. Meist werden Datenstrukturen einmal initialisiert, nur selten verändert und sehr häufig gelesen. Z.B.: Einstellungen und Konfigurationen. Adressauflösung von Netzwerkpaketen Gbit Geschwindigkeit / mehrere Netzwerkkarten / mehrere CPUs WS 2009/10

11 RCU Zusammenfassung RCU bietet lock-freien lesenden Zugriff auf geteilte Daten. Dadurch ergibt sich kaum CPU Overhead und Lock-Contention wird vermieden. Eine fast optimale Skalierung wird erreicht. Der Overhead wird auf Schreiboperation (Update) übertragen. Aufgrund der speziellen Anforderungen an den lesenden Thread/Prozess ist eine Implementierung von RCU meist nur betriebssystemintern möglich. WS 2009/10

12 Systeme 1 Kapitel 9.2 Interaktion von Hardware und Betriebssystem
Linux-Kernel und x86 Systeme WS 2009/10

13 Speicherzugriffe auf x86 Systemen
Auf x86 Systemen existieren drei Arten von Speicheradressen: Logische Adresse Lineare Adresse (Virtuelle Adresse) Physikalische Adresse Übersetzung der Adressen erfolgt mit Hilfe von Hardware. Physikalische Adresse Logische Adresse Lineare Adresse Segmentation-Unit Paging-Unit WS 2009/10

14 Speichersegmente Die x86 Architektur unterteilt Speicher in einzelne Segmente. Eine logische Speicheradresse besteht aus zwei Teilen, dem Segmentbezeichner (segment selector) und der relativen Speicheradresse innerhalb des Segments (offset). X86 Prozessoren besitzen sechs eingebaute Register für einen schnellen Segmentzugriff, insbesondere drei spezielle Register: cs (Code Segment Register) ss (Stack Segment Register) ds (Data Segment Register). Die weiteren Register ef, fs und gs sind unspezifisch und können für den Zugriff auf beliebige Datensegmente verwendet werden. WS 2009/10

15 Segment Deskriptoren Jedes Segment wird durch einen 8-Byte großen Segment-Deskriptor beschrieben. Unter anderem sind das: die lineare Adresse des ersten Bytes die Größe des Segments die Art des Segments (Code, Daten, Task State) der minimale CPU-Privilegienlevel (Ring), der für den Zugriff notwendig ist. Eine globale Segment Deskriptoren Tabelle (GDT) beinhaltet alle definierten Segmente. WS 2009/10

16 Segmentierung und Linux
Die Einführung von Speicher-Segmenten sollte Programmierer dazu animieren, Programme in einzelne logische Einheiten zu unterteilen. Linux verwendet Segmentierung nur sehr eingeschränkt, da die Speicherverwaltung komplexer wird die Portierung auf andere Architekturen dadurch erschwert wird. Linux nutzt lediglich: jeweils ein Segment für Kernel-Code und -Daten jeweils ein Segment für Prozess-Code und -Daten vier spezielle Segmente für BIOS und Powermanagement (APM) ein Task State Segment (TSS) für jede CPU In diesem Segment werden alle Prozessorzustände bei einem Context-Switch zwischengespeichert. WS 2009/10

17 Paging in Hardware x86-Prozessoren können Paging in Hardware lösen
Paging wird aktiviert durch Setzen des PG-Flags im Kontrollregister (cr0). Ein weiteres Kontrollregister (cr3) enthält die physikalische Adresse des Page Directory. 31 22 21 Lineare Adresse 12 11 Directory Table Offset Page Page Table Page Directory cr3 WS 2009/10

18 Paging in Hardware Die Page Directory und Page Table haben die gleiche Struktur: Present Flag zeigt an, ob sich eine Seite im Hauptspeicher befindet. Die oberen (signifikanten) 20-Bits der physikalischen Adresse. Accessed Flag wird gesetzt, falls auf eine Seite zugegriffen wurde (wichtig für die Implementierung eines Seitenverdrängungsalgorithmus). Dirty Flag wird gesetzt, wenn die Seite verändert wurde. User/Supervisor Flag gibt an, welche CPU-Privilegien notwendig sind, um auf die Seite zuzugreifen. WS 2009/10

19 Paging in Hardware Die maximale Größe des physikalischen Speichers ist beschränkt durch die Anzahl der Adressleitungen, die mit dem Prozessor verbunden sind. Bei 32 (Bit) Adressleitungen sind das theoretisch 4 GB. Mit der Einführung des Pentium Pro Prozessors wurde die Physical Address Extension (PAE) eingeführt, die 36-Bit physikalische Adressen erlaubt und damit die Nutzung von theoretisch 64 GB RAM. Dadurch wird die Umsetzung von 32-Bit linearen Adressen in 36-bit physikalische Adressen komplizierter: 64 GB werden in 224 Seitenrahmen aufgeteilt. Die Einträge in den Seitentabellen wachsen von 32-Bit auf 64-Bit, da jetzt 24-Bit der physikalischen Adresse benötigt werden und weiterhin 12-Bits für Flags. Eine weitere Seitentabelle (Page Directory Pointer Table (PDPT)) wurde eingeführt. WS 2009/10

20 Paging in Hardware mit PAE
Eine 32-Bit lineare Adresse wird dann wie folgt interpretiert: Cr3 enthält die Adresse des PDPT (Page Directory Pointer Table). Bits enthalten einen von vier möglichen Einträgen im PDPT. Bits enthalten einen von 512 möglichen Einträgen im Page Directory. Bits enthalten einen von 512 möglichen Page Table Einträgen. Bits enthalten das Offset innerhalb einer 4 KB Seite. WS 2009/10

21 Paging in Linux Der Linux Kernel verwendet allgemein ein auf 64-Bit Plattformen übliches 3-stufiges Paging. Lineare Adresse Global Directory Middle Directory Table Offset Page Page Table Page Middle Directory Page Global Directory cr3 WS 2009/10

22 Paging in Linux Auf 32-Bit Architekturen muss das 3-stufige Paging Modell angepasst werden: Ist keine PAE Erweiterung vorhanden, so wird die Page Middle Directory Tabelle nicht genutzt. Ist die PAE Erweiterung verfügbar, so entspricht die Page Global Directory Tabelle der x86-Page Directory Pointer Table (PDPT). Weitere Designkriterien: Jedem Prozess werden unterschiedliche physikalische Adressbereiche zugeordnet. Zusätzlicher Schutz gegen Adressierungsfehler. Trennung von Seiten (Daten) und Seitenrahmen. So lassen sich Seiten auslagern und in einen anderen Rahmen zurückladen. WS 2009/10

23 Bootprozess Beim Einschalten des Computers ist dieser noch nicht gebrauchsfertig: Die Speicherchips enthalten zufällige Daten. Kein Betriebssystem ist geladen. Beim Einschalten wird Spannung an den Reset-Pin der CPU gelegt. Die CPU wird in den initialen Zustand versetzt. Ein spezielles ROM (read only memory) ist mit Programmcode bestückt und an einer speziellen Speicheradresse (physikalische Adresse 0xff ff ff f0) verfügbar. Das Programm im ROM wird i.d.R. als BIOS (Basic Input/Output System) bezeichnet und enthält spezielle hardwarenahe Programmroutinen. Die CPU beginnt mit der Ausführung der Instruktionen ab 0xff ff ff f0. WS 2009/10

24 Bootprozess x86 Real-Mode
Beim Start des Computers ist Paging deaktiviert und bietet nur eingeschränkte Segmentierung. Real-Mode Adressen haben das Format segment:offset. Beide Felder sind 16-Bit breit. Die physikalische Adresse errechnet sich dann: segment * 16 + offset, was einem 20-Bit Adressraum entspricht. Das BIOS sucht zunächst nach einem gültigen Boot-Medium. Der erste Sektor des gefundenen Boot-Mediums wird an die physikalische Adresse 0x c 00 geladen. Die CPU springt zu dieser Adresse und führt die dort liegenden Instruktionen aus. WS 2009/10

25 Bootprozess Im Bootsektor befindet sich ein Bootloader – Programm.
Dieses Programm lädt den Betriebssystem-Kern von der Platte in den Speicher (0x ). Dann werden Routinen zur Hardwareinitialisierung gestartet. Zu den ersten Schritten eines Betriebssystemkerns gehört der Aufbau des Speichermanagements. Eine initiale Seitentabellenstruktur mit 8 MB Adressraum wird initialisiert, und zwar so, dass die linearen Adressen sowohl im Real-Mode als auch später mit Paging auf die gleichen physikalischen Adressen übersetzt werden. Anschließend kann Hardware-Paging aktiviert und die endgültige Seitentabellenstruktur aufgebaut werden. WS 2009/10

26 Bootprozess x86 – Protected Mode
Speicherschutz Mittels Paging und durch Zugriffskontrolle auf Speicherseiten (user/superviser Flag) Read-Only Seiten Nur Code-Segmente können ausgeführt werden. Privilegierte Instruktionen Spezielle Ein-/Ausgabe Zugriffe (z.B. Hardware-Bus) Der Linux-Kernel definiert zwei lineare Adressbereiche: 0x bis 0x bf ff ff ff (Zugriff privilegiert und unprivilegiert). 0xc bis 0x ff ff ff ff (Zugriff ausschließlich privilegiert). WS 2009/10

27 Interrupts und Exceptions
Definition Interrupt Ereignis, das die von einem Prozessor ausgeführte Befehlsfolge unterbricht. Diese Ereignisse entsprechen elektrischen Signalen, die von Schaltkreisen innerhalb oder außerhalb der CPU erzeugt werden. Es werden synchrone und asynchrone Interrupts unterschieden. Synchrone Interrupts (hier Exceptions genannt): Werden von der CPU Kontrolleinheit erzeugt. Entstehen nur nach vollständiger Abarbeitung einer Maschineninstruktion. Asynchrone Interrupts: Werden durch andere Hardware zu einem beliebigen Zeitpunkt (jedoch Verwendung CPU-Takt) erzeugt. Beispiel: Ein Benutzer hat die Maus bewegt. WS 2009/10

28 IRQs und Interrupts Jede Hardware-Kontrolleinheit, die einen Interrupt auslösen kann (Interrupt ReQuest), hat eine Verbindung zu einer Interrupt-Kontrolleinheit. Die (programmierbare) Interrupt-Kontrolleinheit (PIC) Überwacht alle IRQ Verbindungen. Wird ein Signal an einer IRQ Verbindung festgestellt: Erfolgt die Umwandlung des Signals in einen Interrupt-Vektor, Hält Interrupt-Vektor am I/O-Ausgang für die CPU zum Lesen bereit, Sendet ein Signal an den INTR-Pin der CPU, Warte bis CPU Interrupt bestätigt. Die Kontrolleinheit ist „programmierbar“: IRQs können selektiv abgeschaltet werden. WS 2009/10

29 Exceptions Prozessor-Exceptions
Diese Unterbrechungen werden direkt durch den Prozessor generiert und können in drei Unterarten untergliedert werden: Faults können im Allgemeinen behoben werden. Wenn behoben, kann das Programm i.d.R. ohne Einschränkung weiterlaufen. Die Instruktion die den Fault verursacht hat wird wiederholt. Traps erzeugt einen Sprung in den Kernel. Sobald dieser die Kontrolle wieder abgibt, läuft der Prozess ohne Einschränkung mit der nächsten Instruktion weiter. Aborts werden bei schweren Fehlern ausgelöst. Das System befindet sich möglicherweise in einem inkonsistenten Zustand, so dass der laufende Prozess abgebrochen werden muss. WS 2009/10

30 Exceptions x86 Architektur mit Fehlercode (Signal)
Invalid TSS (fault) [SIGSEGV] Segment not present (fault) [SIGBUS] Stack exception (fault) [SIGBUS] General protection (fault) [SIGSEGV] Page fault (fault) [SIGSEGV] Intel reserved [None] Floting point error (fault) [SIGFPE] Alignment check (fault) [SIGBUS] Machine check (abort) [None] SIMD floating point (fault) [SIGFPE] 0. Devide Error (fault) [SIGFPE] Debugs (trap/fault) [SIGTRAP] unbenutzt [None] Breakpoint (trap) [SIGTRAP] Overflow (trap) [SIGSEGV] Bounds check (fault) [SIGSEGV] Invalid Opcode (fault) [SIGILL] Device not available (fault) [SIGSEGV] Double fault (abort) [SIGSEGV] Coprocessor segment overrun (abort) [SIGFPE] WS 2009/10

31 Bootprozess Fortsetzung
Eine Interrupt Descriptor Table (IDT) ordnet jedem Interrupt-Vektor und jeder Exception eine logische Sprungadresse zu einem Interrupt-Handler: Eine Software-Routine zur Behandlung einer Unterbrechung. Exception-Handler: Eine Software-Routine zur Behandlung einer Ausnahme. Die IDT kann überall im Speicher abgelegt werden; das idtr Register beinhaltet dessen Adresse. Die IDT muss vollständig initialisiert werden, bevor Interrupts angeschaltet werden. WS 2009/10

32 Hardware Behandlung von Interrupts und Exceptions
Nach dem Ausführen einer Instruktion enthält das Instruktionsregister (eip) die Adresse der nächsten auszuführenden Instruktion. Vor dessen Ausführung wird überprüft, ob ein Interrupt vorliegt (Signal an INTR-Pin der CPU). CPU liest Interrupt-Vektor (i) und liest den i-ten Eintrag der IDT. Der Segment-Deskriptor der logischen Sprungadresse wird geladen. Vergleich des aktuellen Privilegien-Levels mit dem notwendigen Level des Speichersegments: Falls notwendig erhöhe Privilegien-Level. Sichere aktuellen CPU-Zustand (insbesondere Instruktionspointer). Beginne mit der Ausführung des Interrupt- / Exception-Handlers. WS 2009/10

33 Interrupt-Handler Bearbeitung eines Interrupts durch das Betriebssystem Sicherung des aktuellen Prozesskontexts Bestätige Interruptbehandlung Ausführung des interruptspezifischen Codes (Interrupthandlers) PIC IRQn_interrupt() do_IRQ(n) Interrupt service routine 1 routine 2 IDT[32+n] Software (Interrupt Handler) Hardware INT Device 1 Device 2 IRQn WS 2009/10

34 Interrupt-Handler Interrupt-Handler sollten so schnell wie möglich bearbeitet werden. Z.B. Tastatureingabe sollte möglichst verzögerungsfrei erfolgen. Daher Aufteilung der Interruptbehandlung in: Top-half – Antwort auf Interrupt wird generiert, IRQ-Signal wird gelöscht. Ziel: möglichst schnelle Abarbeitung des Interrupthandlers. Bottom-half, soft-irq – Große und aufwändige Routinen werden, soweit möglich, in den normalen Schedule aufgenommen. Beispiel: Netzwerk Netzwerkkarte löst beim Empfang eines neuen Pakets ein Interrupt aus. Interrupt-Handler übernimmt Paketdaten und ermöglicht sofort den weiteren Empfang von Paketen. Markiert ausstehende Paketbehandlung. Die Bearbeitung des Pakets (IP -> TCP, UDP, ICMP …) später, da u.U. aufwändig. WS 2009/10

35 Bootprozess Fortsetzung
Zusammenfassung Start der BIOS-Routinen Laden des Kernels in den Speicher Initialisierung der Speicherverwaltung Segment-Deskriptoren werden initialisiert. Kernel Seitentabellen werden angelegt. Initialisierung von Interrupt- und Exception-Handler Interrupts können eingeschaltet werden. Was noch fehlt Start des Prozesses 1: /sbin/init WS 2009/10

36 Timer Eine besondere Art von Interrups sind Timer.
IBM-compatible PC-Systeme besitzen einen Programmable Interval Timer (PIT). Dieser löst periodisch (z.B. alle 10 ms) einen Interrupt aus (IRQ0). Die Timer-Interrupt Routine Aktualisiert die Systemzeit. Überprüft auf allen CPUs, ob der aktuell laufende Prozess, sein Zeit-Quantum aufgebraucht hat. Falls dies der Fall ist, wird der Prozess unterbrochen und der Scheduler aktiviert. Überprüft, ob ein schlafender Prozess geweckt werden muss. WS 2009/10

37 System-Aufrufe System-Aufrufe sind spezielle Anfragen von Benutzer-Prozessen an das Betriebssystem. Beispiel: Anfrage und Freigabe von Speicher (free() und malloc()) Öffnen, Lesen und Schreiben einer Datei (open(), read(), write()) Für die Bearbeitung des System-Aufrufs muss der aktuell laufende Prozess unterbrochen werden. in den Kernel-Kontext gewechselt werden. die Anfrage ausgeführt und der Prozess fortgesetzt werden. Software-Interrupt Analog zu Hardware-Interrupts Maschinenbefehl int 0x80 löst Interruptroutine 128 aus. WS 2009/10

38 Kernel-User Context Zusammenfassung:
Ein Wechsel zwischen Kernel- und User-Context kann durch drei Ereignisse erfolgen: Hardware-Interrupt / Exception Timer-Interrupt Software-Interrupt (System Aufruf) Process 1 Process 1 Process 2 Process 2 USER MODE KERNEL MODE System call handler Scheduler Interrupt handler System call Timer Interrupt Device Interrupt WS 2009/10

39 Evaluation Systeme 1 WS09/2010
Zur Veranstaltung Systeme 1 haben 27 Studierende ihre Meinung abgegeben. Allgemeines: 15 Studenten/Studentinnen schlagen Herrn Prof. Schneider für den Lehrpreis vor, da seine Vorlesung sehr interessant und witzig ist. Er vermittelt den Lehrstoff sehr verständlich und lässt viele praktische Beispiele einfließen. Die Weihnachtvorlesung kam bei den Studenten/Studentinnen sehr gut an. 24 Studenten/Studentinnen sind deutsch, ein Student stammt aus Luxemburg. Alle Studenten besuchen das 1. Semester mit der Studienrichtung „Informatik als Bachelor of Science“. WS 2009/10

40 Evaluation Systeme 1 WS09/2010
Fragen zur Veranstaltung: Alle Studenten/Studentinnen sprechen die Sprache deutsch. In der Lehrveranstaltung fühlen sich die Studierenden weder über- noch unterfordert. Auch die Stoffmenge wird überwiegend als nicht zu groß, aber auch nicht als zu klein beurteilt. WS 2009/10

41 Evaluation Systeme 1 WS09/2010
Fragen zur Veranstaltung: Was gefällt den Studenten/Studentinnen besonders gut an der Vorlesung? Die Vorlesung ist sehr praxisnah und eine gute Ergänzung zur praktischen und theoretischen Übung. Die Folien sind verständlich und sehr ausführlich. Außerdem wird gelobt, dass die Folien auch online stehen. Prof. Schneider vermittelt den Lehrstoff verständlich, interessant, strukturiert und sehr ausführlich und bringt sehr viele Beispiele. Kritikpunkte seitens der Studierenden: „Langweilige“ Themen werden zum Teil zu ausführlich behandelt. Eine Beschränkung auf das Wesentliche wäre ab und zu hilfreich. Einem Studenten/einer Studentin war die Bearbeitungszeit der Zwischenklausur zu kurz, drei Studenten/Studentinnen fanden die Korrekturdauer der Zwischenklausur zu lang. Zwei Studenten bedauern es, dass es nur eine Vorlesung in der Woche gibt. WS 2009/10

42 Evaluation Systeme 1 WS09/2010
Fragen zur Veranstaltung: Anregungen bzw. Verbesserungsvorschläge der Studierenden: Mehr Zeit in der Klausur oder weniger Aufgaben, Umfangreicheres Themengebiet, Die Verzahnung zwischen Vorlesung und Praktischer Übung ist grundsätzlich gut, könnte aber noch deutlicher hervorgehoben werden, In der praktischen Übung wären andere Themen wünschenswert. Fragen zu den Übungen: Die Übungsaufgaben werden von den Studenten/Studentinnen überwiegend (17) weder als zu schwierig noch als zu leicht eingestuft. 7 Studenten empfinden die Übungsaufgaben als schwierig, drei empfinden die Übungsaufgaben als leicht. Außerdem werden die Übungen von der Hälfte der Studenten/Studentinnen als sinnvolle Ergänzung zur Vorlesung angesehen. 4 Studenten/Studentinnen halten die Übungen sogar für sehr sinnvoll, 6 Studenten stehen den Übungen neutral gegenüber und 4 Studenten/Studentinnen halten die Übungen als Ergänzung zur Vorlesung als nicht so sinnvoll. WS 2009/10

43 Evaluation Systeme 1 WS09/2010
Fragen zu den Übungen: Die Erklärungen der Tutoren werden von einem Drittel der Studierenden als verständlich, von einem Drittel als gut verständlich und von einem weiteren Drittel als sehr gut verständlich bewertet. Die Größe der Übungsgruppen wird beinahe einstimmig als optimal angesehen. Die praktische Übung an sich sollte nach Meinung von zwei Studierenden ohne Anwesenheitspflicht durchgeführt werden. Nach Meinung eines Studenten sogar ganz abgeschafft werden. Ein Student/eine Studentin findet die praktische Übung gut, aber leider das Themengebiet langweilig, da er/ sie sich schon sehr gut auskennt. Ein Studierender findet Linux Befehle für Systeme eher irrelevant, dies sollte theoretisch vermittelt werden. Ein Student/eine Studentin findet es schade, dass die praktische Übung nicht so viel mit der Vorlesung zu tun hat. WS 2009/10