Archiv der Kategorie: BSD

Streaming-Audio-Server – Ein Versuch

Veröffentlicht am von
Antworten

Die Folge 39.5 von Anfang September mit dem Thema „Mein eigener Server“ des c’t Uplink Podcasts hat auch bei mir wieder Lust auf einen eigenen Home-Server geweckt. In den letzten zwölf Monaten habe ich verstärkt auf meine digital gespeicherte Musiksammlung – also im Wesentlichen MP3-Dateien – zurückgegriffen. Sei es, weil mein einfacher, kleiner MP3-Player unerwartet kaputtgegangen ist und ich mir einen neuen kaufte, ohne dass ich die Ordnerstruktur mit den Musikdateien vorher noch vom alten Player auf einem Computer zwischenspeichern konnte, oder weil mein Hörinteresse insgesamt in dem benannten Zeitraum auch wieder von den Podcasts weg zu mehr Musik gewandert ist. Anders als viele andere möchte ich aber kein Network Attached Storage (kurz NAS) betreiben und habe es auch bisher noch nicht. Stattdessen habe ich die archivierten Dateien auf einer externen Festplatte gespeichert, wie viele einfache Computernutzer es auch handhaben. – Allerdings mit dem Unterschied, dass ich sie auf zwei externen Festplatten gespeichert habe, um immer wenigstens noch einen redundanten Datenträger zu haben, falls eine kaputtgeht. Der Nachteil gegenüber einem NAS ist aber, dass ich nicht von jedem Gerät immer sofort auf die Dateien zurückgreifen kann. Das liegt zum einen daran, dass die Gehäuse der externen Festplatten unterschiedliche Schnittstellen haben, und zum anderen daran, dass sie mit einem Apple Dateisystem formatiert sind. Je nach Computer und dem darauf installiertem Betriebssystem kann ich also nicht eine der externen Medien immer direkt anschließen, an dem ich sie verarbeiten möchte. Ich muss sie also immer an einen bestimmten Mac mit der richtigen Schnittstelle anschließen und die Dateien mittels einem flexibleren Wechseldatenträger wie einem mit dem Dateisystem exFAT formatierten USB-Stick auf meinen Zielcomputer übertragen, was sehr umständlich und zeitraubend ist. Ich muss nicht immer regelmäßig auf alle meine archivierten Dateien zugreifen, aber da es sich bei denen, wo es in letzter Zeit der Fall ist, um Audio-Dateien handelt, liegt doch der Gedanke nahe, einen Streaming-Server für Musik zu bauen, von dessen mit jedem Gerät sofort die gewünschte Musik abgespielt werden kann. Das sorgt außerdem dafür, dass wenn die Dateien nicht auf dem Endgerät vorhanden sind, sie auch nicht den begrenzten Festspeicherplatz des Endgeräts in Anspruch nehmen und auch die Backups dieser unnötig vergrößern.

Vor dreizehn Jahren habe ich mir für meinen ersten Home-Server das Alix.1C Embedded Board von PC Engines angeschafft. Anfangs einige Zeit mit NetBSD und später durchgängig mit OpenBSD betrieben, diente der Computer für irssi in einer Screen-Session, dann mal als Konsolen-Torrent-Client oder Tor Middle-Node und war meistens über dynamischen DNS aus dem öffentlichen Internet im eigenen Heimnetzwerk erreichbar. Auf die 32 Gigabyte CompactFlash-Karte, die ich einige Jahre später dazu gekauft habe, würde ich meine MP3-Sammlung zwar gespeichert bekommen, aber die Karten sind in ihrer Lese- und Schreibgeschwindigkeit sehr langsam gegenüber den moderneren Festplatten (späte IDE- und generell SATA-Laufwerke). Zum Glück habe ich aber noch irgendwo eine gebrauchte SATA-SSD mit 256 Gigabyte Speicherkapazität herumliegen. Da die Alix-Boards noch einen 44-Pin IDE Port für 2,5″ IDE-Laufwerke besitzt, bin ich das Wagnis eingegangen und habe mir für 12 Euro mal einen 2,5 Zoll SATA (Female) HDD Drive auf IDE 44 Pin Konverter bestellt. Ich war anfangs etwas skeptisch, aber so ein SATA auf 44 Pin IDE-Konverter funktioniert doch problemlos. Der einzige Nachteil, der durch den Konverter entstanden ist, ist der, dass er mit dem 2,5″ Medium die Höhe des schmalen Gehäuses etwas überschreitet und ich das System nicht mehr geschlossen bekomme. Das SATA-Medium wird durch den IDE-Controller vom Board wie ein IDE-Medium erkannt und angesteuert.

ALIX.1C Innenansicht

Ich habe in den letzten vier Jahren das Alix-System zwar nicht mehr nennenswert im Einsatz gehabt, aber vor gut zwei Jahren musste ich feststellen, dass das System von dem OpenBSD Installations-Image auf einem USB-Stick spätestens seit der damaligen Version 6.5 nicht mehr in der Lage ist zu booten. Was der Grund für den Fehler ist, konnte ich bis jetzt nicht herausfinden. Auch der Versuch von einem OpenBSD Installations-Image für die x86 64-Bit statt der x86 32-Bit hat nicht geholfen und die Gesamtsituation hat sich bis zu der vor gut zwei Wochen erschienen OpenBSD Version 7.0 nicht gebessert. Zum Glück hatte ich mir zu Anfang dieses Jahres die be quit! Bastel- und Retro-Workstation zusammengebaut, um von dem Installationsmedium aus zu booten und das System auf den Zieldatenträger zu übertragen. Der erste Boot-Vorgang von dem Zieldatenträger als Hauptdatenträger im Alix-System funktioniert dann zum Glück wieder fehlerfrei, sodass die weitere Konfiguration damit kein Problem darstellt.

2,5 Zoll SATA (Female) HDD Drive auf IDE 44 Pin Konverter

Mit dem nun nach wie vor unter OpenBSD betriebenen Alix-System als wirklich sinnvollen Home-Server habe ich mir auch das Ziel gesetzt, einen eigenen benutzerdefinierten Kernel zu kompilieren. Die Standard-Kernel der drei großen bekannten BSD-Systeme sind zwar schon wesentlich kleiner als die der großen bekannten Linux-Distributionen, aber in Hinblick darauf, dass das Alix-System nur 256 MiB Arbeitsspeicher besitzt, finde ich es nicht verkehrt, es noch Resourcen-schonender zu konfigurieren. Bisher hatte ich benutzerdefinierte Kernel unter NetBSD und zu Anfangs mal kurz unter FreeBSD erstellt. Die Verfahrensweisen und Abläufe sind aber prinzipiell bei allen BSD-Betriebssystemen identisch. Bei meinem jetzt unter OpenBSD 7.0 selbsterstellten Kernel habe ich die Treiber für alle auf dem Alix-Board verbauten Hardware-Komponenten beibehalten und alle diejenigen entfernt, die auch nicht auf dem Board verbaut wurden. Zusätzlich habe ich noch die Unterstützung für einige Dateisysteme entfernt, mit denen ich hier zu Hause eh nicht (mehr) mit dem Alix-System in Berührung kommen könnte (Linux ext2, UDF, CD9660 und NFS). Außerdem habe ich die Software-RAID Funktionalität entfernt und die Farbgebung für Kernel-Ausgaben auf den seriellen Konsolen von der standardisierten weißen Schrift auf blauen Hintergrund zu der für mich angenehmer zu lesenden weißen Schrift auf schwarzem Hintergrund. Ich hätte gerne noch alle Funktionalitäten des Point-to-Point Netzwerkprotokolls und die Unterstützung der VPN-Protokolle entfernt, aber der Kernel hat auf der Standardausgabe während des Boot-Vorgangs (noch) zu viele Fehler geworfen, auch wenn der Rest trotzdem funktioniert hätte. Trotzdem konnte ich die Größe des Kernels signifikant verkleinern. War die ausführbare Kernel-Datei des generischen Kernels noch fast 15 Megabyte groß, war die Datei meines Kernels nur fast 5 Megabyte groß. Während der generische Standard-Kernel im Arbeitsspeicher 20 Megabyte belegte, benötigte mein Kernel nur noch die Hälfte im RAM. Für die Statistik: Da der AMD Geode LX Prozessor – bassierend auf AMDs K7 Mikroarchitektur – nur 500 Megahertz, 2 mal 64 KiB Level-2 und nur 128 KiB Level-2 Cache besitzt, dauert der Kompiliervorgang des generischen Standard-Kernels von OpenBSD 7.0 zwei Stunden und 55 Minuten. Der Kompiliervorgang meiner Kernel-Konfiguration hat dann nur noch 41 Minuten gedauert.

Ich habe mir gedacht, dass es prinzipiell nicht verkehrt sein kann, dass auf dem Alix-Home-Server auf alle Fälle auch ein FTP-Server verfügbar sein sollte, denn schließlich will ich die MP3-Dateien von der an einen meiner Mac’s angeschlossenen, externen Festplatte auf den zukünftigen Musik-Streaming-Server übertragen, beziehungsweise die MP3-Dateien auf einen mobilen Computer oder Abspielgerät für unterwegs herunterladen. – Wie gesagt, ich möchte nicht immer jedes Mal eine der beiden externen HDDs herauskramen müssen.

ALIX.1C mit SATA zu 44 Pin IDE Konverter und 2,5″ SATA-HDD

Da ich mich alleine in meinem privaten Heimnetz befinde, habe ich auf eine Transportverschlüsselung für FTP verzichtet. Nachdem ich meine MP3-Sammlung also via FTP auf dem Server transferiert habe, musste ich feststellen, dass beim Versuch die MP3s via FTP zu lesen und wieder auf ein Endgerät zu kopieren, der FTP-Client bei einigen Dateien Fehlermeldungen ausgab. Offensichtlich sind bei dem Transfer der Dateien auf den FTP-Server bei den betroffenen Dateien einige Bits gekippt. Erst nachdem ich auf dem FTP-Server die Sammlung gelöscht und anschließend die Dateien statt via FTP mit scp erneut auf den Server transferiert habe, funktionierten sie auch alle ausnahmslos. Die effektive Transferrate bei scp ist allerdings etwas geringer als bei FTP, sodass der Datei-Transfer auch etwas länger dauert, aber das macht nichts.
Für den eigentlichen Streaming-Audio-Server hatte ich mir zwei Software-Lösungen ausgesucht.: Den Icecast, welcher von Internetradios gern für das Streamen verwendet wird, und die Media-Streaming-Weboberfläche Ampache.

  • Ampache: Ampache ist ein Kofferwort aus Amplifire und dem bekannten Web-Server Apache. Mit Ampache kann man seine Musik-Bibliothek verwalten, ähnlich wie mit iTunes und bietet verschiedene Berechtigungsstufen. Es ist aber auch möglich, eine Playliste als reinen HTTP-Stream in einem Netzwerk zur Verfügung zu stellen. Von den Entwicklern wird nur Linux und FreeBSD unterstützt. Unter FreeBSD habe ich Ampache nicht zum Laufen bekommen, sondern leider nur unter einem Debian 10 Buster, was schon unter die Kategorie old-stable fällt. Ich hatte mir schon gedacht, dass die 500 Megahertz und 256 MiB RAM der Alix zu wenig sind für Webserver, PHP und SQL-Datenbank sind. Die ganze Implementation ist zwar nicht sehr schnell, aber es funktioniert wie es soll. Problematisch bei der begrenzten Rechenleistung wird es aber mit ffmpeg. Bei einer MP3-Datei mit 320 kbps und einer Spielzeit von zwei Stunden hat sich dann der ffmpeg-Enkoder verschluckt und der Prozessor lief am Limit. Konnte Ampache dann wieder andere, kleinere MP3-Dateien mit ffmpeg verarbeitenund abspielen, sah es so aus, dass von den großen MP3s noch ffmpeg-Zombieprozesse übrig blieben, die es zu killen galt. Für das Alix-System dann doch keine so zufriedenstellende Lösung.
  • Der Icecast-Server ist prinzipiell so ausgelegt, dass er aus einer Audioquelle an der Soundkarte einen HTTP-Livestream ins Netz stellt. Icecast kann aber auch von Audio-Dateien einen Stream erzeugen. Dafür ist eine Textdatei nötig, die als Playliste fungiert. Um sich spontan eine Liste zusammen zustellen ist dies aber doch etwas umständlich. Da auch Icecast sich ffmpeg bedient, wird das auch hier wieder der Bottleneck bei großen Audio-Dateien sein, auch wenn Datenbank und PHP nicht nötig sind.

Da ich auf meinen Desktop-Computern relativ kleine und schlanke Medienplayer mit einer einfachen Listenfunktionalität benutze, die Drag-and-drop fähig sind, wollte ich mal ausprobieren, wie diese damit klarkommen, wenn sie direkt auf die Dateien von einem gemounteten FTP-Share zugreifen sollen. Sowohl der ältere Cog als auch der moderne IINA laden alle Dateien immer vollständig. Sind es viele auf einmal wie zum Beispiel ein Ordner mit 200 Stück, sind die Player je nach Menge zu Anfangs immer etwas ausgelastet. Der Vorteil: alle ID3-Tags und weitere Meta-Daten wie Album-Cover sind verfügbar. Der Nachteil ist, dass das Hörvergnügen zu Anfangs kurze Startschwierigkeiten haben kann.
Der VLC Media Player verhält sich da schon ganz anders. Bei dem Lesen der Dateien von einem FTP-Share wendet dieser tatsächlich das Streaming-Prinzip an. Das heißt, dass er kontinuierlich immer nur das benötigte Stück der Audio-Datei lädt. Damit werden die langen Ladezeiten eliminiert. Die Nachteile sind aber, dass er erstens die Meta-Daten von den Dateien nicht lädt, zweitens kommt der VLC überhaupt nicht damit klar, wenn die Dateinamen sich mit Zeichen aus der aktuellen UTF-Implementation bedienen, die nicht mit den Buchstaben des ASCII-Codes übereinstimmen. Kurz gesagt: enthält der Dateiname beispielsweise einen Akzent über einem Vokal oder er enthält einen kyrillischen Buchstaben, kann der VLC Media Player die Datei nicht lesen.

Fazit:
Alles in allem ist die Lösung, dass ich mit einem lokalem Medienplayer auf einem meiner Endgeräte auf die Dateien via FTP zugreife, für mich zurzeit die am gangbarsten. Allerdings werde ich extra für den VLC Media Player jetzt nicht alle Dateinamen mit Buchstaben aus dem ASCII-Zeichensatz ersetzen.

Links:

MacPorts macOS Big Sur clang Error Code 77

Veröffentlicht am von

Nach meinem Upgrade von macOS 10.15 Catalina auf macOS 11 Big Sur und der darauffolgenden Installation der aktuellen MacPorts habe ich bei einem Paket vom Compiler folgenden Fehler bekommen.:

% sudo port install gd2
Warning: The macOS 11.0 SDK does not appear to be installed. Ports may not build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by running `xcode-select --install'.
Computing dependencies for gd2
Fetching archive for gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from https://kmq.jp.packages.macports.org/gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from https://packages.macports.org/gd2
Configuring gd2<br>Error: Failed to configure gd2, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gd2/gd2/work/libgd-2.3.0/config.log
Error: Failed to configure gd2: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gd2/gd2/main.
Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gd2 failed

Dem Log-File war zu entnehmen, dass der Compiler mit dem Error-Code 77 den Kompiliervorgang abgebrochen hatte. Was mich aber verwundert hatte, war, dass obwohl das aktuelle macOS 11.0 SDK und die Xcode Command Line Tools installiert waren, mir der Lösungsvorschlag präsentierte wurde, die Xcode Command Line Tools zu installieren. Nach etwas Recherche im Internet bin ich auf einen einfachen wie effektiven Lösungsvorschlag gekommen. Einfach die löschen und erneut installieren.

sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install

Links:

Commandlinefu

Veröffentlicht am von

Als ich im vergangenen Herbst nach einer Lösung im Internet recherchiert habe, um eine Audio-Datei (wav, mp3, etc.) aus der Tonspur einer DVD zu erzeugen, bin ich in meinen Suchergebnissen über Beispiele für Kommandozeilen-Befehle auf der Website www.commandlinefu.com aufmerksam geworden. Bei Commandlinefu kann jeder nach der Registrierung einen kleinen Beitrag einstellen für einen Kommandozeilen-Befehl den er oder sie als erwähnenswert erachtet. Dabei wurden – und werden Befehle präsentiert, die entweder etwas Praktisches, etwas Nützliches, etwas Interessantes oder einfach nur etwas Witziges ausführen.
So gab es bis vor etwa zehn Jahren alternative Beispiele, wie sich ein öffentlicher SSH-Schlüssel auf einem Ziel-Host in die Datei ~/.ssh/authorized_keys einfügen lässt. Hintergrund war, dass Apple zwar die vollständige SSH-Suite seit Beginn von Mac OS X als festes Bestandteil integriert hat, aber über etliche Versionen hat das Programm ssh-copy-id gefehlt. So wurden alternative Wege erarbeitet, die mit Hilfe der Standard-Unix-Tools den Schlüssel über ein einziges Shell-Kommando auf den Ziel-Host brachten.xx
Ich habe mal angefangen, ein wenig in der mittlerweile über fast 12 Jahre alten Sammlung zu stöbern und eine wirklich kleine Auswahl in meinem Wiki gesammelt. Aber es steckt noch viel Potenzial in der Sammlung weitere Befehls-Schätze zu entdecken. Es braucht nur etwas Internet und vielleicht einen halben oder ganzen Tag, an dem sich nichts sinnvolleres mit der vorhandenen Freizeit anstellen lässt.
Es gibt im übrigen auch einen Twitter-Account zu Commandlinefu, der einem über einen neuen Beitrag informiert.

Links:

Emulation einer VAX mit SIMH: NetBSD

Veröffentlicht am von

NetBSD ist ein unixoides Betriebssystem, bei dem die einzelnen Komponenten des Userland mit den Fähigkeiten des Kernels optimal abgestimmt sind. Dies wird dadurch erreicht, dass der Kernel und fast das ganze Userland aus einer Hand stammen. Großer Wert wird darauf gelegt, dass sich das System auf allen Architekturen gleich verhält. NetBSD versteht sich sowieso darauf, auf vielen Computer-Architekturen ausgeführt werden zu können, von denen inzwischen viele einen historischen Charakter haben. – Nicht umsonst gibt es den alten Witz.: ‚NetBSD läuft auf allen Geräten. Selbst auf einem Toaster.‘

Die Portierung von NetBSD auf die VAX-Architektur der Digital Equipment Corporation war erstmals mit der NetBSD-Version 1.2 im Oktober 1996 abgeschlossen. Seitdem wird der VAX-Port kontinuierlich weiter entwickelt. Trotzdem ist NetBSD ein modernes Betriebssystem am Puls der Zeit. So war NetBSD auch das erste unter den Open Source-Betriebssystemen, welches die USB-Schnittstelle mit der Version 1.4 im Mai 1999 unterstützte. Selbst unter Linux wurde die Unterstützung für USB erst mit Kernel 2.4 im Januar 2001 realisiert.

Boot NetBSD 9.1 MicroVAX 3900 1
Boot NetBSD 9.1 MicroVAX 3900

Ich selber habe meinen ersten Kontakt mit NetBSD mit Erscheinen der Version 4.0 aufgenommen. – Das war im Jahr 2008. Motivation war damals für mich, dass das Betriebssystem selber nur aus einem kleinen Basissatz mit den wichtigsten Programmen (also dem Useland) besteht und so trotz Fehlen einer grafischen Benutzeroberfläche mit Maus, stattdessen mit einer ncurses-ähnlichen Menü-Steuerung extrem fix auf dem Computer installiert werden kann. Nach dem ersten Boot auf das installierte System war und ist man nur mit dem vi als Texteditor ausgestattet, gezwungen das System durch editieren von Dateien und den Kommandozeilenprogrammen des Basissystems zu konfigurieren und sich einzurichten. Das war für mich der Hebel, einen Zugang zu der Shell zu bekommen. Schneller und deutlich angenehmer als, wenn ich mich zum Beispiel mit Linux From Scratch erst einmal durch lange Anleitungen lesen hätte müssen und die nötigen Programme sowie Bibliotheken aus dem Sorce-Code erst in Binädaten kompiliert werden müssen.

Inzwischen ist das Programm sysinstall – so heißt der ncurses-ähnliche Installer nämlich – nochmals verbessert worden. So lassen sich über ihn inzwischen unter anderem auch die Quellpfade für die pre-kompilierten Programmpakete sowie das Archiv der Programmpakete mit dem Quellcode konfigurieren und beziehen, den lokalen NTP-Zeitserver aktivieren, den Displaymanager xdm für den automatischen, grafischen Login systemweit aktivieren oder einen eingeschränkten User-Account erstellen.
Im Prinzip verläuft die Installation und Einrichtung des Systems auf der VAX-Architektur genau so wie bei der x86 PC-Version (32 und 64 Bit). Das einzige, was im Gegensatz zu den x86 PC-Versionen zum Glück wegfällt, ist die Partition mit der MBR-/GPT-Formatierung. Während des Boots des Installationsmediums muss aber noch ein Terminal ausgewählt werden, sonst kann verständlicherweise das sysinstall-Programm nicht starten. – Es stehen als Terminal-Emulation VT100, VT220, Ansi und XTerm zur Verfügung, wobei die Darstellung von der Ansi-Emulation im SIMH-Emulator absolut furchtbar aussieht.
War ich nach der Installation von dem NetBSD 7.x im SIMH ziemlich angenervt, weil der Init-Prozess bei jedem Booten von der HDD nach der gewünschten Terminal-Emulation fragt, wird bei NetBSD 9.x das System ohne der Emulation gestartet. Es kann sein, dass da die Skripte vor Veröffentlichung nicht vollständig implementiert wurden. Die Umgebungsvariable muss also nachträglich noch händisch gesetzt werden.

In meinem Doku-Wiki habe ich die knappe Konfigurationsdatei für die SIMH-Emulation für NetBSD dokumentiert.

Boot NetBSD 9.1 MicroVAX 3900 2
Login NetBSD 9.1 MicroVAX 3900

Da zum heutigen Veröffentlichungszeitpunkt dieses Beitrags NetBSD 9.1 erst 12 Tage zur Verfügung steht, wurden noch keine pre-kompilierten pkgsrc-Programmpakete für den VAX-Port auf den Servern zur Verfügung gestellt. Waren für NetBSD 8.2 noch 476 Binärpakete verfügbar, gibt es für NetBSD 9.0 nur noch 26 Pakete zur Auswahl. Ich denke, dass aufgrund der aus heutiger Sicht extrem begrenzten Leistungsfähigkeit der VAX-Architektur die Computermodelle längst nicht mehr auch nur für halbwegs sinnvolle Aufgabengebiete eingesetzt werden können, wird an der Menge der angebotenen Programmpakete auch kein Zuwachs mehr zu erwarten sein.
Der NetBSD-User John Klos hatte mal das Experiment gewagt und auf seiner VAXStation 4000/VLC mit 24 Megabyte RAM unter Version 9.0 Perl in der Version 5.30.3 aus den Quellen kompiliert. Das Kompilat stand erst nach exakt 9 Tagen, 15 Stunden, 6 Minuten und 48 Sekunden zur Verfügung.

Mit der Veröffentlichung von Version 2.8 war im Dezember 2000 die Portierung von OpenBSD auf DECs VAX-Architektur abgeschlossen und die Weiterentwicklung begonnen. OpenBSD selber ist von dem ehemaligen NetBSD-Mitinitiator und -entwickler Theo de Raadt im Jahr 1995 gegründet worden, nachdem dieser von seiner ehemaligen Community ausgeschlossen wurde. Nach der Veröffentlichung von Version 5.8 im Jahr 2015 wurde dann die Weiterentwicklung von OpenBSD auf die VAX-Reihe wieder aufgegeben.

Links:

Emulation einer VAX mit SIMH: Die Hardware

Veröffentlicht am von

Der Host – Der Computer auf dem SIMH ausgeführt wird

Nachdem ich meine ersten Gehversuche in der Emulation der (Micro-) VAX unter SIMH unternommen habe um in DEC’s Betriebssysteme ULTRIX und OpenVMS hineinschnuppern zu können, sowie auch bereits der Gedanke in mir aufkeimte, gleich eine Artikel-Serie daraus zu stricken, hatte ich die Möglichkeit für lau einen Laptop zu übernehmen. Dabei handelt es sich um einen Acer Aspire 7530, welcher vermutlich im Mai 2008 auf den Markt gebracht wurde. Ausgestattet ist das Gerät mit einem AMD Athlon X2 Dual Core QL-60, welcher mit 1,9 GHz getaktet wird und der zwei mal 64 KB Level 1 Cache, sowie 512 KB Level 2 Cache für jeden der beiden Kerne besitzt. Damit ist die CPU-Leistung für diesen dicken, schweren 17″-Laptop (von den Maßen und der Tastatur eigentlich schon eine Mobile-Workstation) laut der damaligen Fachpresse recht mager. Zur sonstigen Ausstattung gehörten 3 GB DDR2 RAM, von dem bis zu 256 MB Video-RAM für die auch eher seinerzeit schwache nVidea GeForce 9400M abgezweigt werden können, und eine 320 GB Festplatte. Die weiteren technischen Merkmale habe ich in meinem Wiki in der Auflistung meiner PC-Familie aufgelistet, waren aber seinerseits bei Marktstart des Gerätes alle marktüblich, spielen dennoch aber für meinen Einsatzzweck keine Rolle.

Nach Erhalt des Gerätes bin ich erst einmal hingegangen und habe für etwas mehr als 20,- Euro noch ein 2 GB Speichermodul gekauft und eingebaut, weil ich der Überzeugung bin, dass ein Computer Arbeitsspeicher nicht genug haben kann. So hat das Gerät nun 4 Gigabyte statt der ursprünglichen etwas krummen 3 Gigabyte. Beim Betrieb dann mit Linux unter Verwendung von LXDE als Window-Manager hat sich dann deutlich heraus gestellt, dass die CPU-Leistung der deutlich limitierender Leistungsfaktor ist, und weniger die Menge des Arbeitsspeichers. Da ich auf meinen Apple-Macs leider die Treiber für TUN/TAP und vde2 nicht korrekt installieren konnte, bin ich doch froh einen separaten Computer zu haben, den ich in erster Linie nur für das Ausführen von SIMH nutzen kann. Von daher ist es erstmal nicht so schlimm, dass modernere Betriebssystem wie ein aktuelles NetBSD unter einer emulierten Digital VAX auf dem Acer-Laptop recht träge gegenüber meinen leistungsfähigeren Macs laufen. Auf dem Acer-Laptop habe ich Debian-Linux als Host-Betriebssystem installiert, wo der TUN/TAP-Treiber vernünftig läuft und die Programm-Pakete auch besser aufeinander abgestimmt sind.

Links:

Die MicroVAX 3900 von DEC als emulierte Computer

Die VAX im allgemeinen (kurz für Virtual Address eXtension) ist eine von der Digital Equipment Corporation entwickelte 32 Bit Rechnerarchitektur. Die 32 Bit VAX-Prozessoren besitzen einen CISC-Befehlssatz. Für die VAX-Reihe hatte DEC auch passend zu der Architektur das Betriebssystem VMS (kurz Virtual Memory System, später OpenVMS) mitentwickelt und auf den Markt gebracht. – Inzwischen wurde und wird auch das Betriebssystem OpenVMS durch die Firma Hewlett Packard Enterprise zu einem 64 Bit System weiter entwickelt. – Auch lässt sich inzwischen auf den Computern der VAX-Reihe NetBSD und Linux betreiben. Es wurde von OpenBSD auch eine Portierung für die VAX-Computer entwickelt, aber diese wurde in ihrer Weiterentwicklung mit OpenBSD 5.9 im Jahr 2016 wieder eingestellt. Ich bin mir aber auch nicht sicher, ob inzwischen die Weiterentwicklung der Portierung von Linux auf die VAX-Architektur wieder bereits eingestellt wurde.

In der stabilen SIMH-Version 3.x wurde die von Digital Equipment Corporation als ersten Computer der VAX-Reihe auf dem Markt eingeführte VAX 11/780 aus dem Jahr 1977 und das im Jahr 1989 wesentlich kleinere Model, die MicroVAX 3900 implementiert. Da die VAX 11/780 das erste Modell der VAX-Familie war, hat Digitial im Laufe der Jahre einen eigenen Benchmark für die hinzugekommenen Modell (-Reihen) geschaffen.: den VUP. VUP steht für VAX Unit of Performance, bei dem das Urmodel als Referenz definiert ist. Der bei den nachfolgenden Modellen angegebenen VUP gibt also den Faktor der Leistung zum Urmodell an. So hat die bereits erwähnte MicroVAX 3900 einen VUP von 3,8 oder die im Jahr 1991 eingeführte VAXStation 4000 M60 einen VUP von 12.

Im vorherigen Beitrag habe ich bereits dargestellt, dass die aktuelle Beta-Version von SIMH gegenüber den stabilen, prekompilierten Versionen in den Linux- sowie BSD-Distributionen für mich die bessere Wahl ist. Ein wesentlicher Punkt von der Beta-Version ist, dass neben den bereits in der stabilen SIMH-Version 3.x verfügbaren VAX 11/780 und der MicroVAX 3900 weitere Computer der VAX-Reihe emuliert werden können. In einer Tabelle in meinem Wiki habe ich mal die neu hinzugekommenen Modelle tabellarisch aufgeführt, die einen sichtlichen Leistungszuwachs gegenüber die MicroVAX 3900 vorweisen können – sofern der Host-Computer für die Verarbeitungsgeschwindigkeit entsprechend leistungsfähig ist. So hatte ich zum Beispiel mal den Versuch unternommen gehabt, auf einem Raspberry Pi Model 1 B mit einem mit 700 MHz getakteten 1-Kern ARM11-Prozessor und NetBSD 7 als Host-Betriebssystem, die MicroVAX 3900 zu emulieren. Als Betriebssystem kam die VAX-Portierung von NetBSD 7 wieder zum Einsatz. Die Verarbeitungsgeschwindigkeit des Raspberry Pi war dabei so langsam, dass auf dem emulierten System der Login-Prozess während diesem bereits wieder Timeouts geworfen hatte. Aber ohne Login ist natürlich auch nur im Ansatz kein Arbeiten mit dem System möglich. Andere User hatten zu dem Zeitpunkt sich mit dem Raspberry Pi der ersten Generation bereits erfolgreich OpenVMS-Cluster gebaut gehabt.

Bei meinen Experimenten, eine der hinzugefügten VAX-Modelle in der Beta-Version zu emulieren, bin ich auf zahlreiche Fehler gestoßen und ich konnte bisher nicht die passenden Geräte-Komponenten (Harddisk-Controller, Festplatten- und CD-ROM Modell) für einen Betrieb zusammenstellen. Andere User haben beim Emulationsversuch – beispielsweise einer VAXStation – nicht die Netzwerkschnittstelle aktivieren können. Es kann natürlich auch sein, dass im Code für die in der aktuellen Beta-4 neu hinzugekommen VAX-Modelle noch Fehler sind. Deswegen beschränke ich mich momentan auf die bereits in stabilen Version vorhandene MicroVAX 3900.

Quelle: The NetBSD Foundation, VAX Hardware Reference (www.netbsd.org)

Noch ein paar Fakten und Informationen zu der Hardware der MicroVAX 3900 selber.:

Der Computer wurde durch DEC mit dem Codenamen Mayfair III im April 1989 im Markt eingeführt. Sie war High-End-Modell der MicroVAX-Familie, welche die MicroVAX 3600 ersetzte, und sollte mit der AS/400-Serie von IBM konkurrieren. Bei der Einführung betrug der Startpreis der MicroVAX 3900 120.000,- US-Dollar. Dieses System verwendete das KA655-CPU-Modul, das einen CVAX-Chipsatz mit 16,67 MHz (60 ns Zykluszeit) enthielt.

RangeServer
IntroducedApril 1989
CPUKA655, CVAX+ Chip
Taktfrequenz16,67 MHz
FPUCFPA
Cycle in ns60
Level 1 Cache1 KiB
Level 2 Cache64 KiB mit von 120 ns Cycle
Arbeitsspeicher16 – 64 MiB ECC
BUS Storage1 x QBUS und 1 x DSSI
Bandbreite3,3 MB/s
HDD Kapazitätmax. 9,7 GB
GehäuseH9642 (19″ breit)
VUP3,8
Einführungspreis in $120.000,-
Supportet OSVMS, ULTRIX, VAXELN
FPU DatentypenF, D, G, H
Netzwerkmax. 2 Ethernet-Ports

Links: