Hallo Mathias,
Evtl. ist das mit dem CTorrent Control Server möglich?
http://www.rahul.net/dholmes/ctorrent/ctcs.html
http://www.rahul.net/dholmes/ctorrent/userguide.html#status
Viele Grüße
Klaus
Gerade mal ausprobiert(ohne Klonen):
http://www.rahul.net/dholmes/ctorrent/ctcs-1.4.1.tar.gz auf den Server runterladen, entpacken und ctcs ausführen.
Auf dem Server /etc/default/linbo-torrent ergänzen und torrent Daemon neu starten:
OPTIONS=„-S 10.0.0.1:2780“
Dann über den Browser auf den ctcs verbinden:
http://10.0.0.1:2780
Viele Grüße
Klaus
Hallo Klaus,
danke für deine Tips. Probier ich aus 
Gruß,
Mathias
Hallo zusammen,
so sieht’s aus, wenn alles so läuft, wie es soll:
Dank Klaus weiß ich jetzt, wie ich die Zahlen zu interpretieren habe.
Rechts unten sieht man die Screen-Session des Treckers.
- Am Trecker hängen 17 Peers und saugen.
- Der Server liefert 37341 KB/s upload
Das andere sind die Screen-Sessions einiger Clients. Links unten sieht man:
- Es gibt einen Seeder (unser Server). 22 Leechers, die saugen und 17 Peers im Schwarm?!?
- Die Download-Rate ist 27973 MB/s und die Upload-Rate ist 20764 KB/s.
Das dürfte die Frage beantworten, ob die Clients ihre Chucks auch verteilen. Ja das tuen sie
Jetzt lasse ich mal alle zusammen, also die 23 Rechner die ich grad habe (bei uns wird grade gebaut…). Eigentlich sollte jetzt alles in die Knie gehen. Zumindest war das heute morgen so?!?
Aber jetzt läuft’s top?!? Warum weiß ich auch nicht, woran’s liegt?!?
Hier ist meine linbo-torrent
# default values for linbo-torrenthelper service provided by ctorrent
# thomas@linuxmuster.net
# 20220317
#
# note: you have to invoke 'linbo-torrent restart' after you have changed any values
#
# Exit while seed <SEEDHOURS> hours later (default 72 hours)
SEEDHOURS="8760"
# Max peers count (default 100)
MAXPEERS="100"
# Min peers count (default 1)
MINPEERS="1"
# Download slice/block size, unit KB (default 16, max 128)
SLICESIZE="16"
# Max bandwidth down (unit KB/s, default unlimited)
MAXDOWN=""
# Max bandwidth up (unit KB/s, default unlimited)
MAXUP="102400"
# Supplemental ctorrent options, separated by space (-v: Verbose output for debugging)
# OPTIONS="-S 10.16.1.1:2780"
# Timeout in seconds until rsync fallback (client only)
TIMEOUT="300"
# user to run ctorrent (server only)
CTUSER="nobody"
Gruß,
Mathias
1 „Gefällt mir“
Hallo,
von Enhanced CTorrent User's Guide (Hervorhebung von mir)
Bandwidth Limits
You should always specify an upload bandwidth limit. With the most recent changes in the program, this „option“ is not just a limit to stay under, but an advisement to the client as well. Enhanced CTorrent now tunes its upload performance based on the limit. Without a limit, the client has no idea how much bandwidth your line can support and so cannot perform this tuning. It is now possible to achieve better upload rates with a limit than without. Due to the tit-for-tat nature of bittorrent, this can also indirectly increase your download performance. If you just want the client to use as much upload bandwidth as possible, then choose a limit that is 10% or so less than the available upload capacity of your line. („Available“ means not typically in use by other applications.)
Note that limits are specified in KB/s (kilobytes per second), where 1KB = 1024 bytes (8192 bits). Your ISP likely measures in „kilobits“ (Kb, where 1Kb = 1000 bits or 125 bytes) or „megabits“ (1Mb = 1000000 bits or 122KB). Some of that [to the tune of 20% in some cases] is used by the line protocol and thus not available to you at all.
Das „option“ in Anführungszeichen meint, dass es eben keine Option mehr ist, sondern Pflichtangabe und für volle Geschwindigkeit auf 90% der Leitungskapazität stehen sollte. Steht das so in der LMN-Doku? Ich konnte es nicht finden.
MfG Buster
Hallo zusammen,
wie ich sehe, wird hier massiv ctorrent-Kompetenz aufgebaut. Das ist sehr gut. 
Evtl. mündet das in praktikable Voreinstellungen, die wir ausliefern können.
VG, Thomas
2 „Gefällt mir“
Hallo Buster!
Ich wüsste nicht. A
a) Wo das stehen könnte
b) Was da genau drin stehen sollte
Daher empfinde ich es als gut, dass sich hier geballtes Wissen aufbaut. Das kann, nein, das muss dann in die Doku. Wäre schön, wenn jemand, der Ahnung davon hat, uns einen passenden Text liefern könnte.
Welche Punkte sollten deiner Meinung nach Einzug halten?
Beste Grüße
Thorsten
Hatte den Thread noch gar nicht gelesen, da wir noch mit der alten Musterloesung arbeiten, Migration ging immer irgendwie in die Hose.
Ich verteile mit ctorrent die virtuellen Maschinen fuer die Clients und seitdem ich das Ubuntu 18.04 Bionic auf dem Client mal wieder vor ein paar Wochen geupdatet habe, tauschen die Clients im Raum keine chunks mehr untereinander aus, laeuft alles ueber den ersten Seeder.
Das kann man sich ja prima mit iftop ansehen - ich wuerde sagen, dass sich da irgendwann die ctorrent-Versoin geaendert hat und da ein fieser Bug schlummert.
Hab das aber heute erst erkannt und bin durch etwas Googlesuche hier gelandet.
Ein kurzer Test mit old school „btlaunchmanycurses .“ hat seeden und leechen im Raum ermoeglicht, duerfte also schon an ctorrent liegen. Ich glaube das Programm ist scheisse, uralt, miese Doku und wird nicht mehr gepflegt…deshalb wundert mich, dass ich da wohl irgendwas geaendert hat.
Koennte auch sein, dass da AppArmor, SELinux oder sowas die Daumenschrauben angelegt hat und da wilden Datenverkehr beschneidet…und wild ist das ja schon was da passiert, ich hatte da vorher Datenraten von 800MBit/s auf der Leitung und das rein/raus.
Gruss Harry
Wie/warum ist denn die Wahl auf ctorrent gefallen? Es gibt ja durchaus auch noch andere CLI-Torrent-Clients. Was davon direkt unter LINBO funktioniert, steht natürlich auf einem ganz anderen Blatt, aber hier findet man eine kleine Übersicht:
Unteres Drittel → Command Line Torrent Clients
Hab gerade zwei Schwaerme in der Schule am VMs einspielen, grosse Brocken. Der Schwarm mit ctorrent (18.04er Ubuntu, gleiche Version ctorrent wie vor dem Update des Ubuntus) seedet nur an andere Raeume und leecht vom ersten Seeder (Server), der aria2-Schwarm seedet auch mit richtig Bandbreite im eigenen Schwarm, Faktor 10 schneller.
Hallo,
Hab gerade zwei Schwaerme in der Schule am VMs einspielen, grosse
Brocken. Der Schwarm mit ctorrent (18.04er Ubuntu, gleiche Version
ctorrent wie vor dem Update des Ubuntus) seedet nur an andere Raeume und
leecht vom ersten Seeder (Server), der aria2-Schwarm seedet auch mit
richtig Bandbreite im eigenen Schwarm, Faktor 10 schneller.
hier im thread steht eigentlich was zu tun ist, damit die Clients mitseeden.
Das steht auch in der von Klaus geschickten Doku zu ctorrent: man sollte
MAXUP nicht leer lassen, sonst passiert gerne mal mist.
Ich hab Heute in der Schule folgende zwei Änderungen in der Datei
/etc/default/linbo-torrent (die hat Harry aber nicht, weil er nicht
linbo 4 hat: er hat /etc/default/linbo-bittorrent und ein ganz anderen
Torrentclient (ich glaube utorrent wobei das „u“ ein „mü“ sein soll) auf
dem server).
Ich hab ja sowieso eine andere Installation, das passiert bei mir ja auf dem Ubuntu-Client und da hatte ich noch nie MAXUP eingetragen, da ist in der letzten Zeit nach einem Bionicupdate irgendwas mit ctorrent oder dessen Umgebung passiert was das wohl notwendig macht.
Mein Tracker ist bttrack, Alteisen halt.
Moin!
Bei mir läuft das mit den Standardeinstellungen so:
Habe gestern ein 35GB Win10-Image in 2 Stunden an 29 Rechner verteilt. Mit linbo-remote -p format:1,sync:1,halt zuvor den Onboot-Befehl an alle ausgerollt. Um 18.35 Uhr den Computerraum mit 15 Rechnern aufgeweckt, alle anderen danach in Minuten-Abständen. Um 20.34 war der letzte fertig gesynct.
VG, Thomas
Hallo Thomas,
hast du SLICESIZE verändert? Bei mir gab*s eine deutliche Besserung, als ich SLICESIZE = "16" gesetzt habe.
Gab es bei dir Clients, die lange warten mussten?
Gruß,
Mathias
Hallo,
ich lade derzeit Gruppen von je 17 Rechnern im IT-Lehrsaal und das Image ist ca. 44 GB groß. Die 17 Rechner sind nun gefühlt (bisher nicht genau gemessen) nach 30 Minuten fertig mit herunterladen. Neben dem Server gibt es noch 2-4 VMs, welche den Seed unterstützen. Der Switch im IT-Lehrsaal ist mit 2x1 Gbps (Port-Channel) angebunden. Diese Zeit habe ich aber erst erreicht, nachdem ich auf dem Server den Upload künstlich auf ca. 900 Mbps begrenzt habe (Beitrag #85). Davor hat die gleiche Gruppe 60-120 Minuten gebraucht. Interessanterweise war auch erst nach dieser Begrenzung auf vielen Clients überhaupt ein Upload zu anderen Clients zu sehen. Davor haben sich alle Clients auf den Initial-Seeder, den Server, verlassen. Einen Rückfall auf rsync habe ich seit dem noch nicht gesehen. Ich werde es weiter beobachten.
MfG Buster
Hallo Mathias,
ich habe an den Standardeinstellungen nichts verändert. SLICESIZE=16 muss ich noch testen. Der erste Rechner hat für den Download 37 Min. benötigt, der letzte 40. Keiner ist zu rsync zurückgefallen. Die Last war also IMO gleichmäßig verteilt.
VG, Thomas
Hallo Thomas,
± 3 Minuten ist super. Was will man mehr?
Wenn unser dritter Raum wieder fertig ist, teste ich nochmal. Dabei möchte ich die Rechner wieder mit linbo-remote -r Raumname -b 1 -w 1 quasi gleichzeitig starten.
So, wie’s bis jetzt aussieht, ist es super.
Gruß,
Mathias
Hallo Buster,
Interessant wär es, das Image nochmal auf die 17 Rechner zu verteilen. Allerdings ohne die zusätzlichen Seeder. Wenn ctorrent so arbeitet, wie es sollte, sollte das Image fast gleich schnell verteilt werden.
Gruß,
Mathias
Hallo zusammen,
ich habe jetzt einen Test mit 40 Clients und einem 9 GB-Image gemacht.
Zunächst habe ich die Clients mit linbo-remote -r RAUM -b 1 -w 1 geweckt.
Nachdem alle Clients der drei Räume online waren, habe ich mit linbo-remote -r RAUM -c format,sync:1,halt die Clients quasi gleichzeitig auf das Image losgelassen.
In den ersten zwei Minuten gabe es Clients (die zu letzt angestoßen wurden) die nichts bekommen haben. Aber dann gings los.
Bemerkenswert ist, dass der Server (links oben) kaum noch uploaded. Während die Clients noch gut downloaden. Gut, die die man auf dem Bild noch sieht, sind teilweise ziemlich alte Rechner. Die können nicht schneller…
Ich bin super zufrieden mit ctorrent.
Gruß,
Mathias
1 „Gefällt mir“
Ich mittlerweile auch wieder, bei meinen Problemen lag es daran, dass ich „connman“ (connection manager) deinstalliert hatte, da dieser irgendwie auch DNS-Proxyfunktion hatte und einige Webseiten, z.B. YouTube nicht mehr aufgeloest hat, und das nur mit Firefox - Chromium ging.
Ohne „connman“ kriegen das die Clients aber nicht mehr mit dem seeden/leechen gerissen und bleiben beim 1. Seeder und der ist dann heftig beschaeftigt und nix geht vorwaerts. Falls also mal jemand das Problem hat, nicht connman deinstallieren sondern connman ohne DNS-Proxy starten https://www.i-have-a-dreambox.com/wbb5/forum/index.php?thread/200484-connman-service-ohne-dns-proxy-starten/