UL:DL Ratio: 1 : 2.23 (1 : 1.62)
UL-Sessions successful: 230 avg. time: 24:47 mins | failed: 65 (can't connect: 33 | critical error: 2)
DL-Sessions successful: 822 avg. time: 18:43 mins | failed: 118 (can't connect: 0 )
Uploads Waiting: 4464 | Found Sources: 4156

S.U.I. successful: 84998 - failed: 355
Detected 1232 leechers, 56 credit thieveries
Corrupt blocks: 0 detected
Programm-Laufzeit: 1 T 0 h
Winsock: WinSock 2.0 Running
Virtual: 182.30 mb free: 1865.58 mb | Athlon/Duron optimization active

Schon seltsam, die einen sagen er läuft super (ich auch) und die anderen haben Probleme.
Woran liegt sowas?
Verschiedene Windowsversionen und updates? Manchmal schon sehr rätselhaft, schließlich setzen alle hier doch auf die "gleiche" Basis Windows auf.

Übrigens, trotzdem, daß ich beim Umbau meines Rechner vergessen hatte, meinen Userhash zu sichern, habe ich mit neuem Hash schon wieder ein 1:2,25.

Das lob ich mir!

Gute Arbeit!

Und das mit dem globalen Hardlimit finde ich ne gute Idee.

Ich schaue immer, daß ich um die 4000 liege.

Wo seid ihr so?

also, welche configfiles muss ich beim wechsel umbenennen, und welchen namen sollen sie bekommen?

Hi

@Tobsen23: Wenn du von einem älteren eWombat auf die 0.064c wechseln willst, musst du nur die neue ewombat.exe in das alte Verzeichniss kopieren, fertig.
Wenn du von einen anderen Mod umsteigst, geht das genauso, der eWombat kratzt sich alles was er braucht zusammen und konvertiert es. Die orginal Dateien die der eWombat ändert findet man danach in ../config/old/

Ansonsten steht alles schön im install_deutsch.rtf, die gilt für alle eWombats ab 0.063

cu
Darkwolf

Jetzt versteh ich auch das rumgeswappe zwischen den Files. Ok hab nix gesagt.

Ich connecte manuell. Bisher konnte ich es nur so beobachten: eWombat gestartet, zu Server connectet, nach einiger Zeit Verbindung zu Server verloren, Statistik bleibt stehen, d.h. Up/Downloads gehen ja normal weiter aber die Werte in der Statistik ändern sich dementsprechend nicht, erst beim wiederverbinden zu einem Server aktualisiert die Statistik.

Gruß Maddis

Also in den 64er Versionen ist bei mir der Wurm drin. Ich hab gerade folgendes getan: Hardlimit auf 350 gesetzt und bei einer Datei deren Hardlimit auf 600 war "Automatically Swap all A4AF to this file" angeklickt. Ein paar Sekunden später schnappt sich der Wombat 99% der CPU Ressourcen. Ich hab bestimmt 10 Minuten gebraucht bis der Task-Manager auf war um den Prozess zu killen :roll:.
An meinem Windows kann es nicht liegen, das hab ich erst seit 2 Tagen installiert, weil mir vor ein paar Tagen ne Festplatte kaputtgegangen ist :oops:.
Falls es was hilft: Intel Celeron 1200 auf Abit BX133 Board, 512MB RAM, Win2k3.

Wie gesagt bis jetzt lief noch keine 64er Version bei mir längere Zeit durch. Wenn der Wombat mal läuft isser Super, aber so wie der im Moment zicken macht teste ich den erst wieder wenn darkwolf sagt er hat den Fehler gefunden :cry:. Sonst läuft jede Software auf meinem System stabil. Hier noch meine Einstellungen falls es weiterhilft:

Download: 96 - 86
Upload: 16 - 10
Max. Connections: 400
Max Sources Per File: 350
Max. new connections / 5 secs.: 20
Clientport - TCP:4013 UDP:4416
Server UDP-Port: 4665
eWombat---------
S.U.I. (Secure User Identification)
S.N.A.F.U. V2 (Advanced Leecher Detection)+A.C.T. V2 (Anti Credit Theft)
Spread connections
Auto Cleanup Sources, Drop Full Queue Sources, Drop No Needed Sources, Drop Unknown Sources
Manually Drop Sources with QR > 2000
Reload if sources <= (1..200):200 Save max. Sources (1..50):50
Fake Block Check (A.Z.F. v2) ~CD-Images ~Video
A.U.B.W.C.: min: 3
Slots for Release-files: 1
One Queue per File
Push small files
Push rare files
Transfer full chunks v2
ConnectionTimeout: 60 sec.
ServerReaskTime: 800 sec.
UDPServersReaskTime: 1300 sec.
ServerKeepAliveTimeout: 10 min.
Signal to the client the end of the upload session
---------
File Buffer Size (480000)
Queue Size (5000)
Use smart LowID check on connect
Use Credit System (Reward Uploaders)
Filter server and client LAN IPs
Safe .met/.dat file writing Always

eWombat Version 0.064c [Build: 0.064.C]
UL:DL Ratio: 1 : 1.08 (1 : 1.08)
Downloaded: 761.21 MB (761.21 MB)
Uploaded: 704.01 MB (704.01 MB)
Average DL-Rate: 13.78Kbs (max: 72.81Kbs) UL-Rate 12.75Kbs (max: 26.17Kbs)
aktive Verbindungen (geschätzt): 85 - Zu viele Verbindungen: 0
UL-Sessions successful: 190 avg. time: 16:51 mins | failed: 42 (can't connect: 31 | critical error: 0)
DL-Sessions successful: 214 avg. time: 22:15 mins | failed: 99 (can't connect: 0 )
Uploads Waiting: 1840 | Found Sources: 906

S.U.I. successful: 5217 - failed: 111
Detected 233 leechers, 42 credit thieveries
Corrupt blocks: 0 detected
Programm-Laufzeit: 15:42 h
Winsock: WinSock 2.0 Running
Virtual: 78.14 mb free: 1969.74 mb | Athlon/Duron optimization active

Also ich hab mit der Version auch ein kleines Prob (obwohl er ansonsten super läuft):

Immer wenn er länger läuft (über Nacht), ist er am nächsten Morgen tot (reagiert also nicht mehr und wenn man auf schließen geht, dann komt nur die Meldung, dass dieses Programm nichtmehr reagiert und man es sofort schließen soll). Ok kann man sagen, kann ja mal passieren. Aber was mich dabei doch sehr wundert: Die CPU-Temperatur liegt dann immer auf genau 58° (bei PVI 2,8GH --> Normaltemp: ~35-40°)! Wenn der wombat dann beendet wird, geht die Temperatur innerhalb von weniger als 1 Min wieder runter auf Normalwerte. Beim Neustart des wombats bleibt die Temperatur auch unten...bis er wieder abstürtzt.

Dem Log konnte ich folgendes entnehmen:

28.10.2003 03:45:32: Unerwarteter Dateifehler beim Schreiben [Dateiname]: Unbekannt
Das sind die letzten Worte vor seinem Ableben gewesen.

Hat da vielleicht einer ne Erklärung (v.a. für das mit der CPU-Temperatur)??

Große Probleme
 

Gestern Abend startette ich mit voller Erwartung die 0.64c.

Alles schien prima zu klappen genau wie ich es bisher vom eWombat gewohnt gewesen bin.

Nach seinem ersten Start hatte ich riesige Probleme mit den fehlschlagenden Down- und Uploads obwohl ich die gleichen Einstellungen verwendet habe wie bei der 0.64b. Beiden Werte betrugen ca. 50% was einfach viel zu viel gewesen ist. Die Laufzeit bis zum manuellen Abbruch und einem erneuten Start betrug ca. 8 Stunden.

Heute morgen stellte ich dann fest das er schon seit Stunden erfolglos versuchte zu einem anderen Server zu verbinden nachdem er den vorherigen verloren hatte. Die fehlgeschlagenen Uploads waren 3 mal mehr als die erfolgreichen und bei den Downloads waren es 50% fehlgeschlagene. Keine Ahnung was da passiert ist und es ist auch das erste größere Problem wo ich mit dem eWombat hatte.

Jetzt läuft bei mir wieder die 0.64b Version.

Hi,

@Ov3rKill:
sieht nach einem Dateifehler aus, lass mal Scandisk drüberlaufen...

cu
Darkwolf

Jepp, das hab ich auch gedacht und alle gecheckt, aber ohne Erfolg, ist mir nämlich heute über den Tag wieder abgestürtzt und "heiß gelaufen". Was mich dann aber noch wundert ist, dass die Temperatur innerhalb von einer halben Minute (!!) von 58° auf 37° runter geht. Ich bezweifle aber, dass dies wirklich so schnell möglich ist. Kann es also sein, dass emule in Verbindung mit AsusProbe (2.21.05) irgendwelche Fehlanzeigen verursacht?

Ich werde jetzt erstmal wieder auf einen anderen Mod umspringen, mich würde aber trotzdem eine Ursache hinter dem ganzen brennend interessieren...

Hi,

Ov3rKill: Also AsusProb verwende ich auch, auf einen A7N8X...
Ganz vorsichtig gesagt, bei mir stimmen die Temp-Werte überhaupt nicht (mit und ohne eWombat)...Wenn deine CPU 'heiss' läuft, bedeutet das, das etwas ohne unterbrechung CPU-Zeit frisst, was wieder auf den Schreib/Lesefehler zurückzuführen ist...

Diese Fehlermeldung ist aber trotzdem ein Schreib/Lesefehler einer Datei
Die gleiche Fehlermeldung kam aber bei einem der Betatester:
Hast du vieleicht irgendwelche Dateien von anderen P2P-Clients freigegeben ?

cu
Darkwolf

Nein.


Wenn da aber schreib/lesefehler passieren, ist doch (zumindest nicht nur) die CPU betroffen, sondern Primär die Festplatte. Ich meine, das würde man dann ja hören (tu ich aber nicht ;))

Ich denke mal du solltest deine Kühlung insgesamt mal überdenkenOv3rKiLL, das hört sich verdächtig nach Hitzestau an.
Die Kabel etwas anders verlegt den Lüfter der CPU gereinigt und vielleicht eine aktive Kühlung für die Festplatte.

mfg
Odinasgardson

also meine leerlauf-cpu-temperatur liegt auch zwischen 30°C und 35°C. ich hab aber nachts immer SETI zu laufen, und da steigt die CPU-temperatur mal gerne auf 70°C, hab aber noch nie irgendwas nachteiliges bemerkt, alles läuft einwandfrei, der muli läd wie noch nie, keine blue screens, keine abstürze, nichts...

;)

2x Festplatten aktiv gekühlt, 3 Gehäuselüfter, Kabel siehst du fast keine in meinem Gehäuse...

Wenn das echt ein generelles Hitzeproblem sein sollte, dann müsste das doch auch tagsüber auftreten? Und das tut es nicht (läuft 24/7), obwohl einige Anwendungen laufen, die den PC erheblich mehr beanspruchen als emule.
Auch geht die Temperatur ja sauschnell runter(und dafür muss ich auch nicht das Gehäuse öffnen oder so), sobald ich den wombat beende. Ne halbe Minute is echt nicht gelogen.

Das einzige, wie ich mir das erklären könnte: Der wombat ***** irgendwann in der Nacht ab (weshalb auch immer), durch irgendwas wird die CPU-Last dann auf 100% gebracht und das für ein paar Std nonstop.

Denn wenn der Wombat mal nicht abstürtzt, dann ist die Temp auch normal bei ca 35°...

Wow, dann hast ja nen ganz schönen Krachmacher.
Das aktivkühlen der Festplatten habe ich mir abgewöhnt, weil die Lüfter, selbst die teuren, irgendwann zu laut wurden. Mir hat geholfen, die Dinger auf die 5V Leitung anzuschließen. Aber vorher testen, ob sie auch anlaufen, dann 7V nehmen (12-5=7V)

Nimm doch mal den Motherboard Monitor 5. Der liefert bei mir die gleichen Ergebnisse wie PCProbe von Asus und ist unabhängig vom Hersteller, vielleicht reagiert der anders. Sonst gibts noch Speedfan, das überwacht Lüfter und Temp.

Vielleicht bekommt ja auch nur PCProbe nur zu wenig Rechenzeit und es schleicht sich dann ein Fehler ein und deine Temperatur ist gar nicht so hoch. Du sagst, die Temperatur geht schon in einer halnben Minute runter. Da würde ich das sogar vermuten. Schließlich aktualisieren die ja nur alle paar Sekunden und werden sicher zwischen den gemessenen Werten interpolieren.

Probier mal eines von den anderen Programmen und post dann wieder.

So, hab jetzt mal nen anderen Mod getestet. Da is alles normal, Temperatur konsant 37°...

Dass die Temperatur vorher wirklich so hoch war, merkt man daran, wie heiß es im Zimmer ist (ist n recht kleines Zimmer): Wenn der auf 58° war, dann war es so, als ob man ne Sauna betritt :D



Also lags wirklich daran, dass der Wombat einfach abge***** ist...Darkwolf unternimm was, jetzt muss ich mit einem UL:DL von 1.90:1 rumgurken! :?

Bilde ich mir das nur ein, oder hat die Quellenfindung des Wombat stark nachgelassen?

Hi,

also mit dem eWombat ist es genauso wie mit anderen Mods, auf manchen Systemen läuft er einfach nicht.

Wg. Quellenfindung: Der 0.064C findet genauso viele Quellen wie die A/B, der einzige Unterschied ist: Quellen die nicht erreichbar sind, werden schneller ausgesiebt.

Wg. Serverconnect: Das einzige was sich da geändert hat ist, das der eWombat bei dem Versuch eine Serververbindung aufzubauen, ein bisschen Bandbreite freihält um keine Antwort von einem Server zu verpassen.

Wg. Dateifehlern/Plattenfehler: Wenn man meint, der eWombat sei abgestürzt, weil durch einen kompletten rehash aller Dateien eine Zeitlang das System ausgelastet ist und der eWombat im Taskmanager anzeigt 'keine Rückmeldung' und den eWombat dann während dem Hashvorgang über 'Task/Prozess beenden' abschiesst, braucht man sich nicht wundern, wenn es eine Datei zerschiesst. Der Hashvorgang ist eine sehr Zeit-kritische Funktion. Wenn man viele Dateien im Download und Shared hat, braucht das halt seine Zeit.

Wegen Verbindungen und Verbindungen pro 5 Sekunden: Der eWombat handelt die abarbeitung der Sockets anders als der org. eMule, ca. 5 mal öffters. Dadurch produziert der eWombat mehr Overhead.
- Max. Verbindungen 200 - mit 20 pro 5 Sekunden ist auf sämtlichen Systemen mit DSL ein sicherer Wert, bei dem es keine Probleme mit Serververbindungen u.ä. gibt und die Quellen werden schnell abgearbeitet
- Man sollte immer darauf achten beim Uploadlimit min. 4Kbs Bandbreite freizuhalten
- Auch wenn er ohne Probleme wesentlich mehr Quellen abarbeiten kann: mit ca. 4000 gefundenen Quellen ist man, was den Overhead und die Abfragegeschwindigkeit anbelangt auf der Sicheren Seite, also nicht zuviele Dateien gleichzeitig im Download aktiv halten.

Während des Betatests (von Win98 bis XP war alles vertretten) gab es nur 1 einzigen echten Bug mit Absturz und der passierte wenn unter XP mit offenem eWombat Fenster die Skin gewechselt wird, und der ist behoben...

Also, so hart es klingt: Solche Geschichten wie Dateifehler, zu heisse CPU, Absturz bei automatischen A4AF sind persönliches Pech. Der eWombat hat seit der 0.063 bewiesen das er auf einem sauberen Windows ohne grössere Probleme läuft.
Bugs gibt es leider in jeder Anwendung auch beim eWombat, diese äussern sich aber dadurch das sie meistens mehrere Leute heimsuchen und zweitens nachvollziebar sind.
Kleiner Gag am Rande: Es gibt eine eWombat-User der benützt den eWombat als PC Test-Suit für die Hardware eines grossen deutschen Herstellers und der eWombat wurde als Test-Suit von diesem Hersteller akzeptiert, was ja kaum möglich ist, wenn er 'einfach so ab*****'...

Nichts für ungut

cu
Darkwolf

Hallo @All...
Ich schalte mich hier auch mal ein.
Ist ja eine Interessante Diskussion,die ihr hier führt,
allerdings muss ich zu euren Probs mal sagen,das ihr erst dann am eWombat suchen solltet,wenn Ihr euch hundertprozentig sicher seid,das ihr ein absolut sauberes OS auf eurem Rechner habt.Denn wenn das OS hundertprozentig sauber ist,rennt der eWombat ohne Gnade.
Sollten allerdings ungereimtheiten in eurem OS sein,dann können eben genau solche Abstürze passieren,wie ihr sie hier beschreibt.
darkwolf hat den Code des eWombats ziemlich optimiert,so das der eWombat auch mit sehr niedrigen Einstellungen grandios läuft.

Das hier solltet ihr euch mal zu Herzen nehmen,denn damit rennt der eWombat extrem gut.
Ich persönlich habe mit noch keinem anderen Mod so gute Downloadwerte erzielt,wie mit dem eWombat.

Greets
fightertyp

darkwolf, kann deine worte nur bestätigen.

um nochmal auf das rehashen zurückzukommen. ich weiss ja nicht, wieviel aufwand es macht, aber der morph-kad hat das rehash prob mit der meldung im taskamanger = "keine rückmeldung", nicht, aber vielleicht wäre es möglich, das du dir mal den source vom morph anguckst. der morph-kad ist der einzige mod, bei dem ein weiterarbeiten beim rehashen möglich ist. alle anderen mods blockieren dabei den rechner. jedenfalls bei mir.

ps. gibt es deinen 64c als ed2k-link. im http-download ist der dl ok, aber beim entpacken immer crc-fehler. die vorgänger habe ich deshalb immer über den esel downgeloadet und an den start gebracht.

@ Gucky,

du musst dir eine neue Version von WinRAR oder was du benutzt besorgen. Mit WinRAR 3.20 gehts ohne Probleme.

Gruß Maddis

Hi

@Gucky, das mit dem rehash ist ansich kein Problem, ich habe bloss nie damit gerechnet (Slugfiller wahrscheinlich auch nicht) das einige Leute soviele Dateien im Share und Download haben und an Sommer/Winterzeit umstellung habe ich echt nicht gedacht.
Das rehashen kommt ja auch nur vor wenn:
- eine Datei ausserhalb des eWombats geändert wurde (da reicht es das Datei-Datum zu ändern)
- neue Dateien zum Shared hinzugefügt werden
- die known.met defekt oder gelöscht ist.
- der Temp und/oder incoming Folder woanders hinkopiert wurde


Kleiner Nachtrag zu meinem vorherigen Post: Die eMule's neigen im allgemeinen dazu, die Platten auf denen sich der Temp-Folder befindet ziemlich zu fragmentieren, was einem rehash auch nicht gerade beschleunigt. Auch sollte man darauf achten (falls man mehrere Platten hat) das das eMule Temp Verzeichniss auf einer anderen Platte (nicht nur Partition) ist, als das Windows-Temp, Auslagerungsdatei usw. Konkurierende Plattenzugriffe bremsen den rehash/hash und des eMule im allgemeinen aus...
Auch sollte man bei evtl. Problemen überprüfen, das keine Datei im Share schreibgeschützt ist oder von einer anderen Anwendung gespeert ist...

Ich arbeite für die 0.064D an einem 'SaferHash', damit dauert das rehashen einzelner Dateien etwas länger (macht sich aber bloss bei den Shared-Files bemerkbar, wenn man z.b. einen neuen Ordner hinzufügt oder die known.met löscht). Solange aber nicht gerade ein Scandisk läuft oder ein anderes Programm massiv auf die Platte zugreift, gibt es das 'keine Rückmeldung' nicht...ausser irgendjemand kommt auf die Idee eine Zip-Disk oder CD-RW als Temp herzunehmen oder von einer CD (was katastrophal endet) zu sharen ;)
Dieser 'SaferHash' wird vor einem hash auch die Datei auf Probleme (Schreibschutz, gesperrt o.ä) überprüfen, und evtl. einen freundlichen Hinweis geben und diese Datei dann heftigst ignorieren...

Von mir gibt es jedenfalls keinen ED2K-Link der 0.064c aber mach mal eine Suche, hat bestimmt irgendjemand.
Das eWombat-Archiv auf meiner Webseite habe ich mit WinRar3.10 gepackt, versuch mal den eWombat von Odinasgardson's Webseite zu laden oder nimm 'Extras/Links/eWombat Support Forum', die haben immer die aktuellsten Versionen zum Download...

cu
Darkwolf

darkwolf, erstmal thx für die schnelle antwort.
leider bin ich ein vielklickerer. selbst mit coreldraw bringe ich meine resourcen in w2k ins schleudern. inzwischen habe ich es abgewöhnt, allzuviel im esel zu klickern. das mag er nicht und dann muss er halt eben hashen. und das nervt.
bei meinen vorhergehenden probs war es die vielklickerei. ansonsten sind temp- , os- , programme- und daten partitionen, emule = eigene hdd, alles fein säuberlich getrennt. auch alle atribute der files sind nicht gesetzt.
das es keinen ed2k-link gibt, ok. dann halt eben ein anderer weg. dachte aber ed2k zu fragen, wäre einfacher.

muss deinen mod haben ! ich sonst > :evil:

Tja, einige Mods laufen halt nicht gut, echt schade :(

Also am OS kann es nicht liegen, das habe ich letztes Wochenende erst komplett neu aufgesetzt.
Ebenso kann es kein Hash-Fehler gewesen sein, denn ich hatte zu diesem Zeitpunkt nur sehr wenig im share (und dann kann das mit dem Hashen schon lange dauern, aber bestimmt nicht 5 Std+).

auch nach 2 t und 21 std und 2 zt läuft der mod sehr stabil ohne ausreisser ! habe jetzt allerdings nach 2t und 18 std mal die ratschläge von darkwolf via pm befolgt und der download geht konstant höher !

Here are the results from the wombat jury:

eWombat Version 0.064c [Build: 0.064.C]
UL:DL Ratio: 1 : 2.38 (1 : 1.71)
Downloaded: 6.60 GB (29.15 GB)
Uploaded: 2.77 GB (17.06 GB)
Average DL-Rate: 27.65Kbs (max: 59.25Kbs) UL-Rate 11.62Kbs (max: 12.35Kbs)
aktive Verbindungen (geschätzt): 170 - Zu viele Verbindungen: 1
UL-Sessions successful: 660 avg. time: 25:08 mins | failed: 347 (can't connect: 106 | critical error: 167)
DL-Sessions successful: 2654 avg. time: 17:25 mins | failed: 389 (can't connect: 0 )
Uploads Waiting: 5034 | Found Sources: 3886

S.U.I. successful: 211066 - failed: 1464
Detected 3939 leechers, 193 credit thieveries
Corrupt blocks: 0 detected
Programm-Laufzeit: 2 T 21 h
Winsock: WinSock 2.0 Running
Virtual: 310.55 mb free: 1737.32 mb | Athlon/Duron optimization active

bei mir läuft der eWombat in der neuesten version endlich stabil =). Komischer weise fand ich die dl raten beim morphkad besser. Naja dafür ist der up besser beim wombat

@Pulpman!

Stell mal die max Verbindungen auf: 200
und die max neue Verb. pro 5 sec auf: 20
Die Quellensuche dauert zwar ein wenig länger beim "Start" aber das Endresultat ist ja entscheidend!
Der eWombat brauch nicht so hohe max Verbindungen!

so habe mal folgende these !

habe 41 files im download

gefunden 4000 quellen /hardlimit 200/ max neue verbind auf 5 sec = 20

download nicht viel anders wie bei hard limit 400 und 5 sec = 50

allerdings hat er bei jedem file 2-3 stellige werte in den klammern wenn ich ein limit von 200 setze. bei 400 sind alle quellen abgefragt.
allerdings setzt der download sich bei beiden zwischen 15- und 37 kb/s down fest.
liegt es nun an der viel zu hohen anzahl an files, daß er die quellen nicht komplett abfragt ? die max sourcen per file (700) gibt er mir auch bei den nicht an wo quellen bis zu 2000 und höer sein müssen.

was meint ihr wer ein neuer versuch mit 20 files im down und werte 800/200/20 sinnvoller ? kann es sein das er mir viele down abricht, weil er die gar nicht verarbeiten kann oder erst verspätet abfragt ?

@Tarod´s Son...
Ich würde an Deiner Stelle mal die 41 Files im Download lassen,davon aber so ca. 15 Files einfach pausieren.
Nimm mal folgendes als Richtlinie:
Wenn Du folgende Einstellungen im eWombat verwendest (Max. Verbindungen: 400,max. neue Verbindng. pro 5 Sek.: 35)dann ist das bei einer normalen eMule Version zu Vergleichen mit max. Verb. 800 und max. pro 5 von 55,da der eWombat eigentlich ziemlich aggressiv mit den Sockets umgeht.
Ich habe z.B im Moment 19 Files im Download (davon 7 sehr selten) und fahre den eWombat mit HL: 175,Max. Verb. auf 250 und Max. Pro 5 auf 20.
Mit diesen Einstellungen habe ich einen Down-Schnitt von 50-60KB,was bei der Anzahl von Files ziemlich beachtlich ist.
Geh einfach mal andersrum an die Sache heran als bei anderen eMule Mods.Teste die Einstellungen mal von unten nach oben durch,nicht von oben nach unten... ;)

Greets
fightertyp

@fightertyp

danke dir, aber das in etwa das was ich vermutet habe ! ist schon logo das ich die anderen 21 pausiert lasse. habe jetzt mal 800/300/30 laufen. werde mal testweise morgen berichten, es sei denn jemand hat noch vorschläge.

WICHTIG: es geht mir nicht um einen 50 oder 60 download, sondern einfach nur um möglichkeiten und erfahrungen, von mir aus kann es auch ein 12 down sein, wichtig ist nur das ich den wombat so optimal wie für mich möglich gestalte. Denn warum soll ich was verschenken ?

Genau darum mein Tipp mit den niedrigen Einstellungen @Tarod´s Son...;)
Zu verschenken hat man nichts.
Teste es einfach mal von unten nach oben.Das Ergebnis hat schon einige eWombat User ziemlich zum staunen gebracht (im positiven Sinn). ;)

Greets
fightertyp

@Ov3rKiLL,

deine hohen Temperaturen haben nichts mit den technischen Bedingungen in deinem PC (Kühler/Lüfter) zu tun. Dieses Problem hatte ich auch schon, nämlich genau dann, wenn sich ein leistungsintensives Programm wie der Wombat aufhängt, bzw. sich der Prozess "festfährt". Windows versucht dann krampfhaft, den Prozess zu beenden, was die Systemlast noch zustäzlich in die Höhe treibt. Dieser ganze Vorgang ist sehr CPU-lastig, was wiederum die hohen CPU-Temperaturen verursacht.

Beendest du diesen Vorgang/Prozess, erlöst du den PC sozusagen von den "Qualen" und die Temperatur sinkt innerhalb kürzester Zeit. Kann dir aber auch mit jedem Programm passieren. Das besagte Anwendung in dieser nicht so arbeitet, wie sie soll, ist natürlich normal.

@Tarod`s Sun dein Hartlimit auf 3-400, verbindungen=200, 5Sek.=50
Bei mir läuft diese Einstellung sehr gut, habe aber auch nen doppelt so hohen UL zur verfügung.
Als allerletztes kommt es immernoch darauf an, wieviele User zur selben Zeit dir einen UL geben.

EDIT
Desweiteren kannst du ja ausgewählte Dateien einzel einstellen, um an 1000 oder mehr Quellen zu kommen.
/EDIT

@ darkwolf,
so ein ärger. dein mod mag mich und/oder meinen rechner nicht.
habe den morph wegen zu hoher cpu-last beendet und mit viel tricks deinen mod mir besorgt.
wat macht dein schnuckelmäuschen - natürlich über 1.5 std. rehashen. obwohl der andere mod ordentlich beendet wurde. die hdd-led ging nicht mehr aus, obwohl für alle files schon quellen gefunden worden und blau hinterlegt waren. da timmt wat nisch.
die lange rehash zeit kann, glaube ich, nicht an meiner hdd liegen (fragmentierung). habe den magic-elseve gestartet. der war nach ~ 20 min. mit dem rehashen fertig.

@darkwolf,

danke für diese Info! :) Ich schätze, mit dieser Erklärung der Arbeitsweise sollten sich einige Fragen bezüglich der Einstellungen erledigen. Da der PC bis eben ausgeschaltet war, habe ich diese Einstellungen mit dem Womabt-Neutstart gleich mal ausprobiert und bin auf das Ergebnis gespannt.

Ich habe nur gesehen, dass der QR-Wert standardmäßig auf "2000" steht (hatte vorher alles vom 0.063/0.064a übernommen und dort waren es 1000). Ist das für die o.g. "relativ niedrigen" Einstellungen okay oder doch wieder 1000? Ist dieser Wert eh sooo entscheidend?

Hi,

@Gucky: Da rehash Problem auf manchen Systemen ist mit der 0.64D behoben (Safer Rehash). Anscheinend tendiert XP tatsächlich dazu ab einer bestimmten Anzahl von gleichzeitigen Threads/Offenen Dateien zu blockieren, bzw. Deadlocks aufzubauen. Wie gesagt, das betrifft aber alle Mods die den Slugfiller SafeHash benutzen. Es könnte auch ein Problem mit/durch das P4 Hyperthreading sein.
Der 'SaferHash' geht einfach provilaktisch davon aus, das er auf einem System mit solchen Problemen läuft und startet immer nur einen Thread wenn der vorherige fertig ist (das kann man aber verändern) und Dateien im Download sind solange gestoppt bis ein rehash fertig ist, damit ja kein neuer Chunk-Hash dazwischenkommt ;).

Wenn du den rehash mit einem anderen Mod gemacht hast, sollte der eWombat (beim gleichen Temp-Verzeichniss) keinen rehash mehr durchführen, da ja die TimeStamps wieder stimmen.

@kw. Wenn du den QR Wert beim Cleanup/Autocleanup meinst, der ist für die Verbindungseinstellungen irrelevant, das ist nur die Einstellungen ab welcher Wartelistenposition Quellen entfernt werden, den solltest du aber nicht zu niedrig einstellen und bei seltenen Dateien ganz deaktivieren

cu
Darkwolf

Der Sinn und Zweck ist mir schon klar :)...mir ging es nur um die Höhe des Limits. Ich probier´s dann mal mit den 2000.

Ansonsten war der "Anlauf" seit meinem Posting gar nicht schlecht. Er kam auch mit diesen Einstellungen auf ein DL-Limit von 40kb (max.) und schnurrt im Schnitt munter mit ~25kb vor sich hin. Hut ab, hätte ich vorher echt nicht gedacht.

Wäre es da nicht eine gute Funktion, die regelt, ab wie vielen vorhandenen Quellen das Droppen der Quellen aktiviert.

z.B.: max Quellen 300 --> erst ab 20% (also in diesem Bsp 60) der max zulässigen Quellen werden diese nach den angegebenen Kriterien gedroppt.

Dann würde man sich die Einzelkonfiguration aller einzelnen Dateien sparen.


Nur mal son Vorschlag ;)