Hallo Holger,
Bei Wikipedia wird es immerhin als „legacy“ aufgeführt – das klingt für mich jetzt nicht allzu gefährlich 
LG Jörg
Hallo an alle,
ich würde gerne nochmal den Kern des eigentlichen Problems in den Fokus rücken, weil die aktuelle Situation produktiv wirklich suboptimal ist! Ich habe jetzt seit zwei Wochen immer wieder verschiedenste Tests mit unterschiedlichsten Parametern in ctorrent durchgeführt und wirklich an allen Schrauben gedreht. Habe auch mal 10 Rechner direkt an den Switch des Servers gehängt, um Netzwerkprobleme auszuschließen.
Fazit: Egal was ich auch immer versucht habe: es werden maximal 5-10 Clients versorgt und der Rest bleibt hängen oder fällt auf rsync zurück, was mir das Netzwerk dicht macht. Da ich momentan den 22.04 Client in der Schule verteile und immer wieder Bugfixupdates nachschieben muss ist die Situation wirklich „ätzend“, weil ich das neue Image immer nur Tröpfchenweise verteilen kann…das dauert bei 200 Clients unangenehm lang…und obwohl ich immer nur 10 Clients aufwecke bleiben trotzdem noch manche hängen bei 0%. Bei der 7.0 habe ich alle 200 Clients gleichzeitig aufgeweckt und das neue Image war in 15 Minuten auf allen Rechner. Die momentane Situation nervig…das soll natürlich bitte nur eine Zustandsbeschreibung und keinesfalls eine Kritik sein…bin ja selber Schuld, wenn ich auf Testing gehe!
Frage also: ist das ein Problem, was in der Vehemenz nur bei mir auftritt? Wie ist das bei euch? Wie können wir ggf. das Problem debuggen…aus den logdateien kann ich nichts lesen… . Hat jemand eine Idee für einen Ansatz?
Danke und VG
Dominik
Hallo zusammen,
wie gestern geschrieben habe ich
# Max bandwidth up (unit KB/s, default unlimited)
MAXUP="102400"
gesetzt. Und siehe da, das Netz ist nicht mehr zu 100% ausgelastet und das Image wird gleichzeitig auf alle Clients verteilt.
Ich habe die Client mit linbo-remote -r info -b 1 -w 2 geweckt und vorher mit linbo-remote -r info -p partition,format,initcache,sync:1,start:1 dafür gesorgt, dass die Clients alle das Image (9GB) ziehen müssen.
Anfangs wurden nicht alle Clients versorgt. Aber nach und nach haben dann alle Clients das Image geladen. Am Ende (nach ca. 15 Minuten) waren dann alle Clients fast gleichzeitig fertig.
Gruß,
Mathias
2 „Gefällt mir“
Ich hatte unter vielen Anderen auch den von dir genannten Wert MAXUP=102400 versucht und keinerlei Änderungen im Verhalten festgestellt…welche Faktoren bestimmen denn diesen Wert…vielleicht ist das vom Netz oder der Imagegegröße abhängig…
Als ich MAXUP="" gesetzt hatte, war der maximale Upstream meines Servers 110 MB/s.
Also habe ich meinen Server heute etwas gebrems (100 MB/s).
Ich versuche es morgen nochmal…
Hallo Mathias,
Als ich |MAXUP=„“| gesetzt hatte, war der maximale Upstream meines
Servers 110 MB/s.
du meinst, als du den Upload noch nciht begrenzt hattest lieferte der
Server maximal 110 MB/s
Also habe ich meinen Server heute etwas gebrems (100 MB/s).
Und nachdem du auf 100 MB/s gedrosselt hattest war es besser?
Hast du den ctorrentdienst nach Editieren der Datei neugestartet oder
nur den service reloaded?
LG
Holger
Hallo Holger,
Ja. Die Clients haben nach kurzer Zeit alle das Image geladen und waren fast gleichzeitig fertig.
Das heißt, die Clients, die später angefangen haben, haben aufgeholt. Ich könnte mir vorstellen, dass sie von den Clients, die bestimmte Teile bereits heruntergeladen haben, versorgt wurden.
Ich vermute, dass im unbebremsten Zustand, der Tracker nicht oder nur sehr langsam erreichbar war. Das würde auch erklären, warum die Clients nur vom Server ziehen…
Ich habe ihn mit linbo-torrent restart neu gestartet.
Gruß,
Mathias
Sehr gut, @rettich. Ich hoffe das funktioniert auch bei den anderen.
VG, Thomas
bei mir nicht…gerade nochmal mit diesem Wert in allen drei Rechnerräumen getestet. Ich habe aber einfach den Eindruck, dass die Rechner im Raum nicht gegenseitig seeden. Es werden vom Server in der Regel so 4-12 Clients versorgt und die anderen warten…wenn dann einer fertig ist, fängt ein anderer an sich das Image vom Server zu holen. Einige Rechner bleiben für immer bei 0% hängen, andere fallen irgendwann auf rsync zurück und zwar meisten wesentlich später als der eingestellte Timeout. Ich teste aber nochmal die Tage mit verschiedenen Werten…
…nur eine Randnotiz: ich habe vom Server bis zu den Switchen der Rechnerräume jeweils eine 10GBit OS2 Leitung liegen…vielleicht muss ich den Wert daher höher ansetzen? …irgendwie bin ich verwirrt!?
VG
Hallo Dominik,
bei mir sieht es so aus: egal wieviele ich starte, es bekommen immer nur
10-12 das Image: allerdings wechseln diese während des Verteilens: also
nicht wie bei dir, wo die die was bekommen, ziehen, bis sie fertig sind.
Bei mir fällt also auch ein Cleint der schon was bekommen hat plötzlich
ab und zählt den TimeOut hoch.
Bei 30 Clients schaffen es etwa 3 nicht vor Ende des TimeOuts was zu
bekommen.
Bei den anderen kommt wieder was an, bevor der TimeOut durch ist.
Was mir geholfen hat: ich habe einen virtuellen Client mit dem Image
gestartet und in linbo stehen lassen. Dann lasse ich ihn einmal per
initcache:torrent nach dem aktuellen Image schauen (das er schon hat):
dann seeded er definitiv mit: und das bringt wirklich was, obwohl er auf
dem KVM-Server läuft auf dem auch der lmn Server gelichzeitig läuft.
Es scheint also nciht an der Bandbreite des Uploads zu liegen (das sind
bei mir 10GB/s vom Server bis zum Backboneswitch (L3) und von dort aus 1
GB/s zum Raumswitch und dort 1 GB/s pro Client).
…nur eine Randnotiz: ich habe vom Server bis zu den Switchen der
Rechnerräume jeweils eine 10GBit OS2 Leitung liegen…vielleicht muss ich
den Wert daher höher ansetzen? …irgendwie bin ich verwirrt!?
… ich dachte eher, dass du weniger einstellen mußt.
Mathias hat ja einen Hinweis gegeben, dass er den Wert vorher abgelesen
hat: was der Server vorher maximal geliefert hat (110 MB/s) und da ist
er drunter gegangen ( 100MB/s).
Mit dem script hier aus ask kannst du dir ja die screens anschauen: da
kannst du dir auch den screen am server vom torrentdienst anschauen: und
da steht, was er gerade her gibt…
Natürlich wäre es sehr seltsam, wenn du weniger brauchen würdest, obwohl
du mit 10 GB/s angebunden bist: aber das wäre dann der nächste Schritt:
warum geht nicht mehr? Geht auch mit samba nicht mehr?
LG
Holger
Hallo Holger,
…das macht die Sache nicht weniger rätselhaft. In jedem Fall läuft das nicht annähernd so „fluffig“ wie mit dem alten Torrent. Da du nochmal ein anderes Verhalten hast als ich, stützt das meine Vermutung, dass die Netzwerkumgebung eine entscheidende Rolle spielen muss.
…gerade versucht und du hast Recht, dass sorgt zumindest dafür, dass jetzt bis auf zwei, drei Rechner in einem Raum das Image per Torrent bei den Clients an kommt. Die zwei drei Übrigen hängen aber dauerhaft ohne auf rsync zurück zu fallen. Es werden jetzt ca. 15 gleichzeitig versorgt, 5 - 10 hängen eine Weile und bekommen dann ihr Image. Also seedet der virtuelle Client definitiv mit.
habe ich mit verschiedenen Werten gemacht…hat nichts gebracht.
…doch da geht wesentlich mehr. Z.B. auch wenn ich eine große Datei von einem Client in die Nextcloud schiebe, was ja https ist.
Mit dem alten Torrent ging ja auch viel mehr durch die Leitung…wie gesagt ich habe knapp 200 Clients gleichzeitig geweckt, davon wurden 40 vom Server versorgt und die Restlichen haben sich gegenseitig versorgt. Da war ein 8GB Image in 15 Minuten in der ganzen Schule verteilt.
Danke mal für den Tipp mit dem virtuellen Seeder…aber prinzipiell kann es das eigentlich noch nicht gewesen sein, da es ein Rückschritt ist und die Komplexität jetzt nicht gerade senkt. Ich muss ja in jedes Subnetz einen Seeder stellen, dass wären dann für alle Gebäudeteile min 10 Stück…das macht dann andere Probleme.
Mir fällt nur nichts mehr ein, wo ich noch drehen könnte…
LG
Dominik
Hallo,
mal ins Unreine geschrieben: MTU?
Beste Grüße
Thorsten
Hallo Dominik,
Danke mal für den Tipp mit dem virtuellen Seeder…aber prinzipiell kann
es das eigentlich noch nicht gewesen sein, da es ein Rückschritt ist und
die Komplexität jetzt nicht gerade senkt. Ich muss ja in jedes Subnetz
einen Seeder stellen, dass wären dann für alle Gebäudeteile min 10
Stück…das macht dann andere Probleme.
mein virtueller Seeder ist im Servernetz 
LG
Holger
Hallo zusammen,
ich habe eben nochmal einen Probegurchgang gemacht. 16 Rechner 9GB-Image. Diesmal habe ich die Zeit gestoppt. Bis alle da waren hat es ziemlich genau 10 Minuten gedauert.
Das mit der Bandbreite ist so eine Sache:
Super Leitungen, Super-Switch, aber der Server liefert aus welchen Gründen auch immer nur 80 MB/s. Dann sollte man’s mal mit MAXUP="71680" (70*1024) probieren.
Bei mir läuft alles auf Proxmox. Am Anfang habe ich in den VMs als Netzwerkkarte die Intel E1000 „verbaut“. Die Download-Geschwindigkeit war ziemlich schlecht. Dann habe ich hier im Forum gelesen, dass die VirtIO (paravirtualized) bessere Performance bringt. Und genau so war’s.
Schaut doch mal (mit screen -r imagename.qcow2.torrent) mit welcher Geschwindigkeit die Daten tatsächlich hochgeladen werden.
Gruß,
Mathias
Hallo Mathias,
super Tip! Ich habe mal bei unlimited gemessen und bin im Schnitt auf Werte zwischen 116000 und 122000 gekommen. Habe bei MAXUP="112640" (=110MB/s) eingetragen und jetzt läuft es besser. Alle drei Räume waren jeweils nach 10 Minuten fertig und alle Rechner hatten das Image. Das ist schon mal ein Fortschritt. Wenn ich aber alle drei Räume gleichzeitig aufwecke ist die Situation nach wie vor nicht gut, da etliche Rechner auf rsync zurückfallen oder hängen bleiben. Da lässt sich vielleicht mit einem weiteren Seeder noch etwas nachhelfen.
Es scheint, dass der ctorrent extrem sensibel auf dieses MAXUP in Kombination mit der Netzwerkumgebung reagiert. Ich werde in den nächsten Tagen mal mit kleinen Werten um diese 110MB/s spielen und schauen ob da noch was herauszuholen ist. Mir ist aber wirklich völlig unerklärlich, warum bei 100MB/s Begrenzung und weniger das alles so schlecht läuft (hatte noch 75MB/s und 50 MB/s versucht), mit allen beschriebenen Problemen und es bei 110 MB/s Begrenzung ist es deutlich besser funktioniert?
Optimal ist das insgesamt nicht…
VG
Dominik
Hallo Dominik,
Kann ich mir auch nicht erklären. Hast du die Rechner mit linbo-remote -r raum -b 1 -w 1 nacheinander eingeschaltet?
Gruß,
Mathias
Ja. Habe ich so gemacht.
VG
Dominik
Hi!
Hat jemand eigentlich auch mal mit dem MAXDOWN-Wert experimentiert? Im Gegensatz zu MAXUP tangiert der ja nur die Linbo-Clients, der Server muss ja nix downloaden.
VG, Thomas
Hallo zusammen,
ich habe heute einen Versuch mit MAXDOWN=„51200“. Dann hab ich noch zusätzlich 6 Rechner, als 23 Rechner, gesynct.
Diesmal gings leider ziemlich schief. Statt der 10 Minuten vom letzten mal hats heute fast 2 Stunden gedauert. Interessanterweise ging kein Rechner auf rsync. Die Download-Raten gingen ziemlich in den Keller (So um 1000kB/s).
Interessanterweise ging die Uploadrate des Servers auch in den Keller (Um 10000kB/s).
Ich glaube, es lag an den 6 zusätzlichen Clients. MAXDOWN=„51200“ hatte wahrscheinlich keinen großen Einfluss. Die 50MB/s hat kein Client erreicht.
Wie kann man feststellen,
- wie viele Clients seeden?
- welcher Client seedet?
- wie groß ist die Uploadrate eines Clients?
Gruß,
Mathias
Hallo zusammen,
ich hab da noch eine Frage:
In der Screen-Ausgabe sieht man soetwas:
/ 0/19/24 [36483/36483/36483] 0MB,52817MB | 0,11257K/s | 0,768K E:0,3
Kann mir jemand sagen, was diese Zeile bedeutet?
[36483/36483/36483] das scheinen die Slices zu sein. Aber warum 3 mal?
0MB,52817MB das scheint die Upload-Datenmenge zu sein. Sind die 0MB die Downlod-Datenmenge?
0,11257K/s ist das die Download- Upload-Übertragungsrate?
Gruß,
Mathias