So jetzt meine Werte nach 2 Tagen durchlaufen mit 2x 24 std trennung

Ratio: 1 : 2,44 (1 : 3,85)

aktive Verbindungen (geschätzt): 170 - Zu viele Verbindungen: 0
UL-Sessions successful: 639 - failed: 223 - Avg. time: 10:05 mins
DL-Sessions successful: 1395 - failed: 561 - Avg. time: 21:38 mins
Gefundene Quellen: 2748

SUI successful: 35339 - failed: 190 <--- ich glaube SUI hat sich schon durchgesetzt :)

Detected 930 leechers, 57 credit thieveries, 7 friendshare-mod leechers <-- Hätte nicht gedacht das es soo krazz ist.

Detected 553 suspicious compressed blocks
Programm-Laufzeit: 2 T 2 h

cobrajet,

mag sein, das 9000 Quellen viel sind, aber ich hab schon schlechtere statistiken nach 14h gesehen ;-) Außerdem finde ich es eher beeintruckend, das eWombat das auf seinem Rechner möglich macht. Ich hatte schon Mods, da war ich bei 4000 Quellen bei 100% CPU-Last.

hahaha... ich hab auch was zu bieten was sonst keiner hat :-D

Ratio: 13,35 : 1 (1,74 : 1)
Heruntergeladen (Session (Total)): 250,07 MB (115,93 GB)
Hochgeladen (Session (Total)): 3,26 GB (201,81 GB)
Average(5-min) DL-Rate: 1,96Kbs (3,40Kbs) UL-Rate 26,23Kbs (28,81Kbs)
p»
aktive Verbindungen (geschätzt): 13 - Zu viele Verbindungen: 0
UL-Sessions successful: 1734 - failed: 1007 - Avg. time: 6:03 mins
DL-Sessions successful: 75 - failed: 17 - Avg. time: 20:58 mins
Wartende Uploads: 357
Gefundene Quellen: 13
SUI successful: 1336 - failed: 1
Detected 10 leechers, 6 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 1 T 12 h
Mem used: 111,45 mb free: 1936,43 mb




13 quellen :-D haha
für 8 files wohlgemerkt, davon 4 in release, 2 superkleine mit je 1 quelle, 1 file auf den ich schon hundert jahre warte und 1 file der quasi null bekanntheit hat vom inhalt her.... alles im lot... ich würd sagen für DIESE files sind 13 quellen viel :-D

MxM., da biste wohl nen UL-Leecher. :D

Nur deinen aktuellen eWombat. Use Anti Zero Part File Handling zu den Zeitpunkten aktiv. Aber zwischendurch auch mal ausgeschaltet gehabt. Aber ich meine das is schon 3 Tage her das die Fkt. kurzzeitig aus war. Zwischendurch war mein Rechner aber auch mal aus...

Schon länger nicht mehr. Keinen mehr bekommen bzw. aktiv was getestet. Mir fehlt die Zeit. Bin froh wenn überhaupt immo was läuft...

Hi

@Maddis, deaktiviere am besten das 'Anti Zero Part File Handling', die Funktion hat mehr oder weniger nur noch historische bedeutung und kann vorallen bei *.avi, *.iso und *.bin Dateien fehler verursachen...

@Odinasgardson, für den 0.064er überarbeite ich gerade das a4af handling, beim alten habe ich festgestellt das doch einiges an gute Quellen geswappt wird, TCPIP habe ich überarbeitet, da fehlen aber noch die Einstellungen. (Mit niedrigen Timeout einstellungen lassen sich die Quellen extrem schnell abfragen :wink: )Was noch fehlt ist der update der IPFilter, die Fakeliste für die Suche und ein paar kleine Spielereien. Momentan bin ich aber unheimlich im 'Arbeitsstress', wird also noch ein paar Tage dauern.

Auch wenns OT ist um alle zu beruhigen habe ich den Grund für ca. 60% der failed UL-Sessions gefunden: Diese Clients wollen zu grosse Datei-Blöcke haben, deswegen war in meinen Protokoll immer 'no block requested'. Das liegt an einen Bug in den eDonkeyHybriden und auch einige harmlose(selten dämliche)Leecher sind davon betroffen.

cu
darkwolf

@ darkwolf, will ja nicht drängeln. :D

Ok danke. Werde ich mal ausprobieren. Aber warum nur noch "historische bedeutung"? Gibbet ein neues System dafür?

Lass dir nur Zeit! Wenn die 63er jetzt wieder stabil läuft .... :D

@ darkwolf, Danke für deine Antwort. Wegen meiner mach es lieber in Ruhe und vernünftig als das du nur um die Leute zu befriediegen schnell mal einen Mod auf den Markt wirfst.
Ich habe im Moment sowieso noch genug zu testen. :lol:

mfg
Odinasgardson

@darkwolf,

Oh je , ich habe zwischendurch andere Mods zu testzwecken laufen gehabt und nun will der WOMBAT gar nicht mehr stabil laufen :-( bin ganz gekinickt ... habe nun alles neu installt und bete das es nun wieder richtig funtzt .. werde nun nur noch auf 2. Pc meiner Tochter testen ;-)

Normalerweise habe ich eigentlich nur ca.8000 Quellen, das wird sich aber wieder ändern. CPU ist bis zu 90% ausgelastet.
In letzter Zeit hatte ich immer Probleme, weil mein PC abstürzte, nun ist eine FP kaput gegangen, klappert nur noch und wird nicht mehr richtig im Bios erkannt.
Hab dann auf der 2.FP WinXP neu installiert und siehe da bisher kein absturz.
Und nutze cFos, was ich wegen der Abstürze auch nicht nutzen konnte.

Jetzt DL ich gerade 24 Dateien, wo 4 über 1000 Quellen haben.

Im schnitt würde ich wohl sagen, dass es dann wohl zwischen 400 und 500 sind.
Ich habe die wichtigsten einstellungen voll auf 999 sek. gestellt, wie Drop no needed source, unbekannte Source.
Ein dropping von den anderen sachen halte ich nicht so viel, weil man ja sowieso 24h rund um die Uhr den PC laufen hat, dann kommt man sicher irgentwann mal dran und wenn nicht, dann gibts ja noch genug andere Leute, die es einem dann auch geben.
Das ist doch das geniale am eWombat, dass man auch richtig gute Einstellungen einstellen kann. Nicht so, wie in den anderen eMules, wo man nicht mehr als 3-4.000 Quellen Max. haben konnte. Da war die CPU zu 100% ausgelastet.

Zum Abschluss wollte ich meine Statistik neu posten, aber nachdem ich vor 5,5h cFos aktuallisiert und einige sachen gebrannt habe läuft der eWombat also nicht so lange, deshalb nur mal ein kleiner Ausschnitt.

Ratio: 1,77 : 1 (1 : 2,14)
aktive Verbindungen (geschätzt): 459 - Zu viele Verbindungen: 0
Gefundene Quellen: 9774
SUI Ok: 4961 Invalid: 28
Programm-Laufzeit: 5:20 h

ich würd gern mal wissen wieviel dateien du downlädst.

und auch deine Leitung, dein OS und all den krams wüßt ich mal gern,
bist du direkt an nem backbone dran ?


bei mir ist hier mit 150 aktiven leitungen tatsächlich schluß, und ich kann mich prinzipiell nicht beklagen... ich kann mich auch nicht erinnern, jemals auf eine solche zahl quellen gekommen zu sein... und ich behaupte, dass mein rechnersystem deins um längen schlägt....

sollte das ganze also wohl an der leitung liegen... denn nur mit einer richtig hohen MTU wirst du wohl an soviel source exchange kommen können... allein die pakete für 500 aktive verbindungen lassen mindestens auf 2,3 MBit schliessen... falls das überhaupt reicht.


edit: ich kann schon lesen, dass da TDSL 1500 dransteht wollte ich nur sagen...aber mein Q-DSL sollte bei dir eigentlich mithalten... und in den pingzeiten kann ich mich wahrlich nicht beschweren...aber das was bei dir in den daten da abgeht lässt bei DSL 1500 nur darauf schliessen, dass der nächste knotenpunkt unter deinem haus liegt

Meinst Du das ?
Failed upload session, eDonkeyHybrid v49.4
http://www.emule-project.net/board/i...howtopic=24854

Ist aber denk ich nicht der Grund für über 60%. Benutze grad den neuen Maella Mod der dies bereits gepached hat. Man sieht zwar nun, daß es wirklich klappt, den Hybriden upload zu geben, aber wirklich merklich verbesser hat sich die Anzahl fehlgeschlagener Uploadsessions nicht. Übrigens Maella benutzt auch nen Timeout von 60 Sekunden. Also am Timeout sollte es auch nicht liegen.

MxM.,
kannst DU mir mal erklären was MTU mit source-exchange zu tun hat ? Desweiteren 500 aktive Verbindungen mit 2,3 MBit ?
Du bringst da sachen in Zusammenhang die ich auf diese Weise nie in Zusammenhang bringen würde.

soweit mir bewußt ist wird bei einem source exchange die verbindung zwischen 2 rechnern hergestellt, die daten darüber austauschen wer welche source hat.

angenommen ich habe eine datei mit 100 quellen, so wird durch den source ex jede dieser quellen selbst nach quellen gefragt.

sprich, es werden zusätzlich zu allen bestehenden verbindungen weitere 100 hergestellt um diese daten auszutauschen...egal ob dies nun extra geschieht, oder während des vorgangs des downloads... es wird auf jeden fall ein mehr an dateien pro sekunde getauscht.

die mtu spielt maßgeblich die rolle wieviele ladevorgänge ich gleichzeitig haben kann.



durch das verändern meiner MTU verändert sich auch das verhalten meines mulis... und einen solch hohen wert habe ich mit noch keiner xDSL Leitung gesehen.... 500 aktive verbindungen... bei 8000 quellen...

leider kenn ich mich mit dem TDSL 1500 nicht aus, was für einstellungen insgesamt überhaupt typisch für dieses angebot sind... deswegen interessieren mich diverse werte... ich komm sonst nicht ganz mit, wie es zu solchen ergebnissen kommt

Quatsch! Sorry, aber da verstust Du Dich ein wenig.
Angenommen Du hast 100 Quellen. In regelmäßigen Zeitabständen wird eine dieser Quellen nach seinen Quellen abgefragt. Jetzt sendet Dir der andere seine Quellen. Vielleicht 80 Stück. Von den 80 STück kennst Du vielleicht 70. Mit diesen 70 passiert dann rein gar nichts. Die 10 Neuen werden von Dir abgefragt.

Zu MTU. Die emule Devs empfehlen die MTU nicht zu hoch zu setzen. Inwiefern die MTU den Mulie beeinflußt hab ich auch noch nicht so genau rausgefunden, als das ich eine definitive Aussage darüber treffen könnte.

Der Zusammenspiel von MTU und Source Exchange würde mich auch mal interessieren, gut das ich nicht der einzige bin, den das interessiert. Wenn es wieder mal zu sehr Offtopic wird, kann man das auch an anderer Stelle klären. Wenn hier wirklich konkrete Zusammenhänge sichtbar werden, wie die MTU den Emule beeinflußt, wäre das nicht schlecht.

Noch was zu Source Exchange und zu viele Verbindungen: Mal bitte nicht vergessen, das SE normalerweise über UDP läuft, der zweite Port in den Verbindungseinstellungen. UDP ist ein verbindungsloses Protokoll, also "Fire-And-Forget", die Daten werden einfach abgeschickt, ohne das der Empfang bestätigt wird. Da das normalerweise immer aktiviert ist, das UDP genutzt wird, hält sich die Anzahl der zusätzlichen Verbindungen für SE meiner Meinung nach in Grenzen, wenn es überhaupt in aktive Verbindungen reinzählt (streng genommen ist es keine Verbindung, UDP ist per Definition verbindungslos). Wer natürlich den UDP-Port nicht nutzen kann, hat natürlich durch SE mehr Verbindungen. Auf jeden Fall dürfte es bei UDP-Verbindungen (wenn sie denn als Verbindungen zählen) nicht lange bestehen, ein Timeout von 40 Sekunden oder so wird es nicht geben, da ja wie gesagt auf keine Antwort gewartet wird.

Und nicht vergessen, Overhead/Traffic wird durch SE so oder so generiert, egal ob TCP oder UDP.

ich greif nurmal vorweg:

dieses OT ist genauso wichtig wie das andere... und man kann nicht immer mittendrin woanders einen thread eröffnen. hier wurde eine frage aus dem sachverhalt heraus gefragt und somit wird sie in den sachverhalt hinein geantwortet.


xman

ob ich 80 kenne oder nicht, kann mein emule erst feststellen, wenn die daten zu mir übertragen sind.

zur mtu: meine liegt bei 1448 nach leitungsmessung von cfos

tatsächlich ist das 1492er mtu maximum m.E. wirklich nicht zu empfehlen, da dies für diverse verbindungsarten das hardwaretechnische maximum darstellt... ohne spielraum für fehler, leitungsschwierigkeiten und andere dinge.


über 25/5sec und 200 verbindungen komme ich übrigens prinzipiell nicht weg

unabhängig davon bekomme ich dennoch einen download von bis zu 160 und mein upload geht teilweise bis zu 38

einzig die anzahl der quellen und wie schnell sie abgefragt werden können wurde bei mir durch die MTU beeinflußt

MxM.,
klar müssen die Daten zu Dir gesendet werden, doch das hat nicht smit der Anzahl der Verbdinungen zu tun. Wie Usul schon erwähnte geschieht dies eh per UDP. Es kommen lediglich 10 neue Verbindungen zu stande, wenn 10 neue Quellen gefunden wurden.

Daß die MTU-Größe etwas mit Spielraum für Fehler zu tun hat wäre mir auch neu. Tatsächlich ist es doch so: wurde ein TCPIP Packet defekt empfangen, oder ging es verloren, so wird es erneut gesendet, egal welche MTU eingestellt ist.

Wie genau mißt/beobachtest du das? Ich wüßte nicht, wie ich da halbswegs nachvollziehbare Ergebnisse/Beobachtungen hinbekommen soll.

Usul,

offen gestanden mit dem auge... wobei ich dafür ca 80 äußerst gut verteilte downloads mit vielen quellen als testobjekt benutzt habe... und dann auf ca. 30 stunden verteilt mir die werte nach je 2 stunden angeschaut habe


udp hin oder her... genausowenig ist mir wichtig ob das paket per tcp ip nun als lost oder nicht ist... richtig ist, die verbindung wird per UDP nicht 2seitig aufrecht erhalten und regelmässig gegenseitig bestätigt. UDP Pakete sind dennoch transfer und spielen somit maßgeblich für die MTU eine rolle, da es jeweils sehr wohl den datenstrom beeinflußt... ob nun von mir WEG ...oder zu mir hin... ob einbahnstraße oder nicht... spielt keine rolle


xman

sofern man steuern könnte, ohne übertragung auf daten zu verzcihten die man bereits hat...dann würde DROP NO NEEDED und ähnliches vielmehr sinn machen... so aber bekommt man die selben quellen solange regelmässig rein, bis man sein kontingent mit anderen gültigeren quellen gefüllt hat.
so aber müssen die daten erstmal zu mir, und einzig nach der überprüfung bei mir weiss mein mule, welche quellen er nicht nochmal kontaktieren braucht, da bereits vorhanden. die ergebnisse in meine richtung werden aber komplett gesendet... vermutlich bekomme ich also von 100 leuten jeweils alle anderen 99 ausser ihnen selbst und mir... da erst bei mir geprüft werden kann, ob ich diese habe oder nicht. insofern bekomme ich 100x99 = 9900 source ex von einem file der 100 quellen hat in dem zeitabstand der für source ex eingestellt ist... vermutlich 60 sekunden.

jetzt haben die meisten files aber durchaus auch 300,400 quellen

bei 400 teilt mir jeder die quellen der anderen 399 mit

400x399, das sind dann prinzipiell 159600 quellen... die wie gesagt erst bei mir geprüft werden, ob sie im speziellen abgefragt werden.


deswegen habe ich auch eine beschränkung auf 100 quellen max. je file... die sache läuft mit dem source eX also überproportional...

deswegen gabs zu den einführzeiten von source ex sehr oft den tipp, source ex abzuschalten.... für besseren datenfluß... was sehr oft auch der fall war.

leider haben hier die server betreiber rebelliert... was in einem gewissen maß sinn macht... in anbetracht des gesamten datenaufkommens wäre es aber aus meiner sicht sinnvoller das source ex abzuschalten und dafür statt servern mit 120.000 usern nur noch 80.000 verwalten würden.

ich persönlich denke sogar, dass der source ex den ein oder anderen timeout beim datentransfer und somit also abgebrochene transfers verursacht.


leider also kann man heute den source ex daher nichtmehr ausschalten.
einzige maßnahme kann hier also nurnoch sein...die abfragezeiten zu erhöhen von hause aus....



server werden von mir übrigens alle 24 minuten...also 1600 sekunden belastet...
andere server mit dem anderen maximumwert von 2000 und laufen tut es trotzdem.

Das es wichtig ist (was irgendwie relativ ist, mich interessiert's nicht), ändert nichts an der Tatsache, daß es in diesem Thread völlig fehl am Platz ist. Daran ändert auch deine abenteuerliche "Sachverhalt"-Erklärung nichts.

Ich lese diesen Thread um mich über den eWombat zu informieren. Eure anderen Themen sind zwar vielleicht interessant, aber kann es wirklich so schwer sein, darüber in einem eigenen Thread zu diskutieren?

Ich fänd's nett, wenn das passieren würde.

ich hoffe, dass der entwickler dann in denselben threads liest, und die zeit dazu findet diese zu suchen um herauszufinden um welche themen es dabei geht.

wenn hier wie gesagt "information" zum ewombat einzig erscheinungsdatum sein soll... dann bitte... nur zu. ansonsten wüßte ich nicht, ab wann eine information über den grenzverlauf hinausgeht.... vermutlich dann wenn mehr als ein 3 zeiler entsteht....

aber dann hoffe ich, dass ihr ohne den diskussionsaustausch darüber nach wie vor die qualität wahrt...

ansonsten klar gern... darkwolf schreibt schön seinen wombat ohne grossartige rückdiskussionen über sinn und unsinn lässt hier alle 2 wochen eine information zurück ob und wann der nächste zu laden ist, am ende sagt jeder "danke" oder "*******e"

schöne form von information.


aber kein problem. was ich mti allen anderen threads dieses forums machen kann, kann ich auch hier...dann les ich eben nurnoch

MxM.,
Sag mal willst Du es nicht begreifen ? Du frägst alle x Minuten EINEN Client ab. Dieser schickt Dir seine Quellen. Der emule überprüft welche er davon noch nicht kennt. Diese frägt er ab. Fertig.
Ich empfehle Dir einfach mal das Logfile des Mulies anzusehen. Daran kann man das wunderbar nachvollziehen.
Und da es jetzt schon wieder OT wird, ist für mich das Thema beendet.

Da es bei besagten Dingen nicht ausschließlich um eWombat-bezogene Informationen geht, solltest du vielleicht mal darüber nachdenken, ob es nicht doch Sinn macht, diese Diskussion für alle sichtbar zu führen.
Genau das ist nämlich das Problem: Es geht hier einfach nicht mehr um spezifische Probleme des eWombat. Also führst du deine eigene Argumentation in einem einzigen Posting ad absurdum.
Aber das siehst du bestimmt sowieso wieder ganz anders :roll:

darkwolf ist einer der Modder, der sich auch um kleine Probleme kümmert.
Das habe ich noch bei keinem anderen gesehen.
Bei einem anderen Modder musste ich erst massiv in meiner Sig auf ein Problem
hinweisen und die Antwort kam erst nach vielen vielen Tagen.
Das ist ja wohl noch überzeugenderer oder ?

Und das man sich bei jemanden, der einem eine Information gibt, bedankt,
ist doch wohl selbstverständlich. Ich sehe es jedenfalls so.
Ob mir die Info hilft oder nicht. Jemand hat sich jedenfalls die Mühe gemacht
und mir geantwortet. (OT)

datei 1 [quellen] 76
datei 2 [quellen] 76/79
datei 3 [quellen] [3] 38/68
datei 4 [quellen] [1] 13/15

summasummarum hier 76+79+68+15 = 238 EINZELNE clients

wie du richtig bemerkst wird JEDER einzelne client alle x minuten abgefragt. sagen wir alle 10 Minuten. Mindest und Maximumzeiten sind bekannt.

238 clients werden (avoid too many connections at one moment) schön verteilt auf 10 minuten abgefragt. 10x60 alle 600 sekunden ein client 600/238 = alle 2,5 sekunden wird ein client abgefragt ob er neue quellen kennt. der client ist jetzt x ich bin a. a -> x hallo ich brauche deine quellen. x -> a hier sind meine quellen. a: quellen lesen... aha z neue quellen als source hinzugefügt. diese werden den bestehnden 238 addiert.

dies ist der idealfall. wenn die zeit kürzer eingestellt ist sieht die sache extremer aus... zumal 90% der clients durchaus mal an einer einzigen sekunde nicht EINEN client abfragen sondern meinetwegen 30 clients... und dafür fragen sie dann 30 sekunden lang garkeinen ab.

den rest kannst du mir per pm schicken.

Wie Kosh,
schon sagte intressant und wissens Wert ja aber nicht nur eWombat spezifisch.

mfg
Odinasgardson

Odinasgardson,

direkte frage, auf ne direkte antwort:

warum schreibst du mir DAS jetzt nicht als pm ?

wer dem verlauf folgt stellt fest, dass eine frage an mich gestellt wurde innerhalb des threads, wie schon beim ersten mal. diesen habe ich ebenfalls im verlauf des threads beantwortet um eben all jenen die die frage gelesen haben (welche ja nur in dem thread sind) auch die antwort zu geben.
über die SUCHfunktion wird es sowieso gefunden, egal wo es ist.
warum also müssen jetzt hier immer 5 leute denselben hinweis geben ?
reicht da nicht einer,.... die aussage von kosh hat doch nun mehr als alles gesagt... auch wenn ich der meinung bin, dass der wombat dieses abfrage eben durhc AVOID HIGH CONNECTION komplett anders handhabt als andere...und damit überhaupt nur so gleichmässig zu berechnen ist.,.... aber bitte sehr, nicht dass ich mich nicht anpassen könnte...den thread zum thema MTU im offtopic (wo sonst soll das hin) hat bis jetzt niemand bemerkt...und der ist schon länger da, als kosh hier schreibt.

Doch ich habe in gesehen und es ist nicht persönlich oder böse gemeint ich finde im großen und ganzen das was du dazu beitragst ist sehr intressant und auch wissenswert. Doch hast du leider die angewohnheit etwas zu sagen wir mal ergeizig zu sehen und vertiefst dich immer so in eine Sache das das ganze immer etwas ausufert.
Aber wie ich schon sagte das soll kein Angriff auf dich sein nur ein Hinweis
Also nichts für ungut. :wink:

mfg
Odinasgardson

Hi,

@MxM, wenn dich die ganzen Protokollgeschichten so sehr interessieren, lies dir die
sachen auf emule-projekt durch u n d analysiere die Sourcecodes und zieh dir vieleicht mal ein paar Info's über TCPIP rein...(und das ist jetzt tatsächlich so gemeint wie es sich anhört)

zum MTU: Das hat erstmal nichts mit dem eMule zu tun. Das ist einfach die Packetgrösse von TCPIP (die ideale grösse hängt von eurem ISP ab, bei T-DSL ist es 1500).
Wird nun ein TCPIP-Packet verschickt, das grösser als die MTU ist, wird dieses Packet gesplittet was ein bisschen Netzwerk-Overhead zur folge hat.
Die eMule Client<=>Client Packete sind alle immer kleiner als die MTU, theoretisch bringt die einstellung nur etwas beim DL und UL. Aber erstmal muss man wissen welcher MTU bei Windows eingestellt ist und welche MTU der ISP verwendet.
Eine Anleitung wie man das macht findet ihr hier: http://www.tek-tips.com/gfaq.cfm/lev2/5/lev3/60/pid/581

cu
darkwolf

Bei DSL über PPPOE geht meistens nur eine MTU von 1492. Alles was größer ist wird fragmentiert.

Hi,

@digitalfrost, sorry, hast recht (1500 ist bei Win2000 Standart-MTU). Der eWombat benutzt als Packetgrösse für Dateipackete 1300 (+40 Byte eMule Protokoll) also
wird da bei DSL kein TCPIP-Packet fragmentiert, falls der MTU unter Windows
richtig eingestellt ist.

cu
darkwolf

Einstellbare MTU Größe wär doch ein Feature für die 0067 ;). Das ist sowieso komisch das die MTU Größe im Muli hardcoded ist. Warum wird nicht einfach die größtmögliche MTU genommen? Wenn der eWombat 1300 als Standard nimmt heißt das ja, dass bei jedem Modem-User (okay unrealistisches Beispiel) die Pakete fragmentiert werden.

Beim "Morph" kann man das doch einstellen, glaube ich. Wäre doch mal ein nettes neues Feature für unser aller Lieblingsmod ;)

Hi,

@digitalfrost & Kosh: Ich schwanke noch zwischen Slugfillers 'No refrag' und der einstellbaren MTU, wobei ich mir aber vom 'No refrag' mehr verspreche, da die MTU eigentlich nichts am Download oder Upload vom eWombat verbessert, man den eWombat aber schön mit zu niedrigen/zu hohen Werten in die Knie zwingen kann. Leider lässt sich der richtige MTU Wert nicht einfach ermitteln...
Also mal eine Frage an Alle:
Das es ein minimaler Arbeitsaufwand ist, wer will eine einstellbare DataPacketSize (MTU-Wert) im eWombat haben ?

cu
darkwolf

darkwolf,

ich nicht , weil ich mich damit nicht sonderlich auskenne .. bin auch so mit WOMBAT zufrieden *gg*

darkwolf,

wenn du 'No refrag' für besser hältst, dann nimm das. Erfüllt ja denselben Zweck (wenn ich das richtig verstanden habe) und man kann nix falsch machen (so wie bei MTU).

Eine einstellbare MTU würde meiner Meinung nach nur was bringen, wenn man wüßte, wie man die einstellen muß, und/oder man irgendwie merkt, wenn sie falsch eingestellt ist. Was soll ich mit einem Wert, den ich zwar verändern kann, aber ich nicht weiß, was für Änderungen sinnvoll sind? Gar nichts, und ich lasse die Defaulteinstellungen. Dann kann ich mir den Aufwand auch sparen.

Wenn es eine automatische Methode gibt, die MTU zu ermitteln, wäre das natürlich am besten. In 2000/XP gibts ja sowas schon, kommt aber wohl bei Emule nicht zum Zuge, sonst würde sich die Frage ja nicht stellen. Hier nochmal die Erklärung des Slugfiller-Features von emule-project:

Ich denke auch eine einstellbare MTU ist nicht von notwendig, konzentriere dich lieber auf die Plug ins oder andere noch wichtige Dinge die für den Mod wichtig sind.

mfg
Odinasgardson