Archiv der Kategorie: Computer

Fundstück – Seagate ST446452W 5,25″ Festplatte

Veröffentlicht am von
Antworten

Nachdem im vergangenen Herbst beim Ausmustern und Entrümpeln alter IT-Hardware noch ein externes SCSI-Gehäuse mit einer 3,5″ Festplatte durch meine Hände gewandert ist, hat in der Woche vor den Weihnachtsfeiertagen tatsächlich eine SCSI-Festplatte im Formfaktor 5,25″, voller Bauhöhe – also die Höhe von zwei übereinander gestapelten CD/DVD-Laufwerken – den Weg zum Elektroschrott gefunden.

Seagate ST446452W HDD

Ich kann mich noch gut daran erinnern, dass die Firma Quantum Corporation im Jahr 1996 mit der Festplattenreihe Quantum Bigfoot Laufwerke zu niedrigen Preisen für die IDE-/ATAPI-Schnittstelle mit höheren Speicherkapazitäten in den Markt eingeführt hatte. Man wollte damit auch gezielt dem niedrigpreisigen PC-Markt Festplattenlaufwerken mit höherer Speicherkapazität anbieten. Das erste Modell im Frühjahr 1996 hatte eine Speicherkapazität von 1,2 Gigabyte. Bis in die späten 1990er Jahre wurden Laufwerke mit Kapazitäten von bis zu 19,2 Gigabyte angeboten. Die Laufwerke konnten deshalb zu deutlich niedrigeren Preisen produziert werden, da Quantum die Kapazitäten je Laufwerk dadurch erhöhte, in dem sie nicht die Datendichte auf den Plattern erhöhte, sondern aus dem bereits fest etablierten 3,5″ Formfaktor wieder auf den 5,25″ Formfaktor für diese Modellreihe wechselte. Dadurch wurde einfach die physische beschreibbare Fläche je Platter-Seite bei gleicher Datendichte wie die der 3,5″ Laufwerke vergrößert und es können so mehr Daten gespeichert werden. Die Höhe dieser 5,25″ Laufwerke wurde aber auf die der 3,5″ Laufwerke belassen, sodass sie im Gegensatz zu den 5,25″ Festplattenlaufwerke in den 1980er Jahren noch nicht mal die Höhe dieser mit halber Bauhöhe erreichten und in die moderneren PC-Gehäuse auch eingebaut werden konnten. Allerdings erreichten die Laufwerke der Quantum Bigfoot Serien eher nur unterdurchschnittliche Leistungswerte, da die Umdrehungsgeschwindigkeiten mit etwa 3600 U/min zu Anfangs gering und die Zugriffszeiten recht groß waren. Außerdem waren sie laut. Zumindest bei Laufwerken mit IDE-/ATAPI-Schnittstelle war Quantum der einzige Laufwerkshersteller, der diesen Weg zurück zu physisch größeren Laufwerke für einige Zeit ging.

Als mir Mitte Dezember letzten Jahres aber dann diese 5,25″ SCSI-Festplatte mit voller Bauhöhe in die Augen fiel, war für mich schon sehr auffällig, wie modern und hochintegriert die Platine für die Steuerelektronik wirkte. Es kann sich also auf alle Fälle nicht um ein Laufwerk handeln, welches aus der ersten Hälfte der 1990er oder gar aus den 1980er Jahren stammt. Die Platine wirkt auch deutlich hochwertiger als die der IDE-/ATAPI-Laufwerke aus den 1990er Jahren. Die Wide-SCSI Schnittstelle wurde mit dem SCSI-2 Standard bereits ab 1989 spezifiziert, Laufwerke mit 68-Pin Controller-Kabel waren aber erst ab 1995 verfügbar. Meine Recherche über das Modell ergab, dass es sich um eine Seagate ST446452W mit einer Speicherkapazität von 62 Gigabyte unformatierter, beziehungsweise 47 Gigabyte formatierter Speicherkapazität handelt. Neben der 68 Pin Ultra SCSI-Schnittstelle besitzt das Laufwerk einen 4.096 Kilobyte großen Cache und arbeitet mit einer Umdrehungsgeschwindigkeit von 5.357 U/min. Bei meiner Recherche bin ich auf ein Support-Dokument für dieses Festplattenmodell gestoßen, dessen erste Version im Februar 1998 durch Seagate veröffentlicht wurde. Leider konnte ich aber bisher keine Informationen darüber finden, zu welchen Preisen diese Festplatte bei Markteinführung angeboten wurde. Da der Straßenpreis einer Seagate ST19171N mit einer Speicherkapazität von 9,1 Gigabyte formatiert im Herbst 1997 noch bei etwa 2049,- DM lag, mag man sich nicht ausmalen, wie viel dieses 47 Gigabyte-Laufwerk bei Markteinführung zu dieser Zeit gekostet haben mag.
Prinzipiell muss man wohl konstatieren, dass es in einem Enterprise-Markt für große Speichersysteme wohl Bedarf für Anwendungsfälle gegeben haben muss, dass Seagate dazu veranlasste im Jahr 1997/98 ein Laufwerk mit 47 Gigabyte anzubieten. Allerdings war es zu der Zeit nicht möglich, Laufwerke mit einer auch nur annähernden hohen Speicherkapazität im 3,5″ Formfaktor zu produzieren. So war Seagate also gezwungen, wieder auf den Formfaktor 5,25″ und voller Bauhöhe auszuweichen.

Seagate ST446452W HDD (geöffnet)

Bei dem Laufwerk, welches nun bei uns im Elektroschrott landete, war jemand schon lange zuvor so neugierig gewesen, dass der Deckel des Laufwerks aufgeschraubt wurde, um das Innenleben zu Gesicht zu bekommen. Sowohl die Schrauben für die Gehäuseabdeckung, als auch das Staubfilterkissen für den Luftdruckausgleich fehlen bereits und die Platter haben auch schon gut Staub angesetzt. Letztlich mangels eines 68-Pin-Kabels ist es also auch keine gute Idee mehr, zu versuchen dieses Laufwerk nochmals in Betrieb zu nehmen. Ich bin aber aktuell immer noch auf der Suche nach einem wirklich schönen Plätzchen, wo sich dieser jetzt historische Datenträger als Ausstellungsstück gut macht.

Update 14. März 2022 20:51 Uhr:

Gestern habe ich mal wieder in Bezug von Festplatten im deutschen Wikipedia-Artikel etwas recherchiert und gestöbert. Das Gute am deutschen Wikipedia-Artikel zum Festplattenlaufwerk ist, dass es im Abschnitt zur Geschichte eine Tabelle über die ‚Entwicklung der Speicherkapazitäten der verschiedenen Baugrößen‘ gibt. In dieser Tabelle wird die Seagate ST446452W als letzten Meilenstein in der Entwicklung von 5,25″-Laufwerken genannt. Aus der Tabelle ist heraus zu lesen, dass nach dieser keine weiteren Festplattenmodelle im 5,25″-Format mehr entwickelt wurden. Als Quelle für die ST446452W wird dazu noch auf eine heise-Online-Meldung vom 14. November 1997 verwiesen. In dieser hieß es, dass Seagate schon Testexemplare der Festplatte mit Veröffentlichung der Meldung begann auszuliefern, die Produktion größerer Stückzahlen startete dann ab dem 1. Quartal 1998. Als Preis gab Seagate 2995,- US-Dollar für ein Laufwerk an. Ich habe also dann mal recherchiert, wie der durchschnittliche Wechselkurs von US-Dollar zur Deutschen Mark im Januar 1998 war und bin bei etwa 1,814 DM je US-Dollar auf einen theoretischen Kaufpreis von 5435.70 DM gekommen. Für knapp 5500,- DM einschließlich Mehrwertsteuer hat man als Endverbraucher entweder einen sehr hochwertigen PC als reine Zentraleinheit ohne Peripherie oder ein gutes, recht umfangreiches Komplettpaket bekommen.

Links:

Weitere Gedanken zu den DEC (Micro-) VAX Computern

Veröffentlicht am von
2

In den letzten Monaten haben sich noch ein paar Gedanken zum Thema DEC (Micro-) VAX in meinem Kopf angesammelt, die ich als Nachtrag zu meiner Artikelserie ‚Emulation einer VAX mit SIMH‘ wenigstens auch noch einmal ausformuliert haben wollte.

Zum einen habe ich mal so etwas wie einen Benchmark durchgeführt, in dem ich die Zeit gemessen und verglichen habe, wie lange der Boot-Vorgang mit der emulierten MicroVAX 3800/3900 unter OpenVMS, Ultrix und NetBSD dauert.
Die Kriterien für den „Benchmark“ waren folgende:

  • In der Zeitmessung wird der Selbsttest der Firmware der Zentraleinheit mit dem RAM-Check, der nach dem Einschalten als erstes erfolgt, nicht berücksichtigt. Es wird also nur die Zeit ab dem Bootvorgang des Betriebssystems von der Festplatte bis zum Login-Prompt gemessen.
  • Bei allen drei Betriebssystemen wird keine grafische Benutzeroberfläche geladen. Der Login erfolgt nur auf der Kommandozeile.
  • OpenVMS wird in der letzten für die VAX-Architektur unterstützten Version 7.3 aus dem Jahr 2001 gebootet. (Open-) VMS war das Betriebssystem, welches für und mit der VAX-Architektur in den späten 1970er Jahren durch DEC in den Markt eingeführt wurde. Bei dem Bootvorgang wird auf das Starten von Systemhintergrunddiensten im Wesentlichen voll verzichtet. Es wurde auch kein Netzwerk in der Emulation eingerichtet. Kein DECnet, geschweige den TCP/IP.
  • Ultrix wird in der von DEC letzten veröffentlichten Version 4.5 ausgeführt. Diese erschien im Herbst 1995. Das Netzwerk wurde, soweit es mit den heutigen unter TCP/IP in Version 4 Standard noch kompatibel ist, statisch konfiguriert. Mit dem Bootvorgang werden auch die für Unix-typischen Standarddienste wie Cron, Accounting, Network und SNMPD gestartet.
  • NetBSD wird in der aktuellen Version 9.2 vom Mai 2021 ausgeführt. Als Dienste werden der DHCP-Client-Daemon, inetd, Cron, der Postfix und der SSH-Server während des Bootvorgangs gestartet. Allerdings wurden für den SSH-Server die Schlüssel bereits zuvor generiert. Eine Datenträgerüberprüfung mit fsck wurde aber vermieden.

Als wirklich arbeitsbereit kann hier nur die Installation von NetBSD angesehen werden. NetBSD ist außerdem das einzige Betriebssystem, welches für die VAX-Architektur noch weiter entwickelt wird, somit den heutigen Netzwerkstandards entspricht und dadurch auch moderne Entwicklungen im Bereich Betriebssysteme auf diese inzwischen historische Hardware-Plattform noch bringt. Hier sind nun die Ergebnisse.:

Betriebssystemmm:ss
OpenVMS00:31
Ultrix00:42
NetBSD05:05
Zeit für den Boot-Vorgang

Bevor ich nun die Ergebnisse interpretiere, will ich nochmals auf etwas eingehen, was für Software-Emulatoren wie der SIMH einer ist, gilt. Ein Software-Emulator ist ein Programm, welches einen Computer oder ein Betriebssystem nachbildet. Der größte Nachteil der Software-Emulation ist, dass sie eine hohe Rechenlast auf dem emulierenden System erzeugen. So können, selbst auf modernen Rechnern, zum Beispiel alte Spieleklassiker teilweise nicht flüssig laufen. Die Software-Entwicklung für solche Emulationen ist sehr aufwendig. In meiner Emulation der VAX-Architektur mit SIMH ist es jetzt aber so, dass die Rechenleistung so enorm ist, dass die Ausführung der Betriebssysteme in ihr deutlich schneller als auf der echten, originalen Hardware ist.

  • OpenVMS bootet von allen drei gemessenen Betriebssystemen im SIMH mit etwa 31 Sekunden am schnellsten. OpenVMS – oder ursprünglich nur VMS bezeichnet – wurde aber mit der Entwicklung der VAX-Architektur gleichzeitig mit entwickelt und war so immer auf diese optimiert.
  • Ultrix wurde durch DEC ab 1984 für die VAX-Architektur entwickelt und veröffentlicht. Unix galt in den 1980er Jahren prinzipiell als ein Betriebssystem, welches sehr viele Ressourcen in Anspruch nahm. Ultrix war nicht für alle Computern der VAX-Reihe verfügbar. Auf den Modellen, auf welchen es aber ausgeführt werden konnte, war es dennoch sehr langsam. Mit etwa 42 Sekunden bootet es in meiner Emulation verhältnismäßig schnell.
  • Die aktuelle Version von NetBSD benötigt für den Boot-Vorgang mit 5 Minuten und etwa 5 Sekunden verhältnismäßig extrem lange.

Wie gesagt, gelten die gemessenen Zeiten nur für meine SIMH-Emulationen und die Boot-Vorgänge kann man als wahnsinnig schnell erachten. Der Betreiber des YouTube-Kanals digital diggings präsentiert und führt ausschließlich auf seinen DEC-Rechnern der VAX-Architektur OpenVMS aus. Obwohl OpenVMS von der Ausführungsgeschwindigkeit das Betriebssystem mit der besten Performance ist, wird man beim Anschauen seiner Videos aber schnell feststellen, dass dieser bei der Wiedergabe seiner Aufnahmen, diese um ein bis zu 20facher Beschleunigung abspielt, damit die Wiedergabe für den Zuschauer sich nicht ganz so in die Ewigkeit hinzieht. Rechnet man die Abspielzeiten der beschleunigten Boot-Vorgänge für die einfachen Wiedergabegeschwindigkeiten hoch, so ist festzustellen, dass ein Boot-Vorgang selbst mit OpenVMS um ein Vielfaches als mein gemessener Wert überschreitet. Wie lange müssen dann die Boot-Vorgänge mit Ultrix und NetBSD dauern? 1 bis 1,5 Stunden bei NetBSD?

Links:

Über die Weihnachtsfeiertage habe ich mich mal bei YouTube mit ein paar Videos von Eisenbahnern berieseln lassen. Hauptsächlich kleine Dokumentationen, Aufnahmen von Modellbahnanlagen und Führerstandsmitfahrten. Dabei bin ich aber auch auf den YouTube-Kanal von Alwin Meschede gestoßen. So wie ich das von ihm verstanden habe, war er zu mindesten oder ist vielleicht noch selber als Triebfahrzeugführer tätig. Durch sein Studium der Betriebswirtschaftslehre kann ich mir durchaus vorstellen, dass er nicht mehr nur als reiner Lokführer tätig ist. Durch seine zahlreichen Videos, in denen es ihm weniger um Lokomotiven und Züge geht, sondern er beispielsweise eher über die unterschiedlichen Arten von Gleisbetten, Zugsicherungssystemen oder Gegebenheiten von Hochgeschwindigkeits-Neubaustrecken referiert, wird klar, dass er ein großes Fachwissen über das System Eisenbahn besitzt und über deren strukturelle Organisation in Deutschland sehr gut Bescheid weiß. So habe ich dann aus Neugier mir seinen zweiteiligen Vortrag über die Linienförmige Zugbeeinflussung LZB 100 angeschaut. Dabei schweift er bei dem Punkt über den Aufbau einer LZB 100 Steuerstelle ab und erwähnt, dass bei den LZB 72 Steuerstellen als Prozessrechner Computer der MicroVAX-Reihe zum Einsatz kamen, – wenn sie nicht noch bis heute weiterbetrieben werden.
Ab diesen Punkt kann ich mich noch gut erinnern, denn ich hatte im Sommer 2018 einmal die Gelegenheit, bei der DB Netz AG eine Betriebszentrale kurz zu besichtigen. Bei dem Rundgang dann durch den EMR-Schaltraum habe ich dann in einem Regal eine alte VAXstation entdeckt, die aber nicht mehr in Benutzung schien. Und nun habe ich auch verstanden, warum ich bei dem Rundgang durch die Betriebszentrale noch eine VAXstation antreffen konnte. Die Deutsche Bundesbahn hatte in den 1980er Jahren für der Projektierung der Linienförmige Zugbeeinflussung 72 (kurz LZB 72) Computer der Reihe MicroVAX als Prozessrechner in den Steuerstellen eingesetzt. Und so ist in der von mir besichtigten Betriebszentrale der Deutschen Bahn eine VAXstation noch übrig geblieben.

Links:

Und damit bin ich nun an dem Punkt, wo Computer der VAX-Reihe der Digital Equipment Corporation eingesetzt wurden.

  • Im Bereich Banken-/Versicherungswesen. (Hörensagen)
  • Andere Bereiche für Services.
  • Als Prozessrechner für die Linienförmige Zugbeeinflussung der Deutschen (Bundes-) Bahn.
  • In der chemischen Industrie als Mess- und Prozessrechner. Konkret bei einem früheren Arbeitgeber von mir. Den Computer selber habe ich nicht mehr zu Gesicht bekommen. In einem alten EMR-Schaltraum bin ich aber auf ein serielles Terminal vom Typ VT420 von DEC gestoßen. DEC hatte dieses Terminal-Modell im Jahr 1990 in den Markt eingeführt. Auf Nachfrage an die Kollegen der IT, berichteten diese mir, dass sie „vor kurzem“ erst noch alte klobige Festplatten in den Schrott entsorgt hatten. Ich konnte daraus entnehmen, dass die Festplatten wohl im Format 5,25″ volle Bauhöhe waren. Festplatten diesen Umfang wurden in der Regel in den Modellreihen MicroVAX und vielleicht auch VAXstation verbaut. Sicher bin ich mir bei letzterem da aber leider nicht hundertprozentig. Es ist eher nur eine Vermutung.

Links:

Zuletzt habe ich noch ein wenig in der Google-Bildersuche nach Fotos der MicroVAX I und MicroVAX II gestöbert. Dabei bin ich auf das MicroVAX II Museum gestoßen, dessen Betreiber des Blogs leider nirgendwo namentlich erwähnt wird. Eine E-Mail-Adresse als Kontakt konnte ich bisher bedauerlicherweise auch nicht ausfindig machen.
Wie aber der Name des Blogs nun schon verrät, beschäftigt sich dieses kleine Privatmuseum im Wesentlichen für den Erhalt von Computern der Modellreihe MicroVAX II. Es gibt aber auch Teile (als reine Ausstellungsobjekte) anderer VAX-Modelle. Die Highlights sind aber eindeutig die beiden funktionsfähigen MicroVAX II Computer Tarzan und Jane. Das wirklich Bemerkenswerte an den beiden aus den späten 1980er Jahren stammenden Computern ist aber, dass sie nicht mehr in ihren Originalgehäusen, sondern in wohnzimmertauglichen, schön anzusehenden und leisen PC-Gehäusen betrieben werden. Die Gehäuse sind moderne ATX-Gehäuse mit Plexiglas als Front und Seitenpartie, die beleuchtet sind. Die MicroVAX II Jane besitzt sogar ein LCD-Display mit einer Diagonale von 6,5″ und LED-Backlight. Die MicroVAX II Tarzan besitzt hingegen ein POS-VFD-RS232-Display, welches 2 × 20 Zeichen anzeigt und direkt an den Konsolenanschluss angeschlossen ist, um eine sehr genaue Zeit anzuzeigen, während auf der Maschine ein NTP-Server läuft. Es wurden zusätzlich noch die Festplatten gegen SD-Karten als Festspeicherlaufwerke ersetzt, die über SCSI2SD-Konverter am SCSI-Controller betrieben werden und über eine Speicherkapazität von 16 Gigabyte verfügen.

Links:

Fundstück – Externe SCSI-Festplatte

Veröffentlicht am von

Ein weiteres Fundstück ist mir beim Ausmustern alter Hardware in der Unternehmens-IT in meine Hände geraten. Eine externe Festplatte mit einer SCSI-Schnittstelle aus den 1990er Jahren.

In den letzten fünfzehn Jahren haben sich im Endverbrauchermarkt externe Festplatten etabliert, um Daten und Dateien auf die man nicht regelmäßig zugreift – also vornehmlich Musik, Filme und Fotosammlungen, an einem eigenen Ort gespeichert aufbewahren zu können, ohne dass sie den Festplattenspeicherplatz des PCs unnötig in Beschlag nehmen. Möglich machte dies der Universal Seriell Bus (kurz: USB), der mit der Version 2.0 im Jahr 2000 spezifiziert wurde. Es dauerte dann auch nicht lange, bis um etwa das Jahr 2002 dann erste günstige PC-Mainboards mit USB 2.0 Schnittstellen in den Handel kamen und in PCs verbaut wurden. Spätestens mit dieser 2.0 Spezifikation gab es nicht nur eine sehr preisgünstige, sondern auch eine sehr einfach zu handhabende Schnittstellentechnologie für die Übertragung zu Datenträgern auch außerhalb des PC-Gehäuses, die mit ihren 480 Megabit Busbreite eine höhere Datenrate als die der normalen Festplatten aufweisen konnte. Neben der USB 2.0 Schnittstellen gab es auch schon etwas länger die im Wesentlichen mit von Apple entwickelte FireWire-Schnittstelle, die in dieser ersten FireWire 400 eine Busbreite von 400 Megabit das Problem als erste anging. FireWire hatte Konzepte wie Daisy Chain von SCSI übernommen, war aber aufgrund der damit verbundenen Patente immer teurer in der Anschaffung von Controllern und Endgeräten.

Aber wie war die Situation prinzipiell in den 1990er Jahren? Von den allgemein verfügbaren Schnittstellen wie Serielle oder Parallel gab es keine, die mit nur wenig Aufwand mit direkt adressierbaren Massenspeichern außerhalb des Computergehäuses umgehen konnte. Wenn man für seinen Arbeitsplatz einen schnellen Massenspeicher für viele Dateien benötigte, auf die man zwar nicht permanent aber regelmäßig zugreifen musste, man sie im Zweifel auch an einem anderen Arbeitsplatz „transportieren“ möchte, aber ein File-Server in Hardware trotzdem völlig überdimensioniert war, musste man also schon etwas tiefer in das Firmen-Portemonnaie greifen und sich ein SCSI-Festplattenlaufwerk in einem externen Gehäuse anschaffen. Und scheinbar traf in dem Unternehmen, in dem ich zurzeit arbeite, eben dieses Szenario mal zu.

Frontansicht des externen SCSI-Festplattenlaufwerks

Ich habe ein externes Festplattengehäuse für genau eine 3,5″ SCSI-Festplatte finden können. Auf dem Gehäuse wurde irgendwann mit der Zeit ein Label mit der Aufschrift „Seagte 9,1 GB“ angebracht. Ja – richtig gelesen! Derjenige, der das Etikett erstellt hatte, hatte beim Namen des Festplattenherstellers das zweite ‚a‘ vergessen. Aber dennoch gab mir das Etikett ausreichend Informationen, um das Gerät zeitlich einordnen zu können. Das Gehäuse hat auf der Rückseite neben dem Kaltgeräte-Netzstromanschluss, den Ein-/Aus-Schalter und den beiden SCSI-Centronics Ports für den Daisy Chain Betrieb, auch einen Lüfter, was schon sehr sinnvoll war, da man für diese in der zweiten Hälfte der 1990er Jahre sehr hochwertige Festplattenlaufwerke mit für damalige hohe Rotationsgeschwindigkeit von 7200 Umdrehungen pro Minute drehende Plattenspindel für vernünftige Betriebsbedingungen sorgen sollte. Einer der Centronic-Ports hatte noch den für den SCSI-Bus wichtige Abschlusswiderstand gesteckt.
Ich musste dann meiner Neugier natürlich nachgeben und habe das Gehäuse aufgeschraubt, um zu schauen, was konkret für eine Festplatte verbaut ist, und meine Vermutung, dass es sich dabei um ein 3,5″ Plattenlaufwerk handelt, das Aufgrund durch die hohe Speicherkapazität deutlich höher als die Standard-3,5″ Laufwerke ist, hat sich auch bewahrheitet. Konkret war eine Seagate Barracuda ST19171N mit dem 80 Pin Fast SCSI-3 Anschluss eingebaut. Das Model ST19171N gehörte bereits zur 9. Generation der Seagate Barracuda Festplattenserie. Leider hatte Seagate auch bei dieser Festplattenserie nicht das Produktionsdatum auf dem Label mit vermerkt. Für die Recherche des Anschaffungspreises kam mir zugute, dass irgendwann einmal sich jemand die Mühe gemacht hatte, und die Ausgaben der deutschen Computerspielezeitschrift ‚PC Games‘ für die Jahrgänge 1992 bis 2007 vollständig mit den Werbeanzeigen als PDF digitalisiert und ins Internet veröffentlichte. Was der Straßenpreis im Jahr 1996 bei Markteinführung des Festplattenmodells war, konnte ich zwar nicht herausfinden, aber da der seit 1992 existierende Versandhändler für Computer Alternate GmbH im Jahr 1997 seinen Online-Versand aufgenommen hatte, konnte ich in der September Ausgabe von 1997 in der zweiseitigen Werbeanzeige den damaligen Straßenpreis zum Zeitpunkt der Annoncenschaltung herausfinden. Dieser lag nach gut einem Jahr noch bei 2049,- DM. Für das Geld konnte man sich schon als Einstiegspaket einen neuen PC mit Monitor kaufen. Zum Vergleich: 1996 hat eine normale 3,5″ Festplatte mit IDE Schnittstelle und einer Speicherkapazität von 1 Gigabyte etwa 350,- DM gekostet. Für die externe SCSI-Festplatte kamen dann noch die Kosten für das Gehäuse und etwa 350,- bis 400,- DM für einen SCSI-Controller hinzu.

Seagate Barracuda 9 SCSI-HDD ST19171N

Nachdem ich nun sowieso das Plattenlaifwerk aus dem Laufwerksgehäuse genommen hatte, kam das Laufwerk in die Tonne zum Schreddern durch einen Dienstleister und das Gehäuse in den normalen Elektroschrott.

Links:

Fundstück – Targus Modem Adapter Kit

Veröffentlicht am von

Auf meiner Arbeitsstelle müssen wir Mitarbeiter von der IT-Administration derzeit in ein anderes Betriebsgebäude umziehen. Mal abgesehen davon, dass die neuen Räumlichkeiten weniger Fläche besitzen werden, ist so ein Umzug immer eine gute Gelegenheit, in den eigenen Räume und Läger mal so richtig zu entrümpeln. Dabei kommen – wie es jetzt auch wieder einmal der Fall ist, alte Technik mit ihrem Zubehör wieder zum Vorschein, welche irgendwann in der Vergangenheit aus einer bestimmten Notwendigkeit angeschafft werden musste, aber mit den Jahren oder Jahrzehnten ihre Bedeutung wieder verloren hatten und deswegen nie gleich entsorgt wurden, sondern stattdessen immer erst einmal aufgehoben wurden und dadurch in Schränken und Regalen nach ganz hinten verschüttet gingen,- bis eben jetzt, wo nun die Notwendig besteht, sich von allem Alten und nicht mehr Brauchbaren trennen zu müssen, weil die bald nun ehemaligen Räumlichkeiten Besen-rein an dem Vermieter zurück zu übergeben sind.

Im Konkreten bin ich auf ein sogenanntes ‚Modem Adapter Kit 1 for Europe‘ der Firma Targus gestoßen.

Targus Modem Adapter Kit

Hintergrund ist, dass es sich bei dem Kunden, für den ich mit meinem derzeitigen Arbeitgeber arbeite, um einen Konzern handelt, welcher durchaus auch global handelt. Natürlich hat dieses Unternehmen als Hersteller von Produkten auch eine eigene Vertriebsstruktur mit Außendienstmitarbeitern, die zumindest von dem Standort Frankfurt am Main aus fast im ganzen europäischen Ausland agieren könnten. Mit der Entwicklung der (IBM-kompatiblen) PCs zu praktikableren Laptops und Notebooks ab den späten 1980er Jahren etablierte sich langsam die EDV auch für die Handelsvertreter. Spätestens aber mit der Internet-Revolution in den 1990er Jahren wollte man dann mit den Geschäftsgeräten seine Daten nicht wieder nur auf Papier ausdrucken und versenden, sondern auch bei den Geschäftsreisen elektronisch mit den IT-Service-Diensten des eigenen Unternehmens abgleichen. Lebte man in Deutschland, konnte man so das PC-Modem an den im Jahr 1989 von der Deutschen Bundespost eingeführten Telekommunikations-Anschluss-Einheit (kurz: TAE) mittels TAE-Adapter an den Haus-Telefonanschluss anschließen. – Um es mal sehr vereinfacht zu sagen. Musste man dann mal die Landesgrenze in das benachbarte europäische Ausland übertreten und dann die sogenannte „Dial-up“ -Verbindung aufbauen, stand man dann mit seinem RJ-11 auf TAE-Adapter vor der nächsten Hürde: Der noch von der Deutschen Bundespost eingeführte TAE-Stecker passt nur in Deutschland. Um dennoch im europäischen Ausland aus dem öffentlichen Telefonnetz seine Dial-up-Verbindung zu dem eigenen Internet-Provider mittels Modem aufbauen zu können, brauchte es nun mal dann einen RJ-11 Adapter für die Telefonanschlussdose des jeweiligen Landes.

Man muss aber sagen, dass obwohl dieses Adapter-Set „Modem Adapter Kit 1 for Europe“ heißt, es dennoch auch außerhalb der europäischen Grenzen weltweit in vielen Ländern einsetzbar war – oder acuh noch ist. Dies liegt daran, dass Länder wie Groß Britannien, Frankreich, Spanien oder Portugal bis in das zwanzigste Jahrhundert weltweit sehr viele Kolonien besaßen, die nach ihrer Unabhängigkeit als Nationalstaat die technischen Standards ihrer ehemaligen Kolonialmächte noch beibehalten beziehungsweise übernommen haben. Noch heute lässt sich sicherlich der RJ-11-Adapter für England in Australien anwenden, da der Kontinent noch zum heute bestehenden Commonwealth of Nations angehört. In einem anderen Modem Adapter Kit muss es dann vielleicht die Adapter für Japan oder Russland (mit den ehemaligen Sowjet-Republiken) geben.

Reine Modem-Einwahlverbindungen zu Internet-Providern waren in den Industrienationen noch bis vor etwa zehn bis fünfzehn Jahren üblich. – Oder sind vielleicht in der einen oder anderen abgelegen Region auch heute noch die einzige Möglichkeit, eine Verbindung zum weltweiten Internet aufbauen zu können. Mit der Verbreitung der immer leistungsfähigeren Smartphones – die auch die Funkstandards mit höher wertenden Bandbreiten nach sich zogen – zum einen, und der Verbreitung von privaten und öffentlichen WLAN-Hotspots zum anderen, benötigen Notebooks nun keine kabelgebunden Modems mehr. – Wenn nicht in den Notebooks noch bereits ein analoges Modem eingebaut war. Inzwischen wird in Deutschland das zu Beginn der 2000er Jahre eingeführte UMTS (3G Breitband Mobilfunkstandard) wieder langsam abgebaut, um Frequenzen für die kommenden Mobilfunkstandards wieder zur Verfügung zu haben.

Links:

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: