Ich erzähle ein bisschen mehr davon im Nachbarn Topic.
Es gab relativ viele Umstellungen um die Custom Felder auf dem Landing Page editierbar zu machen, ich hoffe es funktioniert weiterhin alles gut.
… macht das etwas an der torrent Performance des Servers?
Da hab ich nämlich noch größere Probleme: von meinen 60 Clients fallen
sehr viele auf rsync zurück, weil sie viel zu lange nichts vom Server
erhalten.
(ich habe Untersuchungen angestellt und mach dazu einen Tread auf. Wenn
4.0.19 daran was gedreht hat, dann teste ich erst nochmal, bevor ich
einen Tread auf mache).
Moin, moin,
ist es eigentlich richtig, dass die Sync-Funktion bei Windows-Images nach wie vor nicht funktioniert? Ich erhalte bei dem Versuch regelmäßig Fehlermeldungen und die Synchronisation bleibt hängen. (Lino 4.0.17 mit einem aktuellen Windows11-Image)
Ich weiß, dass es bei der 7.0 da Probleme wegen des NTFS-Treibers gab, habe aber keine Ahnung inwieweit hier Besserung in Sicht ist.
Grüße
Carsten Lomann
ist es eigentlich richtig, dass die Sync-Funktion bei Windows-Images
nach wie vor nicht funktioniert? Ich erhalte bei dem Versuch regelmäßig
Fehlermeldungen und die Synchronisation bleibt hängen. (Lino 4.0.17 mit
einem aktuellen Windows11-Image)
ich weiß es nicht, weil ich den „nur sync“ sowiso nicht benutze: warum
auch, wenn neu+start schneller ist …
Ich blende bei Windows imemr den sync Knopf aus und lege den Default auf
neu+start
Ich weiß, dass es bei der 7.0 da Probleme wegen des NTFS-Treibers gab,
habe aber keine Ahnung inwieweit hier Besserung in Sicht ist.
Vielleicht gibt es irgend wann einen ntfs Treiber der das mit den
schattenkopien (Hardlinks unter Windows) richtig macht: aber solange der
nicht auch schneller ist als das ntfsclone, würde ich das „sync aus“
sowiso beibehalten …
macht das etwas an der torrent Performance des Servers?
Nope. Hast du mal an den MAXDOWN/MAXUP-Schrauben gedreht?
nein, noch nicht.
Das liegt an mehreren Dingen:
ich weiß nicht genau wie ich die Schraube einrichten soll: was will
der in der config: kB/s? MB/s? …
es ist natürlich schon etwas seltsam das pro Client ein zu schränken:
dann dauert ja das syncen von wenigen Clients länger als es müßte, und
mir scheint es nicht so, als sei die Summe von 60 mal diesem Maximum das
was ich am Server als „maxdownload“ gesehen habe (siehe unten) …
es ist sehr schwer zu testen. Das letzte mal als ich ein Windowsimage
in meinen zwei Computerräumen verteilt habe war das ein echtes Desaster.
14 GB Image auf zwei Räume (60 Clients).
Im ersten Raum (31 Rechner) sind 17 Rechner auf rsync zurückgefallen:
die hab ich dann neugestartet, damit die Netzwerk und Serverlast wieder
runter geht (manche sind später nochmal auf rsync zurückgefallen). Die
ersten 50 Minuten gab es auch keinen nennenswerte „andere“ Last auf
Server oder Netzwerk: das war nämlich vor der ersten Stunde.
Alles in allem waren die letzten Rechner nach 1,5 Stunden erst fertig
… ich hab die Clients alle die ganze Zeit beobachtet und ab und zu
auch mal auf dem Server nachgesehen (mit dem screen-manager.sh)
Der zeigte das hier an:
META INFO
Announce: http://10.16.1.1:6969/announce
Created On: Thu Mar 31 00:34:27 2022
Piece length: 262144
Created with: Enhanced-CTorrent/dnh3.3.2
FILES INFO
<1> win10-lmg-intel.qcow2 [14589674496]
Total: 13913 MB
warn, couldn't set bit field refer file
"win10-lmg-intel.qcow2.torrent.bf": No such file or directory
This is normal if you are seeding.
Listening on 0.0.0.0:2701
Press 'h' or '?' for help (display/control client options).
> 0/0/1 [55541/55656/55541] 0MB,0MB | 0,0K/s | 0,0K E:0,1 Checking: 99%
Checking completed.
FILES INFO
<1> win10-lmg-intel.qcow2 [14589674496] 55656/55656 (100%)
Total: 13913 MB
Seed for others 100000 hours
/ 0/22/60 [55656/55656/55656] 0MB,175692MB | 0,29120K/s | 0,31360K
E:0,16
schnelle Clients (also die größten Zahlen die ich gesehen habe) zeigten
um die 13000K/s an
Die allermeisten schwankten aber sehr stark und eben immer wieder bis
auf 0 K/s und dann auch bis der Timeout durch war und sie rsync genommen
haben.
An Clients und Server hab ich nichts verändert seit dem upgrade auf linbo 4.
Vorher konnte ich Jahrelang beide Räume gleichzeitig ohne Probleme
bespielen: die haben dann auch alle brav mit 13000 K/s gezogen…
Wenn ich nun also 13 000 K/s als Maximum eintrage, dann entlastet das
den Server ja gar nicht wirklich, weil dann schon zwei Clients ihn
„zumüllen“ würden. (siehe screen oben: 31360 K/s am Server).
Also hab ich das Testen erstmal verschoben bis ich mir hier mehr im
klaren bin, was ich machen sollte.
und dann teste ich es im Semianr, weil da die Rechner sicher aufwachen
und ich das also Nachts laufen lassen kann.
Wenn du MAXUP einschränkst, dann ist das der Wert, den ein Seeder zulässt pro Client, d.h. der Leecher kann natürlich von mehr Seedern mit größerer Geschwindigkeit herunterladen. Wenn ich es mir recht überlege, wäre es ja durchaus sinnvoll, diese Werte für Server und Clients unterschiedlich konfigurierbar zu machen, oder? Z.B. Server unlimited, Client limited.
Timeout mal erhöhen? Ich habe nur 36 Clients, die gleichzeitig ziehen können, konnte aber noch nie einen Fallback beobachten. Sind allerdings in 3 verschiedenen Subnetzen zuhause.
Best Practice war es aber schon immer zunächst ein Paar Seeder zu starten bevor man die Meute loslässt.
Wenn du MAXUP einschränkst, dann ist das der Wert, den ein Seeder
zulässt pro Client, d.h. der Leecher kann natürlich von mehr Seedern mit
größerer Geschwindigkeit herunterladen. Wenn ich es mir recht überlege,
wäre es ja durchaus sinnvoll, diese Werte für Server und Clients
unterschiedlich konfigurierbar zu machen, oder? Z.B. Server unlimited,
Client limited.
baumhof:
bis der Timeout durch war
Timeout mal erhöhen?
ich weiß nciht wie.
Er sit aber schon deutlich höher als früher.
Da waren es 120 Sekunden, jetzt geben sie nach über 300 Sekunden erst auf.
Ich habe nur 36 Clients, die gleichzeitig ziehen
können, konnte aber noch nie einen Fallback beobachten. Sind allerdings
in 3 verschiedenen Subnetzen zuhause.
die beiden Räume sind jeweils in einem eigenen Subnet.
Best Practice war es aber schon immer zunächst ein Paar Seeder zu
starten bevor man die Meute loslässt.
wenn ich „von Hand“ verteile, dann mache ich das auch so.
Das hat früher gut geklappt: damals war es aber nicht nötig: ich konnte
auch ganze Räume „auf einmal“ starten und das 14 GB Image verteilen ohne
rsync Fallback zu beobachten.
use linbo warmstart also for uefi systems. type bzImage64 ermöglicht den Warmstart nach Linbo-Update auch auf UEFI-Systemen und verbessert u.U. auch das Verhalten bei BIOS.