FTP Preload konfigurieren

DennisMoore · Post by *DennisMoore » 2012-12-22, 13:10 UTC

Schönen guten Tag,

ich würde gerne wissen ob es möglich ist irgendwo in der Konfigurationsdateien festzulegen dass der FTP-Client im Total Commander beim Dateiupload x KB/MB/GB vorladen soll.

Hintergrund ist, dass wenn ich neben dem FTP-Upload (4 MB/Sek) weitere festplattenintensive Operationen durchführe, diese stark einbrechen während die FTP-Operation läuft. Bei gewöhnlichen Dateioperationen gibts hingegen keine Probleme.

Ich würde es gerne so einstellen dass der TC beim Start eines Dateitransfers so ungefähr 1 GB einer Datei vorlädt.

Dalai · Post by *Dalai » 2012-12-22, 13:58 UTC

DennisMoore wrote:Ich würde es gerne so einstellen dass der TC beim Start eines Dateitransfers so ungefähr 1 GB einer Datei vorlädt.

Wohin soll TC eine solche Datenmenge vorladen? In den RAM ist ja wohl lächerlich. Auf Festplatte? Genau blödsinnig, weil damit das Problem weiterhin besteht.

Begrenz einfach die Geschwindigkeit, mit der die Übertragung läuft. Das geht, wenn man den Transfer gleich vor Beginn in den Hintergrund schickt (nicht nachträglich!).

MfG Dalai

DennisMoore · Post by *DennisMoore » 2012-12-22, 14:47 UTC

Natürlich in den RAM. Warum sollte das lächerlich sein?
Lächerlich finde ich es eher wenn man die Datentransfergeschwindigkeit runtersetzt obwohl es nicht Not tut und gleichzeitig vielleicht noch 2 GB RAM frei hat der nicht für derartige Optimierungen genutzt wird.

Falls ich heute eine Situation habe wie vorhin beschrieben, schiebe ich die FTP-Daten vor dem Upload in eine RAM-Disk. Dadurch werden die vielen Plattenzugriffe des Clients auch vermieden, aber es wäre halt schön wenn man die RAM-Nutzung direkt im TC konfigurieren könnte. Dann brauchts diesen Umweg nicht.

Dalai · Post by *Dalai » 2012-12-22, 15:35 UTC

DennisMoore wrote:Natürlich in den RAM. Warum sollte das lächerlich sein?

Weil das nicht gehen dürfte, weil man dafür - meiner Einschätzung nach - einen zusammenhängenden Block Speicher braucht; und ein solch großes Stück findest du auch auf Rechnern mit 16 GiB wohl nur direkt nach dem Booten.

Lächerlich finde ich es eher wenn man die Datentransfergeschwindigkeit runtersetzt obwohl es nicht Not tut und gleichzeitig vielleicht noch 2 GB RAM frei hat der nicht für derartige Optimierungen genutzt wird.

Nö, er wird für andere Optimierungen genutzt, nämlich als Dateicache.

MfG Dalai

HolgerK · Post by *HolgerK » 2012-12-22, 16:45 UTC

DennisMoore wrote:Lächerlich finde ich es eher wenn man die Datentransfergeschwindigkeit runtersetzt obwohl es nicht Not tut und gleichzeitig vielleicht noch 2 GB RAM frei hat der nicht für derartige Optimierungen genutzt wird.

Viel Speicher als Lese-Cache einzusetzen ist nicht unbedingt eine Lösung für Problem die evtl. ganz wo anders zu suchen sind. 1GByte Speicher mit maximaler Geschwindigkeit von der Festplatte zu lesen kann auch bedeuten, dass der Rechner für 10-50 Sekunden komplett damit beschäftigt ist den Cache zu füllen (und dabei andere Prozesse noch stärker ausbremst).

Gibt doch mal mehr Details zu deinem Problem an:
- FTP Upload über (W)LAN?
- Wohin? Zu einem entfernten Server oder lokalen NAS?
- Wirklich 4MByte/s (oder gar 4Mbit/s)?
- Was genau verstehst du unter festplattenintensiven Operationen?
- ... auf einer lokalen Festplatte oder einem Netzlaufwerk (ist ja meist auch eine Festplatte)?
- Wird eine zweite TC-Instanz ebenfalls ausgebremst?

4MByte/s im Hintergrund von der HD zu lesen sollte eigentlich einen aktuellen Rechner nicht allzusehr ausbremsen.

Falls ich heute eine Situation habe wie vorhin beschrieben, schiebe ich die FTP-Daten vor dem Upload in eine RAM-Disk.

Vielleicht hilft es ja bereits, wenn du den Speicher der Ramdisk mal lieber dem Betriebssystem zum Cachen von festplattenintensiven Zugriffen gönnen würdest.

Gruß
Holger

DennisMoore · Post by *DennisMoore » 2012-12-23, 12:31 UTC

Dalai wrote: Weil das nicht gehen dürfte, weil man dafür - meiner Einschätzung nach - einen zusammenhängenden Block Speicher braucht; und ein solch großes Stück findest du auch auf Rechnern mit 16 GiB wohl nur direkt nach dem Booten.

Wenn ich ne Anfrage an die Speicherverwaltung von Windows stelle und 1 GB RAM anfordere, dann bekomme ich den auch, egal ob es einen zusammenhängenden Blöck gibt oder nicht. Oder, wenn zu wenig Speicher frei ist, bekomme ich ihn eben nicht sondern einen Fehlercode. Das geht auf jeden Fall, behaupte ich einfach mal so. Ich habe in meinen Programmen keine Probleme riesige Stücke Speicher anzuforden und zugeteilt zu bekommen, und zwar so lange bis Windows das Swappen anfängt.

Dalai wrote: Nö, er wird für andere Optimierungen genutzt, nämlich als Dateicache.

Windows lädt die Datei auch komplett in den RAM-Cache. Das ist nicht das Problem. Leider pfeift der TC darauf dass es die Datei dort schon gibt.

HolgerK wrote: Vielleicht hilft es ja bereits, wenn du den Speicher der Ramdisk mal lieber dem Betriebssystem zum Cachen von festplattenintensiven Zugriffen gönnen würdest.

Keine Sorge. Wenn ich ne 1 GB RAMDisk erstelle hat Windows immer noch 30GB RAM frei an dem es sich austoben kann.

HolgerK wrote: Gibt doch mal mehr Details zu deinem Problem an

Das Problem ist ganz einfach, wie ich in 2 Screenshots illustrieren möchte:

Kopiert man Drive2Drive verhält sich der TCMD beim Lesen/Schreiben der Daten so
Kopiert man die Daten von der Platte auf nen FTP-Server verhält er sich so

Das Problem sind die kleinen Häppchen die er beim FTP-Upload verwendet. Je schneller der Upload desto mehr wird die Platte beansprucht. Kommt nun noch ein anderer Vorgang auf der Festplatte hinzu beginnt sie zu rödeln wie verrückt und die Datenraten beider Operationen brechen ein. Auf SSD ist dies kein Problem, aber auf normalen HDDs schon.

Daher wäre es toll wenn der TCMD die Datei erstmal schnell (mit großen Häppchen) in den RAM liest und dann überträgt.

HolgerK · Post by *HolgerK » 2012-12-23, 12:55 UTC

Probiere doch mal aus, was passiert wenn du in der wcx_ftp.ini unter [General]

F1,4b,wcx_ftp.ini wrote:UploadBlockSize=512 Size of upload buffer. On fast networks, you may try larger sizes like 1492 or even 8192

auf wirklich grosse Werte (>32K) setzt.

Gruß
Holger

Post by *ghisler(Author) » 2012-12-23, 14:32 UTC

>64k geht nicht, verssuchen Sie UploadBlockSize=32768 oder UploadBlockSize=49152.

DennisMoore · Post by *DennisMoore » 2012-12-23, 19:06 UTC

Danke für den Hinweis. Hab UploadBlockSize aufs Maximum 65535 gesetzt. Jetzt flutscht es schon deutlich besser.
Muß nach Weihnachten mal schauen ob das so ausreicht.
Aber die Konfigurationseinstellung mit der 128-fachen Chunkgröße ist auf jeden Fall schonmal ne super Instantlösung.

Frohes Fest und guten Rutsch

HolgerK · Post by *HolgerK » 2012-12-23, 19:19 UTC

DennisMoore wrote:Hab UploadBlockSize aufs Maximum 65535 gesetzt.

Im Land der Zweierpotenzen solltest du lieber 2^16-4096 (8192, 16384) benutzen, um immer ganze Cluster auf der Ziel- und Quell-HD zu verarbeiten.
Und, wie sieht's mit der Uploadgeschwindigkeit aus?
Ist die grösser geworden?

Frohes Fest und guten Rutsch

Dito
Holger

DennisMoore · Post by *DennisMoore » 2012-12-24, 12:09 UTC

Bei der echten Zweierpotenz 65536 weigert sich der FTP-Client auch nur ein einziges Byte zu übertragen. 65535 funktioniert hingegen. Daher nehme ich das.
Ob da nun 1 Byte fehlt oder nicht ist mir für das Ziel der ganzen Sache, nämlich die Festplattenbelastung zu minimieren erstmal egal.
Evtl. teste ich später nochmal mit dem nächstkleineren Wert.

Die Uploadgeschwindigkeit ist nicht gestiegen, aber die Plattenbelastung meines Rechners ist beim Upload spürbar gesunken.
Aber da mein Zielgerät (Dreambox 800 Set-Top-Box) von der Leistung eh nicht mehr an Transferspeed zulässt, kann es durchaus sein dass mit größeren Blöcken auch höhere Geschwindigkeiten ab einer gewissen MB/Sek-Grenze drin sind.

HolgerK · Post by *HolgerK » 2012-12-24, 13:12 UTC

DennisMoore wrote:Ob da nun 1 Byte fehlt oder nicht ist mir für das Ziel der ganzen Sache, nämlich die Festplattenbelastung zu minimieren erstmal egal.

Du entlastest die Kette Festplatten-Firmware/Schnittstellentreiber/Windows-API/CPU indem weniger Bytes in Puffern hin und her geschoben werden müssen wenn du ein Vielfaches der Blockgrösse einer Verwaltungseinheit der Disk benutzt (und zwar auch auf dem mageren Prozessor der Dreambox).

Evtl. teste ich später nochmal mit dem nächstkleineren Wert.

Ja, mach das mal. Glaube kaum, dass es eine messbaren Vorteil bringt 2^16-1 anstelle von 15*2^12 (oder 7*2^13, 3*2^14) zu benutzen.
Ich habe da immer nur Mitleid mit den armen CPU(s), die an irgendeiner Stelle dann wieder den Datenstrom auf Cluster(block)grössen zusammenfrickeln muss.

BTW:

Wenn ich ne Anfrage an die Speicherverwaltung von Windows stelle und 1 GB RAM anfordere, dann bekomme ich den auch, egal ob es einen zusammenhängenden Blöck gibt oder nicht.

Das stimmt so erst mal nicht. Ein Prozess bekommt einen kontinuierlichen Adressbereich vom Betriebssystem zu Verfügung gestellt, den er mit einer eigenen Speicherverwaltung (Heap) selber verwaltet.
Werden Speicherblöcke angefordert und (teilweise) wieder freigegeben, dann wird dieser Speicherbereich fragmentiert. Es reicht aus wenn nur eine einzige (mini-) Speicheranforderung mitten im Speicher benutzt bleibt, so dass nicht einmal 1GByte sondern nur 2*512kByte erfolgreich angefragt werden können.

Die virtuelle Speicherverwaltung (Stichwort pagefile swappen) ist ein anderer Bereich, und bedeutet nur, dass nicht alle dem Prozess zugeordneten Speichersegmente auch wirklich im physikalischen Speicher liegen müssen.

Mit 64Bit Programmen ist das nicht mehr ganz so relevant, aber bei 32Bit Prozessen kannst du manchmal froh sein wenn du einen durchgehenden Speicherbereich von 200-300 kBytes erfolgreich anfordern kannst.

Gruß
Holger

DennisMoore · Post by *DennisMoore » 2013-01-19, 17:13 UTC

So, ich habe jetzt eine Weile mit der Einstellung in der INI-Datei gearbeitet und der beste Wert den ich ermittelt habe ist 61440

Die Transfergeschwindigkeit hat sich netterweise um 500kbyte/Sek erhöht, die "Festplattenrödelei" hat etwas abgenommen, könnte aber noch mehr sein wenns nach mir ginge. Bei einem Transfer über CIFS hört man z.B. keinen Mucks von der Platte. Nehme mal an weil der Windows-Cache dabei exzessiver genutzt wird.

Ein kleines Problemchen gab es aber auch beim Upload von Dateien je nachdem welchen Zielspeicher ich auf der Dreambox wähle. Handelt es sich um den angestöpselten USB-Stick, dann hängt der Transfer alle paar Sekunden kurz und geht dann weiter. Ist der Zielspeicher die interne HDD der Dreambox, läuft der Transfer reibungslos ab.

Unterm Strich reicht mir die Verbesserung durch den INI-Wert erstmal aus. Werde jetzt sicherlich seltener auf ne RAMDisk zurückgreifen müssen. Bei Nutzung von mehreren VMWare oder beim Video konvertieren beispielsweise.

HolgerK · Post by *HolgerK » 2013-01-20, 10:52 UTC

Bei Nutzung von mehreren VMWare oder beim Video konvertieren beispielsweise.

Ist imho fraglich, ob da eine Ramdisk einen wirklich spürbaren Vorteil bietet.
Das Erste braucht primär viel Speicher (den hast du ja bereits).
Je größer du eine Ramdisk einrichtest um von dort eine VM zu starten, desto weniger Speicher gönnst du der Virtualisierung.
Beim Zweiten braucht es vor allem einen schnellen Prozessor (Mehrkern CPU oder GPU-Unterstützung wie z.B. Cuda oder OpenCL).
Der Datendurchsatz ist da selbst bei schnellen Prozessoren eher gering (5-10 GByte in 30 Minuten?).
Außerdem dauert es auch einige Zeit bis du eine VM oder Daten auf eine Ramdisk kopiert hast, um sie dort zu starten oder zu verarbeiten.

Denk mal über eine SSD nach.

Gruß
Holger

DennisMoore · Post by *DennisMoore » 2013-01-20, 19:47 UTC

Die Ramdisk bietet einen Vorteil, allerdings eben nur unter den von mir beschriebenen Szenarien. Ist auch sicher kein Problem auf das massig viele User stoßen werden.
Natürlich würde eine SSD auch helfen, aber auch dann müsste ich zuerst die zu übertragenden Daten drauf kopieren, genau wie in die Ramdisk. Außerdem würde der Kauf einer SSD ein Problem lösen, welches sich auch durch das Verhalten von Software lösen lassen würde. Solche Ausgaben scheue ich in der Regel.
Bin ja schon froh dass man den TC mit der INI-Datei umkonfigurieren kann. Hab mittlerweile rausgefunden dass Filezilla ebenfalls mit großen Blockgrößen arbeitet, aber ich hab natürlich lieber so viele Funktionen wie möglich in einem Programm.