Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Axel BerghoffOpen Source Automation Development Lab (OSADL) eG
PHYTEC Messtechnik GmbH
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-Farm
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Was ist Open Source-Software? (1)
Software wird „Open Source-Software“ genannt, wenn diese von den Rechteinhabern unter eine Lizenz gestellt wurde, die in allen relevanten Eigenschaften die Bedingungen der Open Source Initiative (OSI) für den Lizenztyp “Open Source” erfüllt. Diese Bedingungen heißen Open Source Definition (OSD) und sind online verfügbar (http://opensource.org/osd).
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Was ist Open Source-Software? (2)
Wesentliche Kriterien der OSD für „Open Source“ sind:● Uneingeschränktes Recht zur Weitergabe der Software an
jedermann.● Weitergabe in Form von Objektcode muss erlaubt sein. In diesem Fall
muss der Quellcode entweder zusammen mit der Auslieferung oder später auf Anfrage verfügbar gemacht werden.
● Uneingeschränktes Recht, die Software zu verändern.● Uneingeschränktes Recht, veränderte Software an jedermann
weiterzugeben.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Warum ist das Open Source-Betriebssystem Linux so attraktiv für Embeded-Systeme?
● ... weil die Lizenzbedingungen gut geeignet sind. ● ... weil Linux kostenlos ist.● ... weil Linux so wenige Fehler aufweist.● ... weil Linux so weitgehend skaliert. ● ... weil Linux so viele Architekturen unterstützt. ● ... weil Linux bei Studienabgängern so gut bekannt ist.● ... weil Linux nicht abgekündigt werden kann.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Wesentliche Unterschiede zwischen Nicht-Open Source- und Open Source-Software
Nicht Open Source Open Source
Wer garantiert Fehlerbehebung?
Entwickelndes Unternehmen bzw. Vertriebspartner
Nicht der Entwickler, evtl. Vertriebsunternehmen
Wer garantiert Performance?
Entwickelndes Unternehmen bzw. Vertriebspartner
Nicht der Entwickler, evtl. Vertriebsunternehmen
Wer garantiert Anpassung?
Entwickelndes Unternehmen bzw. Vertriebspartner
Nicht der Entwickler, evtl. Vertriebsunternehmen
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Vertriebsunternehmen fürOpen Source-Software?
Kommerzieller Vertrieb für eine Open Source-Software lohnt sich immer nur dann, wenn eine bestimmte Softwareversion unverändert von einer großen Anzahl an Kunden verwendet wird. Da dies für Embedded-Systeme in der Regel nicht zutrifft, gibt es keine einheitlich vertriebene Standard-Linux-Distribution für alle Embedded-Systeme wie es z.B. für Server der Fall ist:
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Qualitätssicherung des Linuxkernels für Embedded-Systeme in der Medizintechnik
Da es keinen allgemein verwendbaren und als Produkt vertriebenen Linuxkernel für Embedded-Systeme in der Medizintechnik gibt, muss jeder Anwender selbst für die erforderliche Qualitätssicherung sorgen – oder sich einer geeigneten Organisation anschließen.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Was ist OSADL?
Das Open Source Automation Development Lab (OSADL) ist eine Interessengemeinschaft für industrielle Anwender von „Open Source“-Software:
OSADL entwickelt, beauftragt, koordiniert, kontrolliert und zertifiziert die Entwicklung von „Open Source“-Software im Auftrag seiner Mitglieder. Dazu gehört in besonderem Maße die Qualitätssicherung des Linuxkernels, wofür die sogenannte “OSADL QA-Farm” betrieben wird.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
OSADL-Mitgliederentwicklung
12/2005 12/2007 12/2009 12/2011 12/2013 12/20150
5
10
15
20
25
30
35
40
45
50
Num
ber o
f mem
bers
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Branchen der OSADL-Mitglieder
(Maschinen- undAnlagenbauer)
Halbleiter-Hersteller
Hardware-Hersteller
Software-Hersteller
FOSS/Linux-Dienstleister
Industrielle Anwender
Nutzervereinigungen
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Die OSADL QA-Farm (1)
OSADL Test-Racks für zur Zeit über hundertindividuelle Systeme
● 8 auswechselbare Tabletts ● Jeweils 220 V Stromversorgung, Ethernet, RS232● 10/100/1000 Mb/s Switch mit Port-Mirroring● 8-fach Fernsteuerung der Stromversorgung● 8-fach Seriell-zu-Netzwerk-Adapter● 8-fach fernsteuerbarer KVM-Switch (optional)● Kontroll-Server für Überwachung und als Lastgenerator
Pro Rack:
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Die OSADL QA-Farm (2)
Montage der individuellen Systeme auf speziellen Lochraster-Tabletts
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Die OSADL QA-Farm (3)
Kommunikation zwischen Testsystemen, Datenerfassung und Bedienpersonal
OSADL-Cloud
Testzentrum 1 Testzentrum 2
Datenerfassung
Auswertung,Bedienung
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Die OSADL QA-Farm (4)ARMBroadcom● BCM2708 @700 MHz, 32 bit
Freescale● i.MX27 @400 MHz, 32 bit● i.MX35 @532 MHz, 32 bit● i.MX6 @996 MHz, 32 bit
Marvell● SheevaPlug @1200 MHz, 32 bit
Texas Instruments● AM3517 @600 MHz, 32 bit● AM3359 @800 MHz, 32 bit● OMAP3525 @720 MHz, 32 bit● OMAP4430 @600 MHz, 32 bit
Xilinx● Zynq @666 MHz, 32 bit
MIPSICT● Loongson 2F @800 MHz, 64 bit
PowerPCFreescale● MPC 5200 @396 MHz, 32 bit● MPC 8349 @533 MHz, 32 bit● QorIQ 2020 @1200 MHz, 64 bit
x86/x86_64AMD● K6 3D, @333 MHz, 32 bit● LX-800 @500 MHz, 32 bit● Athlon XP 2000+, 32 bit● Athlon 64 2800+, 64 bit● G-Series T56N @1400 MHz, 64 bit● Phenom II X6 @3200 MHz, 64 bit● Opteron X32 @2100 MHz, 64 bit● Kaveri A10-7850K X4 @3700 MHz, 64 bit● Embedded Kaveri X4 @2700 MHz, 64 bit
Intel● Pentium @133 MHz, 32 bit ● Pentium II Klamath @233 MHz, 32 bit● Celeron (Coppermine) @800 MHz, 32 bit
Intel (Forts.)● Atom D510 @1667 MHz, 64 bit● Atom N270 @1600 MHz, 32 bit● Atom Z530 @1600 MHz, 32 bit● Celeron M @1500 MHz, 32 bit● Pentium M @2300 MHz, 32 bit● Xeon (single socket) @2000 MHz, 32 bit ● Xeon (dual socket) @2800 MHz, 32 bit ● Core 2 Duo @2400 MHz, 64 bit● Core 2 Quad @2400 MHz, 32 bit● Nehalem 975 @3333 MHz, 32 bit● Gulftown X980 @3333 MHz, 64 bit● Core i7-2600K @3400 MHz, 64 bit● Core i7-4960X @3600 MHz, 64 bit● Atom E3825 @1333 MHz, 64 bit
VIA● C3 Samuel 2 @533, 32 bit● C3 Nehemiah @533 MHz, 32 bit● C7 @1000 MHz, 32 bit● Nano X2 L4050 @1400 MHz, 64 bit● QuadCore L4700 @1200 MHz, 64 bit
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Wer nutzt die Farm wie?
● OSADL-Mitglieder können die Farm je nach Mitgliedslevel ohne Zusatzkosten nutzen.
● Nicht-Mitglieder können die Farm gegen Miete ebenfalls nutzen.● Zwei verschiedene Update-Kategorien
– „Monitoring“ (keinerlei Update)– „Kernel-Development“ (kontinuierliches Update auf aktuelle
Kernelversionen)
● Drei verschiedene Kategorien der Datenveröffentlichung– „Hidden“ (nur der Kunde hat Zugriff)– „Undisclosed” (öffentlich, aber ohne Namensnennung)– „Public” (öffentlich mit Namensnennung)
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Was ist das Ziel der OSADL QA-Farm?
● Erkennung von Fehlern des Linux-Kernels (speziell bei von der Industrie benötigen Komponenten)
● Transparente Auswahlkriterien für den am besten geeigneten Prozessors
● Ermittlung individueller Zuverlässigkeitsdaten● Gewinnung von Langzeitdaten für Zertifizierung, z.B.
Echtzeit● „Einfrieren und trotzdem weiterwachsen”
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
„Einfrieren und trotzdem weiterwachsen“
Einfrieren für Produktion
Weiterwachsenim Testzentrum
2.6.31.12-rt21
3.0.0-rt1Upgrade-Problem(dokumentiertoder behoben)
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Gemessene Variablen (1)Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance
Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device ● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive
Netzwerk● eth0 errors● eth0 traffic● Firewall Throughput● HTTP loadtime of a page● Netstat NFS● NFS Client ● NFSv4 Client
Prozesse● Fork rate ● Number of threads● Processes● Processes priority ● VMstat
Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance
Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device ● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive
Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance
Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive
Real-time system● 5-min max. timer and wakeup latency ● 5-min max. timer offsets● 5-min max. wakeup latency● RT Features
Sendmail● Sendmail email traffic● Sendmail email volumes● Sendmail queued mails
Sensoren● Fans● HDD temperature● Power consumption● Temperatures
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Gemessene Variablen (2)System● Available entropy● C states● CPU frequency● CPU usage● File table usage● Individual interrupts● Inode table usage● Interrupts and context switches● Kernel version● Load average● Logged in users● Memory usage● Split memory usage● Application memory usage● Swap in/out● Uptime
Virtuelle Systeme● Virtual domain block device I/O● Virtual domain CPU time● Virtual domain memory usage● Virtual domain network I/O
Zeit-Synchronisation● NTP kernel PLL estimated error (secs)● NTP kernel PLL frequency (ppm + 0)● NTP kernel PLL offset (secs)● NTP states● NTP timing statistics for system peer
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Markierung von Warnung und Alarm mit Munin
Rot: Alarm, gelb: Warnung, blau: Messung im Normalbereich
Name des Systems Direkter Link zu den Variablen einer Gruppe
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Vier verschiedene zeitliche Auflösungen
Tag Woche
Monat Jahr
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Ereignis-Verwaltung mit Nagios
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Ereignis-Histogramme mit Nagios
Mit Ereignis-Histogrammen lässt sich leicht feststellen, ob bestimmte Fehler z.B. immer zu bestimmten Uhrzeiten, Wochentagen oder
Monatstagen auftreten.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
CPU- und Graphik-Benchmarks
Rot: geringe Performance, gelb: mittlere Performance, grün: hohe Performance
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Memory-Leak Diagnostik (1)
Normal (kein Leak)
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Memory-Leak Diagnostik (2)
System-Leak Applikations-LeakKeilförmiger Anstieg von Speicherbereichen: Alarm!
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Stabilitätsmessung (1)
30 Stunden
1,25Tage
Bei jedem Neustart des Systems beginnt die Zählung der Uptime bei 0.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Stabilitätsmessung (2)
13 Monate
437 Tage
5 Wochen
Etablierter single-core ARM Prozessor,Texas Instruments AM3517 @500 MHz
Neustart im April 2013 für Update
Dual-core ARM processor,Texas Instruments Pandaboard @1000 MHz
Livelock Linux Bug
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Stabilitätsmessung (3) und Bugfix
5 Wochen 13 Monate
Bugfix
Nach Analyse des Fehlers in der QA Farm wurde von OSADL ein Bugfix bereitgestellt und eingespielt, danach war das System stabil.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Messung von Leistungsaufnahme und Taktfrequenz der CPU
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Messung von Leistungsaufnahme und Schlafstadien der CPU
Durch gezielte Maß-nahmen (Taktfrequenz bzw. Schlafstadien der CPU) basierend auf den Daten der QA-Farm lässt sich möglicherweise Energie in erheblichem Maße einsparen.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Prinzip einer EchtzeitmessungExternes Ereignis,
z.B. von einer LichtschrankeStart der Applikation
Im Userspace
Scheduling,Kontext-Wechsel
Interrupt ServiceRoutine
Gesamt-Latenz oder Präemptions-Latenz
IRQ-Latenz
Gatter-Latenz
CPUIRQ
3 3 9 15
6
30
Wie lange dauert es, bis ein externes Ereignis vom System verarbeitet wird und eine wartende Userspace-Applikation dies erfährt?
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Ergebnis einer Echtzeitmessung
Fast 100 Millionen Mal sehr schnell (etwa 10 µs)
Ein einziges Mal 55 µs, dies ist die Latenz des Systems
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Ergebnis einer Langzeit-Echtzeitmessung (1)
Konsekutive Latenzplots ingemeinsamer Darstellung
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Beispiel: Ergebnis einer Langzeit-Echtzeitmessung (2)
Bereits ein einziger Ausreißer in20 Milliarden Messungen kann erfasst und dargestellt werden.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Zusammenfassung (1)
● Lizenzen von Open Source-Software gewähren in sehr großzügiger Weise Nutzungsrechte.
● Allerdings sind in dieser Lizenz keinerlei Zusagen im Hinblick auf Fehler-behebung, Performance, oder Anpassungsarbeiten enthalten. Hierfür ist jeder Anwender zunächst selbst verantwortlich; die eigentlichen Arbeiten sollten aber – genau wie die Entwicklung von Open Source-Software – in einer Community erfolgen. Unter anderem für diesen Zweck wurde das Open Source Automation Development Lab (OSADL) gegründet.
Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014
Zusammenfassung (2)
● Die OSADL-QA-Farm (osadl.org/QA) bietet Referenz-Daten für eine große Anzahl von Prozessor-Architekturen und Konfigurationen. Darüber hinaus können (und müssen) die Daten der Farm genutzt werden, um Fehler an der getesteten Hardware und Software zu beseitigen bzw. deren Performance zu verbessern.
● OSADL ist bereit, die Erfahrungen aus dem nunmehr vierjährigen Betrieb der Farm an interessierte Unternehmen weiterzugeben.