Vier Clients, sieben Szenarien, identische Hardware und Provider, Läufe verschränkt, sodass sich Provider-Drift aufhebt. Die Kennzahl ist Zeit bis zur benutzbaren Datei: geladen, geprüft, entpackt. Inklusive der Etappen, die wir nicht gewinnen.
Auf dieser Seite
Erst die Methodik
pipelining_requests=8 (es liefert 1 aus, also ungepipelinet; allein diese Einstellung brachte seine 190-GB-Zeit von 24m24s auf 19m02s), NZBGet bekam ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb seine dokumentierte Konfiguration.Szenario 1 · sauber, riesig
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| Zeit bis zur benutzbaren Datei | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | keine¹ |
| GB auf der Leitung | 169.6 | 169.8 | 169.7 | 186.5 |
| Spitzen-RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb war bei 5m 42s mit dem Bewegen der Bytes fertig, nachdem es 186.5 GB gezogen hatte (10% mehr über die Leitung als alle anderen), hinterließ aber keine entpackten Medien, seine dritte gescheiterte Runde in Folge an diesem Post. · ² nzbfasts Speicher folgt seinem konfigurierten Budget, nicht dem Job: diese Etappe lief mit dem Standard-Auto-Budget und erreichte in der Spitze 1.4 GB; ein bewusst riesiges 64 GB-Budget bringt nur 4% (4m 22s), und gedeckelt auf 1 GB läuft derselbe 190 GB-Job trotzdem durch (siehe die Niedrigspeicher-Leiter weiter unten). In der früheren „US-Ostküste“-Runde (~2.4–3 Gbps Leitung) lief das gleiche Szenario in 9m 00s vs. NZBGet +30% und SABnzbd +111%. Der Abstand hält über Leitungsgeschwindigkeiten hinweg.
Szenario 2 · der Abstand wächst mit der Größe
Ein-Pass heißt: kein nachgelagerter Prüf-/Entpack-Durchlauf, je größer der Job, desto weiter zieht es davon. Sequenzielle Läufe auf derselben Maschine:
| Job | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX („Europa“, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB verschleiertes 4K („Europa“) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K („US-Ostküste“) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB auf einer Platte mit 97 GB frei („Europa“) | 3m 08s | läuft nicht² | läuft nicht² |
| 190.6 GB („US-Ostküste“) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Ihr Spitzen-Fußabdruck (Volumes + entpackte Ausgabe gleichzeitig, ~156 GB) überstieg die 97 GB frei. Ein-Pass braucht 1× die Inhaltsgröße: es halbiert die Platte, die du brauchst, nicht nur die Zeit.
Szenario 3 · verschleierter Post
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| Zeit bis zur benutzbaren Datei | 96 s | 153 s (+59%) | 259 s (+170%) | keine benutzbare Datei³ |
| Spitzen-RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb lud in 119 s, markierte den Job als Completed, und lieferte die rohen verschleierten Volumes: keine Umbenennung, kein Entpacken. nzbfast deobfuskierte aus den PAR2-Metadaten und entpackte im Stream, null Rücklese-Blöcke.
Szenario 4 · Warteschlange aus dreien
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| Warteschlangen-Laufzeit | 122 s | 136 s | 162 s | 277 s |
| Leitung im Leerlauf (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Drei Ausprägungen desselben Problems: nzbfasts Tail-Overlap hält die Leitung von Kante zu Kante ausgelastet; NZBGet ruht nie, läuft aber ~35% langsamer, weil es gleichzeitig entpackt; SABnzbd lädt schnell und lässt die Leitung dann zu 61% der Zeit dunkel während der seriellen Nachbearbeitung. In der Resilienz-Variante (ein Job mit verschlüsselten RAR-Headern) verkeilte sich SABnzbds Warteschlange am verschlüsselten Job und nur 1 von 3 Jobs wurde je fertig; nzbfast parkte ihn mit klarer Meldung und beendete den Rest.
Die ehrliche Spalte
Beide Läufe, die hier standen, wurden auf dem ausgelieferten Build neu gemessen und keiner ist mehr eine Niederlage: Der beschädigte Store-Mode-Post kostet uns jetzt 30 s gegen NZBGets 38 s, und die Rekonstruktion aus reiner Parität ist in 9 s fertig statt in 19 s, auf einem Lauf, bei dem NZBGet in derselben Zeit zurückkehrt, aber nichts liefert. Wir lassen den Abschnitt stehen, statt ihn zu löschen: Hier landen unsere Niederlagen, und die nächste Runde, die eine findet, stellt sie wieder hier hinein.
Szenario 6 · lass es am RAM verhungern
Dieselben vier Jobs, erneut mit harten Speicher-Budgets von 2 GB, 1 GB und 256 MB gefahren: was der Auto-Sizer auf einer 8-GB-Box, einer 4-GB-Box und einem 2-GB-NAS wählen würde. Jede Etappe erzeugte eine korrekte, voll geprüfte, entpackte Datei; das Spitzen-RSS folgte dem Budget, nicht dem Job. Zeit bis zur benutzbaren Datei, 10-GbE-Leitung:
| Job-Größe | reichlich RAM | 2-GB-Budget | 1-GB-Budget | 256-MB-Budget |
|---|---|---|---|---|
| 7 GB | 15 s | 15 s | 15 s | 15 s |
| 35 GB | 65 s | 70 s | 70 s | 65 s |
| 87 GB | 148 s | 206 s | 196 s | 180 s |
| 190 GB | 330 s | 427 s | 402 s | 411 s |
Der Aufschlag von 20–40% bei den großen Jobs ist ein 10-GbE-Artefakt: ausgelagerte Blöcke kosten nur Zeit, wenn die Leitung die Platte überholt. Derselbe 87 GB-Job bei denselben Budgets auf einer ~2.4 Gbps-Leitung maß −1% bis +7%, Rauschen. Auf einem typischen Heimanschluss ist ein kleines Budget bei jeder Job-Größe quasi gratis. Ein NAS-Profil (2 Verbindungen, 256 MB Budget) beendete den 35 GB-Job mit 0.4 GB Spitzen-RSS. Ein 2-GB-NAS kann das stemmen. Kein anderer Client bietet überhaupt eine Speicherobergrenze.
Szenario 7 · Archive in Archiven
Posts kommen zunehmend verschachtelt an: ein RAR im RAR, ein 7z in einem Store-Archiv, eine Leiter aus Schichten, eine Passwortkette. Diese Runde bewertet, was für den Betreiber übrig bleibt. auto heißt: jede Nutzlast entpackt, byte-identisch, ohne Handgriff; manuell heißt: der Client meldete Erfolg, ließ aber ein inneres Archiv im Ausgabeverzeichnis liegen, das du selbst öffnen darfst.
| Form | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| Store-RAR im Store-RAR | auto | auto | manuell | manuell |
| komprimiertes RAR im Store-RAR | auto | auto | manuell | manuell |
| 7z in einem Store-RAR | auto | auto | manuell | manuell |
| 5-Ebenen-Leiter, 6 Nutzlasten | auto · 6/6 | manuell · 3/6 | manuell · 1/6 | manuell · 1/6 |
| Passwortkette, 3 verschlüsselte Ebenen | auto · 3/3 | fragt nach einem Passwort | fragt nach einem Passwort | gescheitert |
| automatisch fertig, alle zehn Formen | 8/10 | 6/10 | 2/10 | 2/10 |
Loopback-Rig, maschinell erzeugtes Korpus, alle vier Clients auf derselben Maschine, bewertet per Inhalts-Hash, sodass ein Client, der die Nutzlast umbenennt, trotzdem gewertet wird. Weil innere Schichten im Flug entschachtelt werden, hält nzbfast eine einzige ~1.5 GB-Kopie auf der Platte, wo Ausschreiben-und-Entpacken-Clients ~3 GB halten, und beendet diese Etappen in 1–2 s gegenüber 4–8 s. Bei der Passwortkette steckt das Passwort jeder Schicht in einer Datei, die die Schicht darüber entpackt: nzbfast liest es und entsperrt alle drei Ebenen; die anderen halten an und warten, bis du es eintippst. Die beiden Formen, die es nicht automatisch abschließt, werden mit Absicht hart bewertet: eine 10-Ebenen-Leiter jenseits seiner Standard-Tiefengrenze und ein Post, der auf allen drei Ebenen beschädigt ist. Auf beiden rettet es mehr Nutzlasten als jeder andere Client, beendet sich aber mit einem Fehlercode, statt einen Teil-Job einen Erfolg zu nennen, also zählen beide hier als Fehlschläge.
Komponenten-Duelle
Entpacken und PAR2 sind unser eigener nativer Code, also lassen wir sie auch standalone gegen das Feld antreten, auf identischen Korpora. Eine Zeit zählt nur, wenn die Ausgabe byte-identisch zur Quell-Nutzlast ist.
Gegen unrar 7.23, 7-Zip, bsdtar, unar und das Upstream-rars-Crate auf einem Apple M3 Ultra gewinnt nzbfasts Entpacker jede Form oder liegt gleichauf: 400 kleine Dateien in 0.13 s zu unrars 0.66 s, solid 0.50 vs. 0.87, verschlüsselt 0.49 vs. 0.82, ein RAR7-Archiv mit 128 MB-Wörterbuch 0.71 vs. 0.92. Erneut gefahren auf einem 20-Kern-M1-Ultra und auf einem 14-Kern-Intel-Laptop hält das Ergebnis bei jeder Form, und auf dem Laptop weiten sich die Abstände: die parallelen Decode-Pfade skalieren in die zusätzlichen Threads. Jede gemeldete Zeit erzeugte sha256-identische Ausgabe.
Gegen das klassische par2cmdline, den SIMD-Fork par2cmdline-turbo und MultiPar hat nzbfast auf jeder gebenchten Maschine die schnellste Prüfung und die schnellste Reparatur. 20-Kern-Desktop: saubere Prüfung 0.40 s zu turbos 1.08 und den 3.67 des Klassikers; Reparatur von 101 beschädigten Blöcken 1.26 s vs. 2.61 und 7.52. 14-Kern-Laptop: Prüfung 1.26 vs. 1.48, Reparatur 2.57 vs. 3.62. Jede reparierte Datei byte-identisch. Eine ehrliche Anmerkung: Wir erzeugen kein PAR2 (ein Downloader braucht das nicht, und ParPar gehört diese Etappe).
Was ein Job kostet
Das Ein-Durchlauf-Versprechen betrifft den Speicherplatz genauso wie das Tempo, hier also gemessen statt behauptet: der Höchststand des Arbeitsverzeichnisses während der verschachtelten Läufe, zweimal pro Sekunde abgefragt. Einmal am Ende zu messen wäre sinnlos, denn ein Client, der seine Volumes nach dem Entpacken löscht, sähe aus, als hätte er sie nie geschrieben.
| Form | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| Store-RAR im Store-RAR | 1538 | 1538 | 1774 | 3080 |
| komprimierte innere Ebene | 1536 | 1536 | 1674 | 3102 |
| RAR im RAR, Tiefe 2 | 1536 | 1536 | 1714 | 3076 |
| 7z in einem Store-RAR | 1503 | 1536 | 1722 | 3102 |
Megabyte, weniger ist besser. NZBGet zieht hier mit uns gleich, und der Grund gehört dazu: Es läuft mit DirectUnpack und DirectWrite, so wie wir jeden Konkurrenten konfigurieren, und auf diesen Formen reicht das für eine einzige Kopie auf der Platte. SABnzbd hält zwei. Der verbleibende Abstand ist der, für den die Pipeline gebaut wurde: Wir materialisieren die Volumes gar nicht erst, der Spitzenwert ist also die Nutzlast selbst statt der Nutzlast plus dem Archiv, das sie transportiert hat.
Fähigkeiten, keine Mikro-Benchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| Pipelined NNTP | ja | standardmäßig aus | nein | ja | - | - |
| volle Prüfung während des Downloads | jeder Block | danach | Quick-Check | danach | danach | danach |
| Entpacken während des Downloads | im Stream, keine Volumes auf der Platte | Direct Unpack⁴ | Direct Unpack⁴ | unzuverlässig⁵ | nein | nein |
| Platte für einen N-GB-Post | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| Vollständigkeits-Urteil vor dem Download | blockgenau | nein | Zustand % | nein | Artikel-Check | nein |
| begrenzter Speicher (nie swappen) | budgetiert | 9.3 GB @ 190 GB | Cache-Einstellung | nein | - | - |
| Datei an jeder Stelle beim Download prüfen | ja | nein | nein | nein | sequenziell | nein |
| eingebauter Indexer + Posterwand | ja, schlüssellos | nein | nein | nein | Such-UI | Gruppen-Browser |
| Sonarr/Radarr-Drop-in | SAB API + Newznab | nativ | nativ | teilweise | nein | nein |
| Handy-Fernsteuerungen (nzb360/LunaSea) | über NZBGet-RPC | ja | ja | nein | nein | nein |
| Watchlist-Auto-Grab + Upgrades | eingebaut | über *arr | über *arr | nein | Watchdog | Regeln |
| einzige, in sich geschlossene Binary | ja | Python | ja | ja | .app | .exe |
| Open Source | GPL⁶ | GPL | GPL | ja | kostenpflichtig | kostenpflichtig |
| Plattformen | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | nur mac | nur win |
⁴ Direct Unpack materialisiert die Volumes trotzdem zuerst: 2× Schreiben und 2× Platte. ⁵ rustnzb lieferte in unserer Runde verschleierte Volumes, markiert als „Completed“ (sein Entpacken hängt sich mit RARLab-unrar zudem auf, sofern nicht deaktiviert). ⁶ GPL-3.0-or-later. Usenapp/Newsbin sind kommerzielle Ein-Plattform-Reader mit Downloader-Funktionen; sie stehen hier, weil Leute fragen, nicht weil sie beim Tempo mithalten.
Transport-Beweis