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.

Hi,

die durchschnittliche Downloadraten ergeben sich beim eWombat aus den Downloadmenge der letzten 5 Minuten und (der Wert in Klammern bei der Statistik)
über die gesamte Laufzeit. Der Werte der in der Statusleiste angezeigt wird ist der durchschnitt der letzten Minute.
Die Berechnung der Downloadrate ist noch nicht sonderlich genau (ist noch der alte 0.28a code: Menge der übertragenen Bytes pro Sekunde) sollte aber im durchschnitt um nicht mehr als 10% unter dem tatsächlichen Wert liegen. Es wird allerdings eine Menge Overhead erzeugt wenn der eWombat gerade Quellen abfrägt.

zur Zwangstrennung: Xman hat recht, die erkennung ob man eine neue IP hat, ist ansich kein Problem, ich möchte es halt bloss auch gleich erkennen können ob der IP-Wechsel durch eine unterbrechung der Internetverbindung zustande kam (um während der Unterbrechung z.b. den Speicher aufzuräumen und die Timer auf 0 zusetzen, damit eben gleich wieder nach Quellen gefragt wird)

cu
darkwolf

darkwolf,


Erstmal Danke für Deine schnelle Antwort.


Aus meinem TCP Monitor gingen bei einem 5 Minuten Screenshot folgende Daten allein für den eingehenden Datenstrom vom Wombat hervor, also dem was unter Download fällt:

Nachdem diese Werte gestimmt haben, bin ich ins Grübeln gekommen und habe MiniStatistik und Statusleiste überprüft. Daraufhin habe ich zu folgenden Zeiten folgende Messungen gemacht:

Damit konnte ich nicht die von mir gefühlten 50% nachstellen, die vielleicht zu einem anderen Zeitpunkt so ausgesehen hatten. Hier zeigt sich also ein alter Bug bei CPU Last, aber ich sehe auch, dass Wombat in seinem eigenen Statistik-Fenster echte Werte hat. Der Wert der MiniStatistik wurde nach meinem Gefühl 5x pro Sekunde aktualisiert, der Wert der Statusleiste alle 3 Sekunden.

Läßt sich der Wert der in der Mini Statistik steht auf der Statusleiste ausgeben ?
Hat jemand anderes ähnliche Erfahrungen gemacht ?
Ist es möglich, dass der Overhead in 5 Minuten bereits knapp 1 MB beträgt ?


cu Termi

darkwolf,
da es jetzt anscheinend immer häufiger vorkommt, daß sich Leecher versuchen vor dem rechtmäßigen Userhashbesitzer auf dessen Userhash zu registrieren (ich weiß es macht keinen Sinn, aber sie tun es dennoch), sollte man bei SNAFU vielleicht folgendes bedenken:
Nicht die sicher identifizierten Clients von der SNAFU Prüfung herausnehmen,
sondern SNAFU auf alle Clients anwenden und nur diese identifizieren lassen, welche sicherlich keine Leecher sind.

Ich weiß natürlich nicht ob das technisch möglich ist, war nur ein Gedanke den ich hiermit kundgetan hab ;-)

Hi

@Terminal, also die Werte in der Ministatistik werden maximal jede Sekunde erneuert und der High-CPU Bug existiert noch. Momentan werden die Download Raten beim eWombat an drei verschiedenen stellen berechnet (wie eMule) ich arbeite aber daran die Berechnung der Downloadrate auf den selben Level wie die Uploadraten zu bringen (wobei dann die Overhead-Werte auch genau stimmen).

@Xman, momentan sieht es so aus, das der s.n.a.f.u. nicht mehr bei clients angewandt wird, die als sicher erkannt wurden (da bei solchen zumindestens nicht mehr der Hash wechseln kann). Aber ich werde deinen Vorschlag mal testen...(Dann erwischts aber mit sicherheit einige LSD10 mit eingeschalteter Community-Mimick)

cu
darkwolf

cu
darkwolf

Ich habe die Dateien von einem alten Mod (0,29c mit SUI)
herrüberkopiert so, wie es in der rtf steht, allerdings wurde die preferences.dat nach dem ersten Start nicht vom Verzeichniss /eWombat/preferences.dat nach eWombat/config/Preferences.dat herrüber kopiert sondern blieb dort /eWombat/preferences.dat. Nach erneutem Start des eWombat hieß es im Log cryptokeys initialized, wird also mein altzer userhash weiterhergenommen?
Ich gehe mal davon aus, da sonst keine andere preferences.dat da ist.
Könntest du bei der nächsten Version es so einrichten, dass man im Log file seinen Userhash sieht.

Hallo,


da ich das Phänomen inzwischen wieder hatte, habe ich nochmals die Zahlen heruntergerechnet. Es liegt in Wirklichkeit nicht am Wombat, sondern habe ich einen cFos Treiber installiert. Dieser wird über einen virtuellen comPort gesendet und zählt somit extra. Alle Tools die den TCP Traffic offensichtlich zählen, scheinen hier nicht unterscheiden zu können und addieren das ganze. Ich hätte nicht gedacht, dass sich 2 Tools irren, aber der Wombat nicht. Die oben geschriebenen Zahlen sind dennoch richtig, da sie sich nicht auf TOTAL beziehen, sondern nur auf die Wombat-Zahlen.

cFOS User aufgepasst: Zahlensalat ;-)

Hi

@Edol die /eWomabt/preferences.dat wird nach eWombat/config/eWombat.dat kopiert. Vergleich mal die ersten 16 Byte dieser zwei dateien, wenn die gleich sind, dann wurde der alte userhash übernommen.

@Terminal, ich habe mal den Download eine Zeitlang beobachtet und habe festgestellt, das die DL Anzeige in der Statusbar ca. +/- 1KByte/sec dem reallen
Traffic (über Router gemessen) entspricht. Aber wie gesagt die DL-Messung wird noch überarbeitet :wink:

cu
darkwolf

Kleiner Zwischenbericht zur 0.064er
- Tempdir änderung pro File (fertig) - Incoming ist in Arbeit.
- Checkdiscspace (fertig)
- Autoupdate ipfilter und fakecheck (fertig)
- Dateinamenbereinigung (fertig)
- Stabileres TCPIP (fertig)
- Bessere DL-Raten Messung und Release-Funktionen (in Arbeit)

Hey darkwolf, :lol:
Ich weiß ja nich ob du schon weißt aber lies mal hier.
http://www.emule-web.de/board/viewtopic.php?t=5067
da hat jemand deiner Mod als Grundlage genommnen was ansich ja auch löblich ist aber ich glaube nicht das es das gelbe vom Ei ist was derjenige gemacht hatt.

mfg
Odinasgardson

@ Darkwolf
thx.
Ich habe nicht bemerkt, dass die preferences.dat zur eWombat.dat wurde.

Dein Mod sieht super aus, leider ging es nicht ihn über die Nacht laufen zu lassen ,weil die Internetverbindung getrennt wurde (keine 24h Trennung). :( :(

Was mich seit einiger Zeit wundert ist, daß ich selbst ca. 3000 Quellen und mehr habe, aber relativ wenig in meiner Warteliste,, obwohl ich relativ viel im Share habe. ca. 40GB im Moment.

Auch nach 2 Tagen gerade mal knapp 4000. Früher waren das schon nach ein paar Stunden so viele.

Selbst Leute, von denen ich gerade lade und die selbst noch nicht alles haben, ich aber sehe, daß ich manche Chunks habe, die sie selber nicht haben, sind nicht bei mir in der Liste, obwohl als "Secure" eingestuft.

Am download kann ich nicht meckern. Aber es stimmt mich komisch!
Meine stats sind sei eWombat wieder nach oben. von 1:1,4 zu folgendem.

Ratio: 1 : 4,35 (1 : 2,81)
Heruntergeladen (Session (Total)): 3,50 GB (115,66 GB)
Hochgeladen (Session (Total)): 824,70 MB (41,14 GB)
Average(5-min) DL-Rate: 49,30Kbs (55,69Kbs) UL-Rate 11,33Kbs (12,01Kbs)

aktive Verbindungen (geschätzt): 251 - Zu viele Verbindungen: 2
UL-Sessions successful: 285 - failed: 141 - Avg. time: 18:28 mins
DL-Sessions successful: 915 - failed: 243 - Avg. time: 23:12 mins
Wartende Uploads: 3960
Gefundene Quellen: 3179
SUI successful: 8825 - failed: 44
Detected 286 leechers, 46 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 20:42 h
Mem used: 186,34 mb free: 1861,53 mb


PS: ich glaube, daß die leecher und credit thieves abnehmen. Es sind immer weniger in der Liste. Außer es hängt doch irgendwie mit der Warteliste zusammen.