ich hab auch mal ne Frage

[Xman]

Ich schreib dies mit Absicht in emule Allgemein, denn ich hab das folgende bis jetzt mit jedem Mod, mit jeder Version so gesehen.

Man fängt einen neuen Download an. Dann kommt es ja manchmal (sogar oft) vor, daß man als erstes den ganz allerletzten Chunk bekommt. Emule legt in diesem Fall also sein part-file an. Wenn dieses file so 700-800 MB hat, dann dauert das je nach Festplatte schon mal >1 Minute. Während dieser Zeit steht alles im emule bei mir still! Um genau zu sein: emule schickt kein einziges TCPIP Packet mehr raus. Somit wird dem Download auch nicht mehr geantwortet. Als Folge brechen dann viele der gerade übertragenden Quellen den Download ab.
Inzwischen hab ich ja ne etwas schnellere Platte. Hier ist das nicht mehr so gravierend. Einen gewaltigen Zacken in meiner Statistik hab ich dennoch.

Als ergänzenden Hinweis mölcht ich noch sagen: beim fertigstellen eines Files, wo schließlich auch 800MB kopiert werden müssen gibt es keinen Einbruch. Ich denke also, daß die interne Priorität des Anlegends einer neuen Dummy-part-Datei zu hoch ist.

Hab ihr ähnliche Erfahrungen gemacht ?

[MxM.]

eigentlich nicht, aber interessant, unter umständen achte ich mal drauf


bei mir laufen 4x 7200 umin platten.
emule läuft auf einer anderen platte als windows, und auch auf einer anderen als die swap datei vom windows.

alle platten NTFS.

[Ov3rKiLL]

Jep, also besonders bei Riesen-Files, da kommt es auf meinem Low-End-PC schonmal des häufigeren vor, dass der emule für einige Minuten gar nicht mehr reagiert (also auch nciht auf das Klicken, um z.B. die Kartei zu wechseln). Was mir dabei aufgefallen ist: Dieses Problem tritt besnders ausgeprägt auf, wenn ich esel gerade neu gestartet habe und direkt anschließend ne große Datei adde. Wenn er vorher schon einige Zeit gelaufen ist, klappt das auf jeden Fall besser (also das Programm reagiert dann wieder schneller).

Woran das liegen mag, weiß ich auch nicht genau. Ich könnte mir allerdings vorstellen, wieso das Fertigstellen der Dateien nicht so viel Performance raubt wie die Erstellung der Dummy-Datei: Beim adden eines Downloads muss ja noch so einiges geprüft werden, z.B. ob noch genug Platz auf der Platte ist (was ja beim am Ende geschehende "Füllen" der Dummy-Datei nicht erfolgt), wurde die Datei schon gesaugt, etc. Und dabei fängt er dann wahrscheinlich gleich an Quellen zu suchen (weiß ich nicht genau, da er zu dieser Zeit bei mir gar nix mehr anzeigt). Alles in allem sorgt dann wohl dafür, dass besonders schwächere Systeme in die Kie gezwungen werden.

[Xman]

Ov3rKiLL,
stimmt, das hab ich oben ganz vergessen zu schreiben, daß man während des Anlegens des Files nirgends mehr klicken kann.
Mit dem Abfragen der neuen Quellen hingegen hat das denk ich nichts zu tun. Wie gesagt denk ich, daß der Prozeß der das File generiert allen anderen Prozessen des Mulies "die Kraft raubt".

[Blomy]

Mein Rechner bockt ein bischen. Aber UL/DL stabil - keine Einbrüche.
Muss aber warten, bis die HDD sich wieder beruhigt hat,
um mit anderen Sachen weiter machen zu können.

[Usul]

Wenn ich ehrlich bin, ist mir das Beschriebene noch nie aufgefallen. Ich gehe mal davon aus, das der DMA-Modus für die Festplatten bei den Betroffenen aktiviert ist, oder nicht? Wenn nicht, und die Platten laufen im PIO-Modus, kein Wunder. Falls es von Bedeutung ist, bei mir liegt der temp-ordner auf FAT32.

Mal an der Stelle etwas, was auch mit Plattenplatz zu tun hat: Wenn eine Datei beendet wird, und incoming und temp liegen auf der gleiche Partition, dann wird die betroffen Datei aus temp nach incoming verschoben und nicht kopiert. Es kam mal irgendwo die Behauptung auf, das man zum beenden einer Datei soviel Platz haben muß, wie die Datei groß ist, das stimmt aber halt nur dann, wenn temp und imcoming auf verschiedenen Partitionen liegt, weil die Datei aus temp nach incoming kopiert wird und dann im temp gelöscht wird. Konkretes Beispiel: Ich hatte noch 500MB Platz auf Platte, eine 700MB-Datei wurde beendet, kein Problem. Daraus kann man auch schließen, das es von Vorteil ist, wenn Temp und Incoming auf der gleichen Partition liegen, weil man a) weniger Platz braucht und b) das beenden schneller geht.

[Xman]

Usul,
da kann ich Dir wieder nicht zustimmen, daß Verschoben statt kopiert wird. Also bei mir wird immer kopiert.
Vielleicht ist das bei Dir wieder so ne ewombat-Geschichte, wo dieser mal wieder seinen eigenen Weg geht (in dem Fall sehr sinnvoll).

Noch wa szu meinem Problem:
Es war egal welches Betriebsystem ich nutze (w2k oder XP). Auch egal an welchem Controler die Platte hängt (Standard IDE oder Raidcontroler). DMA ist auch aktiv.

[Usul]

Xman,

Ok, momentan läuft bei mir Gnaddelwarz, ich werde nochmal hinschauen und kurz vor dem Beenden einer Datei die Partition so vollpflastern, das kaum noch Platz ist, und dann werden wir sehen, was passiert.

[Blomy]

Xman, es ist eindeutig kopieren. Beim Verschieben auf ein + derselben
Partition, wird ja nur der Header im Filesystem neu gesetzt. Die Datei bleibt
physikalisch am selben Ort. Und das Header schreiben ist eine Sache, die
in Bruchteilen von Sekunden erledigt ist.
Und die Zeit die Emule braucht, um eine Datei zu vervollständigen, zu
beobachten am Leuchten der HDD Led, kann nur kopieren sein.
Da muss ich Usul auch widersprechen.
Warum braucht dann Emule so viel Zeit, um eine Datei zu vervollständigen ?
Weil sie kopiert !
Und das macht jede Emule Version so.

[Usul]

So, Experiment vorbereitet. Temp und Incoming liegen wie gehabt auf einer Partition, so der Emule-Gott gnädig ist, wird in etwa 15 Minuten eine 250MB-Datei fertig werden, auf der Partition sind noch 50 MB frei. Laut euch dürfte das ja nicht funktionieren, oder? Was kommt eigentlich für eine Meldung dann, nicht genug Platz zum beenden eines Downloads oder so? Außerdem läuft nebenher CPUCool und protokolliert die Festplattenaktivitäten.

Momentan noch 11 Minuten bis zur Deadline, wenn noch jemand Vorschläge zur Ergänzung des Experiments hat, die Zeit läuft

[Blomy]

Usul, wir treffen uns nachher alle in der Board-Kneipe und
nehmen dann von dir die Huldigungen gnädig entgegen. Natürlich knieend vorgetragen.
Anrede an uns ist : Meister oder so ähnlich.

[Usul]

So, *hämisch grins*, es hat wunderbar funktioniert. Auf der Partition sind immer noch nur 50MB frei, nur befindet sich die Datei jetzt fein säuberlich im incoming, und nicht mehr im temp. Der Beenden-Vorgang hat, wenn es hoch kommt, nur 2-3 Sekunden gedauert, CPUCool hat nur eine kurze Auslastungsnadel bei der Plattenaktivität gemeldet. Selbst wenn ich sage, das der Beenden-Vorgang 5 Sekunden gedauert hat, dann wären das bei 250MB 50MB/s, und das auf der selben Platte, niemals, das schafft meine nicht. Ich hab mal zu Testzwecken die eben fertiggestellte Datei auf eine andere Partition kopiert, das hat doppelt so lange gedauert wie der ganze Beenden-Vorgang, bei dem noch die part.met-Datei gelöscht und die ganzen Quellen aus dem Speicher entfernt werden. Also bei mir wird meiner Meinung nach verschoben, ich wüßte sonst nicht, wie Emule dieses Kunststück sonst hinbekommen soll, beim Kopieren+Löschen müßte die Datei ja irgendwann einmal doppelt vorkommen, das kommt aber weder zeitlich noch platztechnisch hin.

blomy
Wenn du dich mal irrst, komme ich darauf zurück .

[Xman]

bevor ich Usul nun mit "euer Gottheit" anrede , stell ich einfach mal die Frage in den Raum: hat das Gnaddelwarz vielleicht auch optimiert ?

[Blomy]

Meister Usul, ich habe da mal eine Frage ?

Meine Rechnung war halt eben : Emule braucht so
ca. 20 - 40 sec, um eine 700 MB Datei zu vervollständigen.
Und bei diesem Vorgang leuchtet dauernd die HDD Led.
Und soviel Zeit brauche ich auch mit WinCMD um eine Datei zu kopieren.
Windows Explorer ist hierfür zu langsam.
Daraus habe ich geschlossen, das es kopieren ist,

@ Xman nicht drücken

[Usul]

Das Problem ist, das ich eigentlich noch nie ein Problem mit dem Beenden hatte. Bei mir ist die Konfiguration schon immer so, das temp und incoming auf der gleichen Partition sind, Platzprobleme hab ich immer mal, so das es öfters mal der Fall ist, das weniger 500MB frei sind. Aber seit meiner Emule-Zeit (irgendwann September letzten Jahres war Erstkontakt) war noch nie das Problem, das ich eine Datei nicht beenden konnte, weil zu wenig Platz da ist. Ich weiß nicht mal, was Emule dann für eine Fehlermeldung ausgibt, könnt ihr mir das nicht mal sagen, ich hab vorhin schon gefragt. Das eine Datei nicht runtergeladen werden kann, weil kein Platz da ist, das passiert öfter als mir lieb ist. Deswegen kann ich auch nicht nachvollziehen, wo bei anderen immer das Problem ist.

@blomy

Ist mir schon klar, wie du auf deine Annahme gekommen bist, bei mir ist es halt nur anders, aus welchen Gründen auch immer. 20-40 Sekunden dauert das beenden bei mir niemals. 10 Sekunden ist Maximum. Ich hoffe, es vergißt hier niemand, das es nur darum geht, wenn incoming und temp auf einer Partition liegen. Wenn es zwei verschiedene sind (d: und e: meinetwegen), muß zwangsweise kopiert+gelöscht werden.