![]() |
sagen wir mal so... im grundegenommen gib ich Usul voll und ganz recht. Es weiß niemand welcher MTU-Wert nun wirklich sinnvoll ist. Andererseits hat der ewombat schon andere TCPIP Einstellmöglichkeiten. Insofern wäre der MTU Wert die logische Ergänzung dazu. |
darkwolf, also ich wünsche mir so eine Option, ich gehöre eh zu den Leuten die immer jedes kleine Setting verstellen müssen ;). Die MTU rauszufinden ist kein Problem www.speedguide.net/analyzer.php. Ich hab keine Ahnung was "No regfrag" ist, aber wenn es die gleiche Funktion hat ist es Newbie freundlicher. Einstellbare MTU wär mir trotzdem lieber, wenn jemand keine Ahnung hat ist er ja nicht gezwungen an den Einstellungen rumzufummeln. |
Zitat:
|
Das ist wieder ne andere Geschichte hier wird direkt vom Modder gefragt was wir möchten und so ist eine Diskussion darum logisch gesehen nicht OT.Aber wie gesagt Leute die sich damit auskennen mag es helfen aber was glaubt ihr wieviele ahnungslose einfach an allen Einstellungen rumspielen und dann nicht mehr weiter wissen .Nicht allen ist das Forum bekannt und sollte der eWombat nicht ein Schlanker einfacher Mod sein ? Wenn das so weitergeht das man jede kleinigkeit einstellen kann sind wir bald bei Fusion oder LSD Standart wo selbst erfahrene User erstmal genau schauen müßen. mfg Odinasgardson |
Um ein letztes Mal aufs Thema MTU zurückzukommen... die Frage geht jetzt direkt an darkwolf: macht es Sinn, die größtmögliche MTU ohne Fragmentierung zu verwenden ? Anmerkung: Maella hat die einstelle MTU schon lange. Abänderung des Standardwertes von 1340 brachte keine direkt sichtbare Änderung. |
Zitat:
Gibt es z.B. im Morph-Mod... Allerdings halte ich die Möglichkeit, die MTU zu ändern, für nicht besonders hilfreich. Denn erstens merkt man Änderungen kaum (oder sagen wir, praktisch gar nicht) und zweitens was würde das bringen? In emule (egal welcher Mod) gibt es so viele Einstellungen, mit denen man das Dl-Verhalten optimieren kann. Bis sich da ein veränderter MTU-Wert auswirkt, kann man vergessen. Man würde dadurch also nur ein sinnloses Feature reinbringen, mit dem wahrscheinlich viele User überfordert wären, da sie nicht genau wüssten, wie sie dieses einzustellen haben. |
Hi, zur MTU: Für den eMule ist die MTU (inter Fragsize) nur insofern wichtig, da sie die grösse der DatenPackete angibt, die er versenden will. d.h. wäre die MTU im eMule/eWombat sehr klein müssten mehr Datenpackete erstellt werden und die CPU-Beanspruchung steigt. Eine Verbesserung der Übertragungsleistung wäre bei einer ideall eingestellten MTU nur messbar wenn mit voller Kapazität Up und Download läuft (ca. 0.5% höhere Leistung. Eigentlich würde es nur etwas bringen wenn man sich mit der Gegenstelle auf einen gemeinsamen Wert einigen könnte (eMule benutzt 2*1300, Plus und eWombat 1*1300 usw.). Aber dazu wäre eine Protokollerweiterung und ein ziemlicher Aufwand im eMule-Socket code notwendig... Viel sinnvoller ist es (meiner meinung nach) vorallen für Win98/Me User die MTU von Windows richtig einzustellen (und da gibt es Tools). Zum 'no refrag': Der eMule erstellt die Datenpackete anhand des MTU-Wertes, und füllt das letzte gegebenenfalls mit 0 falls die angeforderte Datenmenge nicht genau x mal MTU entspricht (daher steht ein Upload oft auf 0.0 Kbs bevor er endet). Der 'no refrag' passt in solch einen Fall die grösse des letzten Datenpackets an, was die Upload-Datenrate etwas gleichmässiger hält. Beim 'no refrag' wird kein MTU-Wert benötigt... Kleiner Tip noch, Win2000/XP kann man über die registry so einstellen, das es den idealen MTU-Wert selbst ermittel: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters] "EnablePMTUDiscovery"=dword:00000001" <- ist standardmässig auf '0' d.h. aus cu darkwolf |
@ darkwolf, haste dich da jetzt nicht vertan ? bei mir steht EnablePMTUDiscovery"=dword:00000001" <- ist gleich bei mir 1 also an wenn also EnablePMTUDiscovery"=dword:00000001" <- ist standardmässig auf '0' d.h. aus ist wie kan das dann bei mir 1 an sein ? mfg Odinasgardson |
Zitat:
So langsam habe ich das Gefühl, das eine einstellbare MTU nur in seltenen Fällen was bringt, man sich mit falschen Einstellungen aber schön Ärger einhandeln kann. Wenn die Einstellmöglichkeit gewünscht wird und es kein großer Aufwand ist, diese Möglichkeit zu ergänzen, dann soll sie meinetwegen ergänzt werden. Ich für meinen Teil würde sie nach dem jetzigen Erkenntnisstand nicht ändern, weil ich nicht wüßte wie. Odinasgardson Wenn ich darkwolf richtig verstanden habe, ist der Registry-Link so geschrieben, das das Feature aktiv ist (also eine 1 drin steht), er aber als Bemerkung dazu geschrieben hat, das es standardmäßig aus ist (also auf 0 steht oder der Key gar nicht existiert). |
Ja gut wenn man es so sieht ist es richtig ,war wohl etwas ungeschickt von darkwolf, ausgedrückt. :wink: Passiert jedem mal. Usul, Es wird ne Menge Newbie,s geben die dran rumstellen und dann hier auftauchen und dir ihr Leid klagen, ich denke das es nicht wirklich von sinvollen Nutzen ist. Zitat:
Also überflüssig. mfg Odinasgardson |
Und was macht man wie ich, der diesen Registry Eintrag gar nicht hat ? |
dann erstellt man sich den einfach :wink: oder nutzt Progs wie DFÜ SPeed oder DFÜ optimierer mfg Odinasgardson |
Zitat:
blomy dann legst du ihn einfach an (Achtung, exakte Schreibweise ist wichtig), oder du suchst dir ein Tool, was das macht (z.B. X-Setup, mein bevorzugtes Registry-Tweak-Tool, http://www.xteq.com/ ). |
Vorsicht vor DFÜ Speed, das hat bei mir unter Win2k die Registry Einstellungen für Win9x gesetzt (bringt natürlich nix). Der TCP Optimizer von SpeedGuide.net ist ziemlich gut IMO. Wobei ich für den Muli die Anzahl der Duplicate ACKs auf 3 gesetzt und die Black Hole Detection aktiviert habe. |
Usul Meins auch (Version 6.3). Und mit der Registry kenne ich mich doch so einigermassen aus. Ich habe cFos am Laufen (mit DSL Optmimierung oder wie das da heist) und es läuft bei mir alles super. Bloss der Schlüssel war nicht da. Never touch (change) a running system Meine Frage war irgendwie nicht richtig gestellt. :D |
auch wenn ich jetzt mal wieder allen widersprechen sollte aber... nach allem was ich bisher über windows und MTU gelesen habe (auf vielen Internetseiten) + eigene Erfahrungen ist MTUDisccoery standarsmäßig EINgeschalten. Ich persönlich hab subjektiv bessere Erfahrungen gemacht wenn ich dieses ausschaltete. (hatte ich schon vor Wochen mal in irgend nen Thread geschrieben). Will mich hier jetzt nicht als Besserwisser hinstellen, sondern nur mal eben meinen Kenntnisstand einbringen ;-) |
Zitat:
|
Usul, Zitat:
Also warum ein Feature was nichts bringt ?oder so wenig das es nicht zu bemerken ist. Ich denke der eWombat kommt ohne ganz gut zurecht. mfg Odinasgardson |
Hi, @Odinasgardson: Also bei mir wars nach einer Win2000 Neuinstallation aus (hab aber mal rumgeschaut, bei anderen Installationen gibt es den Schlüssel garnicht, bei manchen wiederum ist es von vornherein aktiviert) :wink: Nochmal zum MTU: Die MTU von Windows und die MTU vom eMule sind zwei verschiedene Sachen... Es gibt die MTU-Einstellung von Windows, die ist wichtig und sollte richtig eingestellt sein (in abhängigkeit von der MTU die euer Provider benutzt), was die allgemeine Zugriffsgeschwindigkeit aufs Internet verbessert. Dann gibt es die MTU bei manchen eMule-Mods, die sollte man eigentlich besser als 'eMule Datei-DatenPacket Grösse' bezeichnen: Pro durchlauf (also alle 100ms) werden an Clients die Upload haben, 0-x dieser Packete geschickt (je nachdem ob die Übertragung der letzten Packete schon fertig ist oder nicht) und für jedes Packet das verschickt wird entstehen 40Bytes Protokoll-Overhead (innerhalb von eMule). Also um so kleiner der eMule-MTU um so mehr Overhead. Vom Windows-TCPIPStack wird dann alles was der eMule liefert in TCPIP-Packete zerlegt und gesammelt (abhängig u.a. von der Windows-MTU) und auf das Netzwerk losgelassen... Der 'no refrag' sorgt dann quasi u.a. dafür, das die 'eMule Datei-DatenPacket Grösse' an die tatsächliche Client-Geschwindigkeit angepasst wird... @Alle 'Experementierfreudigen': Ich habe jetzt bei den TCP-IP settings eine verstellbare MTU eingebaut (die neugier was damit subjectiv ereicht werden kann, war mir die 5 Minuten arbeit wert ;) ) cu darkwolf |
@ darkwolf, Na gut du bist der Modder und machst schon das richtige wie immer bisher. :lol: Werd mir das dann mal anschauen ob und in wieweit mir das was bringt. mfg Odinasgardson |
Hi, @Odinasgardson: Der MTU war kein aufwand, hab den code eh noch drin gehabt, es hat bloss die Einstellung dafür gefehlt ;) An 'Slugfillers no refrag' arbeite ich gerade (in Verbindung mit den release-slots) und der hält den upload so weit wie ich bis jetzt sagen kann noch stabiler als bisher... cu darkwolf |
ich begrüße in allererste linie die diskussion darüber. letztenendes ist sogar ein ergebnis gut, welches besagt dass das einstellen der MTU 0 bringt. |
@ darkwolf, Zitat:
mfg Odinasgardson |
Zum Thema MTU: Und was ist mit den Router Usern? Bei mir erledigt ja das der Router. Ich habe da schon mal das eingestellt, was laut einer Zeitschrift das optimale wäre für DSL. Bei mir kam dann aber gar nichts mehr an. So wie es auf Standard ist, funtk aber. |
Alles zurück! Das was ich einstellen kann ist MSS, nicht MTU! |
cobrajet, die ist eh immer MTU - 40 |
THX, habs bei mir im Router eingestellt. 1492-40. 1492 hat dieser tcpoptimizer gemeint, wäre das beste. |
Ab wann gibt es denn ungefähr Aussicht auf das Webbrowser-PlugIn ? Bin darauf im Moment leider unabdingbar angewiesen, kann also den Wombat nicht nutzen. Oder hat sich das PlugIn-Vorhaben auf unbestimmte Zeit verschoben ?? |
Hi, @Adnazar, die PlugIns kommen definitiv nach der 0.064er, ich habe momentan bloss relativ viel andere Arbeit und komme nicht ganz so schnell mit dem eWombat voran wie ich möchte... cu darkwolf |
darkwolf, macht nix, denn : " gut Ding will Weile haben" :mrgreen: |
darkwolf, ich bin ja mit dem eWombat wunschlos glücklich. Das angekündigte Pluginsystem wird die Wünsche nach den Features, die mir noch fehlen, mit großer Wahrscheinlichkeit erfüllen. Ich hätte da allerdings noch ein konkretes Bedürfnis nach einem Feature, das ich für recht sinnvoll halte (mal wieder seit längerem): Zitat:
|
Kosh, ist ne gute Idee ! mal schauen was DARKWOLF noch so alles zaubert *gg* |
Kosh, gebt diesem Feature noch ein paar Tage Zeit. Es ist nämlich noch in der Experimentierphase. Xman ;-) |
Ich hat's mir fast gedacht ;) |
Hi, @Kosh, mit sowas experementiere ich schon länger rum, das problem an der Sache ist, wie erkenne ich das die Internetverbindung unterbrochen ist (ohne laufend irgendwelche Server anzupingen) und wann sie wieder da ist. Bei einer Wählverbindung wäre es einfach, aber es gibt ja auch LAN-Verbindungen (z.b. über Router) cu darkwolf |
darkwolf, hab ich gelöst... ähm.. PM ;-) |
Xman, wie denn? Würd mich mal interessieren. Gerne auch per PM, falls das hier zu OT ist ;) |
Kosh, die IP Änderung wird anhand der ID Änderung erkannt. Aber dennoch.. wird bischen OT, solang der ewombat noch gar kein solches Feature hat ;-) |
Hier hast du ja schon eine ganz gute Erklärung geliefert. Das sollte erstmal reichen. Meine Frage ist ja auch schon längst beantwortet :) |
darkwolf, Wie liest der Wombat die Raten aus? Während TCP Monitoring bei der Uploadrate exakt ist, ist der Wert der Downloadrate oft nur 50%. Als Beispiel zeigt mein Monitor eine Rate von 65-88 an, während Wombat 37 ausgibt. Die Rate des Wombat fällt, wenn die Rate am Monitor ebenfalls fällt. Da am Monitor die Werte jedoch nicht unter den des Wombatwert fallen, ist es nicht möglich, dass es nur ein Average-Wert ist, da andernfalls die Rate beim Wombat weiter steigen sollte. Im Moment weicht der Average Wert mit 35,77 sowieso vom Downwert 41,0 ab. TCP Monitoring gibt derzeit 77 - 90 aus. Geladen werden 3 .ape files. Da eine Kompression mit WinAce, WinRar und WinZip nicht möglich ist, gehe ich auch nicht davon aus, daß ein Kompressionswert die Werte verändert, zumal der Wert am Monitor höher ausfällt als der im Wombat. Da die Rate der einzelnen Dateien zusammen sehr wohl die addierte Summe in der Statusleiste ist, gehe ich davon aus, dass bereits die Einzelwerte falsch sein müssten. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:12 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.