Torrent ist irgendwie lahm, wenn mehrere PCs verbunden sind?!

Hallo Zusammen,
ich habe momentan ein seltsames Problem mit dem Torrent von Linbo.
wenn ich nur einen einzelnen Computer in Linbo gestartet habe und das Abbild Synce, erreiche ich je nach PC ca. 60000-101000,0000K/s - bei jedem weiteren Computer, den ich starte reduziert sich die Geschwindigkeit ca. um die Hälfte - das kann ich solange machen, bis Linbo auf rsync umschaltet.
Wenn ca. 20 PCs laufen, erreiche ich Geschwindigkeiten von 5,9000K/s - 20,000K/s - also um ein vielfaches Langsamer.
Nun könnte man vermuten, dass es mit dem Switch oder Uplink zu tun hat - wenn ich aber mein Laptop mit qbittorrent „unter Last“ (also wenn die weiteren 20PCs auch torrenten) starte kann ich aber die „volle“ Datenrate erreichen.

Außerdem erscheint an den PCs immer wieder die Meldung „Torrent wachtdog: download of win11.qcow stalls since … seconds“

Ich habe schon die Switches entsprechend untersucht, Storm Control und „Safeguard-Engine“ (<- irgendein D-Link quatsch) sind bereits deaktiviert.

Außerdem habe ich an dieser PIECELEN=schon etwas rum gespielt, aber ohne erfolg. (also das Verhalten bleibt besteheh)

Hat jemand schon mal ein ähnliches Phänomen beobachtet? Hat jemand Ideen, was man da machen könnte?

Timo

Hallo Timo,

wir mußten leider bei den neueren linboversionen auf einen anderen Torrentclient und server umsteigen, weil der alte überhaupt nicht mehr weiterentwickelt wurde.
Dabei mußten wir feststellen, dass torrent leider nicht mehr so problemlos war wie früher, wo wenige an den Einstllungen rumschrauben mußten und trotzdem gute Raten erreichten.
Auch ich mußte rumschrauben, bis es wieder Annehmbar war.
Pionierarbeit dabei hat Mathias geleistet.
Hier ist sein Tread:

Bei mir läuft es jetzt wieder OK.

LG

Holger

Hi Holger,
mit den einstellungen von Mathias erhalte ich folgende Fehlermeldung innerhalb der tmux-session:

error, „win11.qcow2.torrent“ is really a metainfo file???
error, initial meta info failed.

Vorher habe ich linbo-torrent create win11.qcow2 ausgeführt.

Timo

Hab das File neu mit " ctorrent -t -u „http://10.0.0.1:6969/announce“ -s win11.qcow2.torrent win11.qcow2" erstellt. Jetzt ist es wenigstens Kontinuierlich langsam :stuck_out_tongue:

Hallo Timo,

Die Meldung: error, „win11.qcow2.torrent“ is really a metainfo file???
error, initial meta info failed.
kommt, wenn die Pieclen zu KLein für die Größe des Torrents sind.

https://ask.linuxmuster.net/t/torrent-fehler-is-xxxx-cloop-torrent-really-a-metainfo-file/376/11

Schau auch mal hier:

LG
Holger

Hallo Holger,
ich wusste jetzt nich so richtig, wie ich die Piece-Length kalkulieren sollte. Bin dazu aber auf dieses Tool gestoßen:

Das Tool ermittelt, welche Piecelenge man Ideal für „Dateigrößen“ nutzen kann:
root@server:~/piecelength# du /srv/linbo/images/win11/win11.qcow2
38290948 /srv/linbo/images/win11/win11.qcow2
root@server:~/piecelength# piecelength 38290948
4194304

…hat mich bisschen zu dem Ding geführt:
könnte man nicht, das Tool nutzen, um die Piecelength je Image / Torrent-Datei zu kalkulieren?

Unabhägnig davon, hat das meine Situation aber nur unwesentlich verbessert:

Grüße und schöne Feiertage,
Timo

1 „Gefällt mir“

Ja, beobachten tun wir das regelmäßig (sowohl die abtauchende Datenrate wie auch die stalls) und nein, Ideen habe ich leider auch nicht.

Gruß
Sascha

Hallo,

das Tool zum Berechnen ist natürlich schon cool … aber uns bringt es nur sehr bedingt was, weil man ja normalerweise schon mehrere Images hat und die Pieclenlength gilt ja für alle …

Es ist ein sehr komplexes Problem.
War es nicht so, dass die Einstellungen ungeschickterweise für den Server und die Clients gleich ist? Das bedeutet, wenn man die Uploadrate begrenzt, dann begrenzt man sie auch für den server …
Sowas wurde hier schon diskutiert.

LG

Holger

Was mich halt so wundert ist, dass an meinem Laptop mit qbittorrent es so super schnell ging. Gibt es da vielleicht ein Problem mit ctorrent?
Meint ihr, es bringt was auf dem Server einen anderen Seeder laufen zu lassen? Ich hätte eher vermutet, dass es ein Client Problem ist.

Wenn du aber Sagst, dass Client&Server gleich wäre, müsste ich dann ein update-linbofs machen?

aufm Client sieht der Prozess so aus:

4313 root 32524 S ctorrent -e 0 -I 10.17.0.160 -m 1 -M 100 -z 128 -X touch win11.qcow2.complete win11.qcow2.torrent

Daher würde ich behaupten, dass zumindest nicht die gleichen gleichen Parameter laufen.

… also vielleicht trotz torrent „portionsweise“ bestücken?

Ich hatte den Link kürzlich in einem anderen Thread gepostet. Möglicherweise passt er auch hier hin:

Hallo,

Das kann ich bestätigen. In meinen Tests stellte sich heraus, dass man den Upload auf 95% des technischen möglichen Maximums limitieren sollte, um den Download auf dem Client nicht negativ zu beeinflussen. Das führt zu äußerst ungünstigen Situationen, wo man bspw. 10 Gbps für den Server im Upload zulassen will, aber nur 1 Gbps für die Clients hat. Es braucht unbedingt eine Trennung der Konfigurationsdateien für Server und Seed-Hosts (zusätzliche VMs fürs Seeden) sowie den Clients.

Noch besser wäre es, wenn auf dem Server nicht ctorrent zum Einsatz käme. Auf dem Client kann ich es verstehen, wenn man unbedingt einen Client mit minimalen Fußabdruck haben will, aber auf dem Server halte ich einen Torrent-Client mit Unterstützung für SuperSeed (jeder Teil einer Datei wird erst ein weiteres mal versendet, wenn alle Teile mindestens einmal versendet wurden) für unerlässlich.

Um „on the fly“ rumzuspielen und nicht jedes Mal die Konfigurationsdatei ändern zu müssen, kann man CTCS, den CTorrent Control Server, nutzen. Er bietet eine webbasierte Übersicht über alle Clients, ihre Down- und Uploadraten und Steuerung der Limits pro Seed oder Client. Ich habe das Perl-Skript bei Bedarf auf dem Server in einer screen-Session im Hintergrund laufen. Man muss den Clients nur die IP des CTCS-Servers in der Konfigurationsdatei mitgeben.

Ich hatte auch festgestellt, dass die Zeit bis ein Client beim Tracker nach weiteren Peers nachfragt, sehr hoch ist. Wenn wir die Rechner per Wake-On-LAN mit 1-2 Sekunden Zeitversatz gebootet haben, hat nur der letzte PC alle Peers gesehen und der erste PC hatte die weiteren Peers erst nach 30 Minuten vom Tracker abgefragt. Ich denke hier sollte man mit -m min_peers Min peers count (default 1) entgegenwirken und einen Wert >1 wählen. Leider scheint es bei ctorrent keine Option zu geben diese Tracker Update time zu beeinflussen. Es gibt zwar das Operator Menu, wo man das manuell triggern könnte, aber in der Linbo-PXE-Umgebung hat man keine vollständige Shell-Unterstützung.

VG
Buster

2 „Gefällt mir“

Hallo Timo,

… du solltest in jedem Fall auch die Clients betrachten.
Gerne werden ja RealTek Karten Onboard Verbaut, und die haben gerne Probleme mit Treibern und dann ist die Performance unter linbo schlecht (am Client).
Auch dazu haben wir Treads im Forum (such nach Realtek) wo es was gebracht hat, eines der Treiberkernelmodule von Realtek zu blacklisten, damit der kernel gezwungen wird ein anderes zu verwenden, was besser geht.
LG
Holger

Hallo Buser,
Hallo Holger,

Hast du mal einen anderen Torrent-Client probiert?

jop - ich hab bereits das rt8168-Modul im Einsatz. Ich vermute, dass es nicht am Netzwerktreiber liegt, weil ja die Performance, wenn nur ein Rechner synct gut ist.

KernelOptions = forcegrub modprobe.blacklist=r8169 pci-stub.ids=05e3:0735 dhcpretry=9

Timo

Hi. Vor einiger Zeit wurde das Torrent Paket ja auf ctorrent umgestellt. Ich weiß nicht mehr genau wie es vorher hieß aber mMn musste die Umstellung geschehen, weil das alte Paket nicht mehr entwickelt wurde, richtig :man_shrugging:t2::interrobang:

Ich habe daher mal kurz etwas gestöbert und bin auf das hier gestoßen:

Vielleicht wäre ein Umstieg (serverseitig) ja nochmals denkbar bzw gar keine so große Sache?
:thinking::interrobang:
Viele Grüße
Michael

… noch eine Ergänzung: Ich hatte irgendwann auch mal etwas mit den Torrent-Downloads experimentiert. Dazu hatte ich mir ein Script gebastelt, das die torrents zur Laufzeit der Clients (!!) (also nicht während LINBO noch läuft) synchron hält.

Hier das Script dazu:

Damit könnte man z.B. testen, ob die Übertragungen performanter laufen, wenn Ubuntu vollständig gestartet ist … dann wüsste man immerhin, ob es ein Treiber-Problem ist (realtek … s.o.).

P.S.: https://linuxconfig.org/ubuntu-22-04-list-of-torrent-clients

Viele Grüße,
Michael

HI Michael

sehr cool, über so was habe ich schon lange mal nachgedacht – war aber immer zu faul, das anzugehen. muss ich im originalthread übersehen habe, wahrscheinlich weil da was mit Wlan stand und ich nicht weitergelesen habe…

Werde ich nach den Ferien auf jeden Fall mal ausprobieren.

Gruß
Sascha

Ok, berichte gerne, wie gut oder schlecht das damit läuft. Ich habe gesehen, dass in den Kommentaren des verlinkten Scriptes noch von .cloops die Rede ist. Das sind jetzt natürlich alles .qcow2-Dateien … dürfte für die Funktionalität aber ansonsten egal sein.

Viele Grüße,
Michael

Das stimmt so nur bedingt - ja im Moment gilt die in der Config gesetzte Piecelength für alle, weil das ausführende script bei der imageerstellung diese list und als Parameter einsetzt. dieser parameter könnte aber bei jeder imageerstellung auch unterschiedlich sein, wenn besagtes script zum beispiel auf die gleiche weise wie das tool eine optimale piecelen jeweils berechnen würde.

Gruß
Sascha

Moin,
ich wollte noch kurz meine Ergebnisse-Teilen, bevor ich zum Weihnachtskaffee gehe…

auf dem Server habe ich nun qbittorrent-nox in Betrieb genommen, das habe ich jetzt erstmal von Hand gemacht, geht aber ischerlich auch automatisch. Dazu muss man im wesentlich den Linbo-Torrent-Dienst killen (also die tmux-session beenden), anschließend kann man den qbittorrent-dienst starten.

Dann ein neues .torrent-File erstellen, ich hab dazu auch ctorrent genutzt:

root@server:/srv/linbo/images/win11# ctorrent -t -u „http://10.0.0.1:6969/announce“ -s win11.qcow2.torrent win11.qcow2
Create hash table: 149574/149574
Create metainfo file win11.qcow2.torrent successful

In der Weboberfläche dann entsprechend öffenen, dort kann man das .torrent-File rein laden und den entsprechenden Dateipfad, hier:

Für das Torrent kann man dann auch das „SuperSeed“ was Buster beschrieb aktivieren:

Auf dem Linbo-Client habe ich entsprechend folgendes gestartet:

testvm00: /cache # ctorrent -s win11.qcow2 win11.qcow2.torrent
META INFO
Announce: http://10.0.0.1:6969/announce
Created On: Tue Dec 24 14:06:36 2024
Piece length: 262144
Created with: Enhanced-CTorrent/dnh3.3.2
FILES INFO
<1> win11.qcow2 [39209926656]
Total: 37393 MB
warn, couldn’t set bit field refer file „win11.qcow2.torrent.bf“: No such file or directory
This is normal if you are seeding.
Listening on 0.0.0.0:2705
Press ‚h‘ or ‚?‘ for help (display/control client options).
\ 0/1/3 [3/149574/7] 0MB,0MB | 0,0K/s | 0,0K E:0,1 Checking: 99%
Checking completed.
FILES INFO
<1> win11.qcow2 [39209926656] 3/149574 (0%)
Total: 37393 MB
/ 0/0/3 [17/149574/17] 5MB,0MB | 0,0K/s | 0,0K E:0,1

Der Peer wird zunächst auch in qbittorrent angezeigt, aber leider beginnt die Übertragung nicht.

Ein anderer Torrent-Client legt nach <1 Sekunde los mit dem Download:

Meine Einschätzung wäre jetzt, dass ctorrent nicht kompatibel mit dem qbittorrent ist.
Weiß jemand, wie man „dirty“ in den Linbo-Client ein anderen Torrent-Dienst rein zum testen hinein bekommt?

Jetzt erst gesehen, ggf. wäre Transmission noch geschicktert:

root@server:/srv/linbo/images/win11# transmission-
transmission-cli transmission-edit transmission-show
transmission-create transmission-remote

root@server:/srv/linbo/images/win11# transmission-create win11.qcow2 -t „http://10.0.0.1:6969/announce