Erklärt · eins

Wie das Laden in einem Durchgang funktioniert

Das meiste, was diesen Client schnell macht, ist kein schnellerer Netzwerkpfad. Es ist, dass die Daten sich nur einmal bewegen. Hier steht, was das in der Praxis bedeutet, warum es etwas anderes ist als direktes Entpacken, welche Archivformen es überstehen, und was der Wegfall des Schreib-und-Rücklese-Zyklus auf einer echten Maschine tatsächlich wert ist.

Der Ausgangspunkt

Was ein Usenet-Download herkömmlich tut

Ein Post besteht aus Tausenden kleiner kodierter Artikel, die zusammen einen Satz Archivbände bilden, welche wiederum die Datei enthalten, die du eigentlich willst. Von einem zum anderen zu kommen waren herkömmlich vier getrennte Aufgaben, jede abgeschlossen, bevor die nächste beginnt.

  1. Laden und dekodieren. Jeden Artikel holen, dekodieren und die wieder zusammengesetzten Archivbände auf die Platte schreiben. Bei einer 60 GB-Veröffentlichung sind das 60 GB geschrieben.
  2. Prüfen. Alle 60 GB von der Platte zurücklesen, um sie gegen die Paritätsdaten zu kontrollieren, und reparieren, falls etwas nicht stimmt.
  3. Entpacken. Die Bände nochmals lesen und die entpackten Nutzdaten daneben schreiben. Nun liegen 120 GB auf der Platte.
  4. Aufräumen. Die Bände löschen, die Nutzdaten bleiben übrig.

Jede Stufe ist korrekt, und das Ergebnis stimmt. Aber die Nutzdaten wurden zweimal geschrieben, mindestens zweimal gelesen, und im Höchststand musste die Platte zwei vollständige Kopien eines Auftrags fassen, von dem du nur eine Kopie wolltest. Die Uhr, die du erlebst, sind alle vier Stufen nacheinander, und deshalb kann ein Client einen schnellen Download melden und dich trotzdem warten lassen.

Die Änderung

Es stattdessen einmal tun

Ein Durchgang heißt, dass die Bytes vom Netzwerk an ihr endgültiges Ziel gehen, ohne je zu einer Archivdatei auf deiner Platte zu werden. Es gibt keine Stufe zwei oder drei, weil die Arbeit von beiden geschieht, während Stufe eins noch läuft.

In der Praxis wird jeder Artikel bei seiner Ankunft im Speicher dekodiert und sofort an zwei Dinge zugleich übergeben. Der Prüfer kontrolliert ihn unverzüglich gegen die Paritätsdaten, sodass die Korrektheit feststeht, während die Daten landen, statt durch späteres Zurücklesen. Der Entpacker behandelt die eingehenden Bytes als Position innerhalb des Archivs, ermittelt, zu welchem Teil welcher Nutzdatendatei sie gehören, und schreibt sie dorthin.

Die Archivbände werden nie zusammengesetzt. Sie bestehen als eine Struktur, die der Entpacker versteht, während der Download im Flug ist, und das Einzige, was deine Platte erreicht, ist die gewünschte Datei. Wenn der letzte Artikel ankommt, bleibt im Grunde nichts mehr zu tun, weshalb unsere Endzeiten nahe an der Downloadzeit selbst liegen statt an einem Download plus Nachlauf.

Die messbare Folge: für denselben Auftrag schreiben wir etwa halb so viel, lesen weit weniger zurück und brauchen ungefähr die Größe der Nutzdaten an freiem Platz statt das Doppelte. Bei einer 190 GB-Veröffentlichung sind das etwa 157 GB freier Platz gegenüber etwa 313 GB, und rund ein Drittel des Plattenverkehrs.

Zwei Dinge machen das schwieriger, als es klingt, und sie sind der Grund, warum es selten ist. Artikel kommen nicht der Reihe nach an, der Entpacker muss also mit Bytes zurechtkommen, die an beliebigen Positionen landen, statt als Strom von Anfang an. Und ein komprimiertes Archiv lässt sich nicht ab der Mitte dekomprimieren, also muss jeder Teil der Arbeit, der wirklich Reihenfolge verlangt, erkannt und anders behandelt statt wegangenommen werden.

Der Vergleich, nach dem gefragt wird

Warum das kein direktes Entpacken ist

Direktes Entpacken ist eine gute Funktion, und die Clients, die sie haben, sind damit besser dran. Es löst auch einen anderen Teil des Problems, und der Unterschied zeigt sich genau dort, wo es darauf ankommt.

Direktes Entpacken beginnt zu entpacken, bevor der Download fertig ist, sodass Stufe drei Stufe eins überlappt, statt ihr zu folgen. Was es nicht tut, ist Stufe eins zu entfernen. Die Archivbände werden weiterhin vollständig auf deine Platte geschrieben, denn der Entpacker ist ein herkömmlicher, der herkömmliche Dateien liest; direktes Entpacken startet ihn bloß früher. Die zwei Kopien gibt es weiterhin, die zwei Schreibvorgänge finden weiterhin statt, und der Bedarf an freiem Platz ist unverändert.

Bände auf die Platte schreibenbenötigter freier Platzwie oft die Nutzdaten geschrieben werden
Laden, dann entpackenja, dann zurücklesen~2× der Auftrag2
Direktes Entpackenja, früher zurückgelesen~2× der Auftrag2
Ein Durchgangnie geschrieben~1× der Auftrag1

Der zweite Unterschied ist, was passiert, wenn die Form nicht einfach ist. Weil direktes Entpacken die Arbeit einem herkömmlichen Entpacker übergibt, sobald Bände auftauchen, braucht es eine unkomplizierte Lage: die Bände in brauchbarer Reihenfolge vorhanden, keine Reparatur ausstehend, nichts, das zuerst entsperrt werden muss, und ein Archiv, dessen Inhalt nicht selbst Archive sind. Fällt eines davon weg, ist das Vernünftige, zurückzutreten und auf Entpacken am Ende zurückzufallen, und genau das geschieht. Du bekommst ein korrektes Ergebnis und den gewöhnlichen Zeitverlauf.

Weil unser Entpacker von Anfang an um Bytes außer der Reihe herum gebaut ist, sind diese Lagen für ihn keine Ausnahmen. Das ist der eigentliche Unterschied: nicht dass wir früher anfangen, sondern dass wir uns nicht auf Bedingungen verlassen, die häufig nicht gelten.

Was es tatsächlich übersteht

Die Formen, mit denen es zurechtkommt

Ein solcher Entwurf lohnt nur, wenn er für die Posts gilt, die dir tatsächlich begegnen, und nicht für einen sauberen Idealfall. Der aktuelle Stand: kein Containerformat wird nur auf der Platte behandelt. RAR, 7z und zip gehen alle den Weg des einen Durchgangs.

Formein DurchgangAnmerkungen
RAR, gespeichert (ohne Kompression)jader Normalfall bei Medienveröffentlichungen
RAR, komprimiertjaauch ein komprimiertes Archiv als äußere Schicht
RAR 1.5, 3, 4 und 5jaalle vier Generationen des Formats
7zjaauch mit deflate-komprimiertem Inhalt
zipjaauch mit bzip2- und LZMA-Inhalt
Verschlüsselter Inhaltjamit Passwort, auch verschlüsseltes zip
Verschlüsselte Kopfdatenjawenn auch die Dateinamen verborgen sind
Passwortkettenjadas Passwort jeder Schicht steckt in der darüberliegenden
Verschachtelte Archivejaim Lauf entschachtelt, bis zu einer einstellbaren Tiefe
Auf mehreren Ebenen beschädigtjaReparatur auf jeder Ebene, weiterhin ein Durchgang
Numerisch geteilte SätzejaTeilungen im Stil name.001
Selbstentpackende ArchivePlattendurchgangdas Archiv beginnt nicht am Dateianfang
Verteiltes zip (.z01)Plattendurchgangund einige seltenere zip-Varianten
Fortgesetzte AufträgePlattendurchgangein nach einem Neustart fortgesetzter Auftrag endet herkömmlich

Die drei Absagen sind ehrliche und verhalten sich gleich: der Auftrag wird korrekt fertig, über den herkömmlichen Weg, und du bekommst für diesen Download den gewöhnlichen Zeitverlauf mit zwei Kopien. Nichts schlägt fehl; es hört bloß auf, auf die Art schnell zu sein, die der Rest dieser Seite beschreibt. Selbstentpackende Archive werden aus einem strukturellen Grund abgelehnt und nicht aus Mangel an Mühe: ein Archiv an seinen ersten Bytes zu erkennen kann nicht funktionieren, wenn die ersten Bytes ein Programm sind.

Die Zeilen zu verschachtelt und verschlüsselt sind die, die man ernst nehmen sollte, denn dort geben die meisten Clients dir den Auftrag zurück. Auf einem erzeugten Korpus von zehn verschachtelten Formen, bewertet per Inhalts-Hash, damit ein Client, der die Nutzdaten umbenennt, dennoch angerechnet bekommt, haben wir 9 von 10 ohne Eingriff abgeschlossen; der nächstbeste Client schaffte 5, und zwei weitere schafften 2. Die eine, die wir nicht automatisch abschließen, ist eine zehnstufige Leiter, die an der voreingestellten Tiefengrenze von fünf sauber endet und die tiefste Schicht als gesundes Archiv zurücklässt, und vollständig durchläuft, wenn du die Grenze anhebst. Diese Durchgänge stehen mit dem vollen Raster auf der Benchmark-Seite.

Warum es sich lohnt

Was der Wegfall des Umwegs tatsächlich einbringt

Es ist schneller, aus einem unspektakulären Grund. 60 GB zu schreiben und zurückzulesen ist selbst auf einer schnellen SSD nicht umsonst, und auf allem Langsameren ist es oft der eigentliche Engpass statt des Netzwerks. Ein Schreiben und zwei Lesevorgänge zu streichen nimmt diese Zeit vollständig von deiner Uhr. Der Gewinn ist genau dort am größten, wo man ihn am meisten bemerkt: bei großen Aufträgen und auf Maschinen, deren Platte nicht ihr schnellster Teil ist.

Es halbiert den Verschleiß. SSDs haben eine endliche Zahl von Schreibvorgängen in sich, und ein Downloader, der jede Nutzlast zweimal schreibt, verbraucht dieses Budget in doppeltem Tempo, ohne dass du etwas davon hast. Über ein paar hundert Terabyte Download hinweg, was für einen aktiven Nutzer ein gewöhnliches Jahr ist, macht der Unterschied einen spürbaren Anteil an der Lebensdauer einer Platte aus.

Es ändert, was hineinpasst. Freier Platz ist keine Leistungseigenschaft, er ist ein Ja oder Nein. Ein Auftrag, der das Doppelte seiner eigenen Größe an Luft braucht, läuft entweder oder nicht. Nur etwa die Größe der Nutzdaten zu brauchen heißt, dass Aufträge auf Maschinen und Datenträgern fertig werden, auf denen der herkömmliche Ansatz schlicht aufhört, und deshalb passt eine 190 GB-Veröffentlichung hier in etwa 157 GB freien Platz statt in etwa 313 GB.

Es kostet weniger Prozessorzeit. Daten nicht zweimal durch die Platte zu bewegen erspart die Arbeit dafür, und während des Downloads zu prüfen heißt keinen zweiten Durchgang über die Nutzdaten zur Kontrolle. Unser Prozessoraufwand bleibt flach bei etwa 1.7 Prozessorsekunden je Gigabyte, von einem 35 GB-Auftrag bis zu einem mit 190 GB, und das ist die nützliche Eigenschaft: die Kosten je Gigabyte wachsen nicht mit dem Auftrag.

Es läuft mit weniger Speicher, und mit begrenztem Speicher. Weil Bytes bei ihrer Ankunft verbraucht statt angehäuft werden, ist der Arbeitsbereich ein Budget, das du setzt, und keine Funktion der Auftragsgröße. Das erlaubt, eine 190 GB-Veröffentlichung auf einer Maschine mit rund 1.1 GB verfügbar zu verarbeiten. Wichtig ist nicht die Zahl, sondern die Gestalt: Speicher, der mit dem Auftrag wächst, trifft irgendwann auf einen Auftrag, den deine Maschine nicht beenden kann, und er scheitert durch Auslagern oder Abgeschossenwerden statt dadurch, dass er es dir sagt.

Zusammengenommen geht es hier weniger darum, einen Benchmark zu gewinnen, als darum, wo die Software überhaupt laufen kann. Ein Entwurf, der den halben freien Platz, die halben Schreibvorgänge und eine begrenzte Menge Speicher braucht, funktioniert auf einem kleinen Heimserver, einem älteren Laptop oder einem NAS, und genau dort lebt ein guter Teil dieser Software tatsächlich.

Jede Zahl auf dieser Seite ist gemessen und mit Build und Datum daneben auf der Benchmark-Seite veröffentlicht, einschließlich der Durchgänge, die wir verlieren. Das ehrliche Gegengewicht, dort ebenfalls genannt: ein Entpacker und Reparierer, gebaut um einen laufenden Download zu begleiten, halten mehr Speicher belegt als ein eigenständiges Werkzeug, das einmal von der Kommandozeile läuft; wenn deine Randbedingung also der kleinstmögliche Fußabdruck für einen einmaligen Auftrag an einer Datei ist, die du schon hast, gewinnen die spezialisierten Werkzeuge diese Spalte.