Hallo,
das Verhalten konnte ich auch schon beobachten. Der Torrent-Client aria2 ist da weitaus besser dokumentiert und mit mehr Funktionen (u.a. Web-Seed, Local Peer Discovery) versehen. Mit dem hatte ich in einer Windows-Umgebung erfolgreich und sehr performant Images für VirtualBox verteilt.
MfG Buster
Hallo an alle,
ich habe das Verhalten ebenfalls beobachtet. Maximal 4-10 Clients laden gleichzeitig, der Rest bekommt einen Timeout und fällt auf rsync zurück oder bleibt sogar endlos bei 0% Fortschritt stehen. Die Performance ist wesentlich schlechter als bei linuxmuster 7.0, da habe ich gleichzeitig 200 Rechner aufgeweckt und ein Image verteilt, was problemlos getan hat. Jetzt ist schon ein Rechnerraum zu viel.
Ich habe in der o.g. Datei mal die Option M 200 gesetzt, einfach nur um zu schauen, ob sich etwas verändert…leider passiert nichts. Kann man eigentlich irgendwo verfolgen, wie viele Clients am Server „nuckeln“…bzw. wie könnte man den debuggen wo es klemmt?
VG
Dominik
Hallo,
ich frage mich, wieso man eigentlich vom alten bittorrent auf ctorrent gewechselt hat, wenn das Teil nicht vernünftig funktioniert. Könnte man dann doch wieder rückgängig machen oder aria2 ausprobieren, wenn @Buster hier gute Erfahrungen gemacht hat.
Viele Grüße
Klaus
Hallo Dominik,
Ich habe in der o.g. Datei mal die Option M 200 gesetzt, einfach nur um
zu schauen, ob sich etwas verändert…leider passiert nichts.
hast du den Dienst linbo-torrent neugestartet?
Tauch dann beips aux | grep torrent
der Schalter -m mit auf? (zusätzlich zu -e)
Kann man
eigentlich irgendwo verfolgen, wie viele Clients am Server
„nuckeln“…bzw. wie könnte man den debuggen wo es klemmt?
ich hab da das script manchmal verwendet:
https://wiki.linuxmuster.net/community/anwenderwiki:linbo-remote
LG
Holger
Hallo Holger,
Ja und Ja
kenne ich, das hilft hier aber nicht weiter, weil man nicht erkennt, warum denn der Server nur 4-10 Clients direkt „bedient“.
Vielleicht kann ja @thomas was zur Aufklärung beitragen!?
LG Dominik
Hi!
Gut, dass ihr das erforscht. ctorrent läuft mit Defaultwerten und da sind max. 100 gleichzeitige Verbindungen erlaubt. In meiner Schule bei 36 gleichzeitig ziehenden Clients habe ich im Vergleich zum alten Linbo eine bessere Performanz beobachtet. Beim nächsten Ausrollen werde ich das mal genauer beobachten.
Funktioniert das nur bei mir ohne Probleme?
VG, Thomas
Hallo Thomas,
Danke für die Argumente! Leuchtet mir alles ein.
Bei meinen letzten Versuchen bekam ich an den Clients immer wieder Timeouts. Irgendwann ging es dann zwar wieder weiter, aber warum die Timeouts?
Viele Grüße
Klaus
Hallo,
Danke für die Argumente! Leuchtet mir alles ein.
Bei meinen letzten Versuchen bekam ich an den Clients immer wieder
Timeouts. Irgendwann ging es dann zwar wieder weiter, aber warum die
Timeouts?
der Default ist, wie Thomas schreibt, eigentlich 100 MAX Connections.
Aus irgend einem Grund macht der ctorrent auf dem Server aber viel
früber Schluss.
Wenn ich einen Computerraum mit 26 Rechnern gleichzeitig bespielen will,
dann hab ich schon 5-10 Clients nach 3 Minuten, die nix mehr bekommen
und den TimeOut hochzählen.
Manche bekommen dann wieder was: aber ca. 3 fallen dann auf RSYNC
zurück: das macht dann wirklich Last auf Server und Netzwerk.
LG
Holger
Hallo,
so wie Holger habe ich es auch schon erlebt mit 32 Clients gestartet und am Ende waren mindestens 10 Clients auf rsync zurückgefallen.
Es sieht auch so aus, als ob die Zeit für erneute Anfragen beim Tracker per Default auf 10 oder sogar 30 Minuten steht (hab grade den Client/Server nicht zur Hand). Wenn man also geringfügig Lastverteilung fahren will, indem man das Wake-On-LAN mit Zeitverzögerung zwischen jedem Client einbaut, damit nicht alle Clients gleichzeitig die initrd via TFTP laden, dann denken die ersten Clients sie wären alleine und nur die letzten Clients sehen alle Teilnehmer am Seed.
Das führte vermutlich auch dazu, dass die früher gestarteten Clients bei mir fast nie Upload hatten. Überhaupt habe ich nur ganz selten Upload auf den Clients gesehen, selbst wenn es Clients mit 80% Verfügarkeit des Images gab und neue Clients gerade erst eingestiegen sind.
MfG Buster
Hi!
Das Zurückfallen auf rsync deutet darauf hin, dass die Netzwerkbandbreite ausgereitzt ist. In der Standardeinstellung nimmt ctorrent keine Begrenzung der Uploadrate vor, sodass jeder Client die volle Bandbreite beanspruchen kann. Das lässt sich aber ändern:
screen -r image.qcow2.torrent
h.u und danach + lässt sich die Uploadbandbreite in B/s einstellen.Ich könnte mir vorstellen, dass man das Problem damit in den Griff kriegt. Ich werde bis Freitag ein Linbo-Release veröffentlichen, mit dem ihr dann die ctorrent-Parameter per Konfigurationsdatei einstellen könnt.
VG, Thomas
Hallo zusammen,
mich würde interessieren(um bei der Fehlersuche behilflich sein zu können), wer eigentlich auf rsync zurückfällt. Das macht ja nicht der ctorrent Client von sich aus. Generell würde mich interessieren, warum man in lmn71 ohne Torrent Tracker auskommt, welcher in lmn70 ja noch gelaufen ist.
Und nochmal generell:
Macht es Sinn Fehlersuche eines Tools zu machen, dessen letztes Release von 2004 ist? Sollte man nicht lieber aktuellere Software dafür verwenden?
Viele Grüße
Klaus
Linbo.
Klarerweise läuft da opentracker. Ohne Tracker gehts nicht.
apt-cache show ctorrent (21.10):
Original ctorrent's upstream has stopped its development and now
it's kept updated with new releases/bug fixes by a new developer.
VG, Thomas
Hallo @thomas
Danke für Deine Erklärungen im letzen Post.
Meiner Meinung nach sollte das nicht gemacht werden. Durch den Fallback auf rsync verschlechtert sich die Situation mit der Bandbreite mit jedem weiteren Client. Quasi ein Dominoeffekt.
Viele Grüße
Klaus
Hallo,
ich hatte irgendwo aufgeschnappt, dass es die Möglichkeit gibt den Rückfall per Konfiguration zu unterbinden. Was muss man da wo einstellen?
MfG Buster
Hallo Klaus,
ja, aber nur, wenn der Torrent läuft. Wenn der Torrent aus irgendwelchen Gründen nicht läuft, kriegst Du so zumindest ein Image. Tatsächlich ist es bei mir aber immer so, dass ich gleich merke, wenn der passende Torrent nicht gestartet ist (weil ich ein Image umbenannt habe oder soetwas). Und dann ist der Fallback tatsächlich der Todesstoß, außer der wäre dann SEHR bandbreitenbegrenzt, vielleicht wäre das eine Lösung (wenn dasüberhaupt geht).
LG
Max
Hallo,
ich habe (linbo 2.x, lmn 7.0) auch diese Art von Problemen gesehen, ohne ihnen nachzugehen.
Ich kann noch einwerfen: Ich habe die ERfahrung gemacht, wenn autoinitcache=no in der start.conf und man nicht explizit initcache:torrent auf der Kommandozeile angibt, dass dann auch kein torrent fürs seeden läuft.
Vielleicht spielt das hier keine Rolle, weil jeder der per torrent herunterlädt auch hochladen kann, trotzdem sollte man das im Hinterkopf haben für clients, die zwar schon das image haben, aber trotzdem nicht seeden wollen.
Außerdem: bei mir half bisher oft, linbo-bittorrent neu zu starten (hat Holger schon vorgeschlagen).
VG, Tobias
Hallo,
die Upload-Bandbreite pro Client zu begrenzen könnte kontraproduktiv sein. Wenn es nur einen Client gibt, soll der auch die maximal verfügbare Bandbreite erhalten. Gibt es Einstellungen für Quality of Service?
MfG Buster
Es gibt die Torrent-Einstellungen, die es eben gibt. Layer3-Priorisierung geht nur auf Router- oder Switch-Ebene, falls der Switch Layer 3 kann.
VG, Thomas
Hallo zusammen,
Seit wir das geändert haben:
/etc/default/linbo-bittorrent
→ MAX_UPLOADS=80
bleibt keiner der Clients mehr hängen und fällt auf rsync. Klar wird es bei 20 Rechnern langsam, aber alle ziehen torrent durch. Geschwindigkeit fällt von 114000 auf 6000, einige Clients bleiben bei 35000.
Warum die Clients dann nicht auch uploaden, habe ich schon 2 mal gefragt. Wäre doch ne nette default-Einstellung, dann wäre ja oft nur der letzte Switch betroffen, was die Bandbreite am Server entlasten würde.
Das teste ich in dem Zusammenhang mal.
VG
Volker
Das ist lmn70, hier geht es um lmn71.
VG, Thomas