[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MODs - Allgemein (http://www.emule-web.de/board/emule-mods-allgemein/)
-   -   eMule0.28a-[lovelace.10e] [24.04.2003] (http://www.emule-web.de/board/2841-emule0-28a-lovelace-10e-24-a.html)

Usul 25. April 2003 21:30

Also bei mir habe ich SUC zwischen 6 und 16 eingestellt, Slotspeed ist 6250 (ist wohl default), und ich habe eigentlich auch immer zwei im Upload, manchmal kurz noch einen dritten. Sieht man gut in diesem Bild, die gelbe Linie sind die zwei Uploadslots, die kurzen Zacken darin ist der dritte.
http://home.pages.at/usul/lovelace10everbindungen.png

MightyKnife 26. April 2003 07:15

Zitat:

Zitat von cosmic girl
Xantor
Hab da mal eine Frage zu dem community string in deinem eMule nick:
Der [lovelace] Mod unterstützt doch kein community sharing - was bringt

Warum hat der Mod eigentlich kein Community Sharing ?

Ist doch eigentlich eines der am leichtesten zu implementierenden Features.
@lovelace: Kannst du das vielleicht nicht einbauen ?

Was noch interessant wäre: Hash-gebundene Friend-Uploadplätze.
Alleine schon wegen der 24 Stunden Zwangstrennung der Telek*m finde ich die normalen IP gebundenen Uploadplätze für DSL-User benachteiligend. Wenn man dagegen den Uploadplatz Hash-gebunden machen würde, könnte man ihn jederzeit in der Friendlist aktivieren, auch ohne das diejenige Person connected ist, und der Uploadplatz würde auch nach einem Disconnect erhalten bleiben...

Sagt mal, ich lese immer wieder, dass es so große Probleme mit "gestohlenen Userhash's" gibt. Seid ihr sicher, dass da so oft wirklich eine Userhash von einer anderen Person gestohlen wird ?

Irgendwie kann ich mir das nicht vorstellen. Ich glaube eher, dass da zwei Leute zufällig die gleiche Hash bekommen haben, da die Hash-id ja komplett nur eine 256 Bit Zufallszahl ist.
Man denke nur an das Geburtstags-Paradoxon aus der Wahrscheinlichkeitstheorie.........

Usul 26. April 2003 10:21

Zitat:

Zitat von MightyKnife

Warum hat der Mod eigentlich kein Community Sharing ?

Ist doch eigentlich eines der am leichtesten zu implementierenden Features.
@lovelace: Kannst du das vielleicht nicht einbauen ?

Es gibt auch Leute, die Community Sharing nicht mögen (z.B. ich), vielleicht ist lovelace auch einer von dieser Sorte.

Zitat:

Irgendwie kann ich mir das nicht vorstellen. Ich glaube eher, dass da zwei Leute zufällig die gleiche Hash bekommen haben, da die Hash-id ja komplett nur eine 256 Bit Zufallszahl ist.
Man denke nur an das Geburtstags-Paradoxon aus der Wahrscheinlichkeitstheorie.........
Also mein Userhash ist 32 Zeichen lang, jedes Zeichen repräsentiert 4 Bit, also insgeamt 128 Bit (16 Byte). Ich gehe jetzt mal davon aus, das da keine Prüfbits dabei sind, also alle Bits gewertet werden. Dann haben wir 2^128 verschiedene Userhashs, also 3,4028236692093846346337460743177e+38 verschiedene (Das sind seeeehr viele ;-) ). Die Wahrscheinlichkeit, das zwei Userhashs gleich sind, wäre also ETWA 1:3,4028236692093846346337460743177e+38 (Das ist seeeehr unwahrscheinlich ;-) ) Laut dieser Seite liegt die Wahrscheinlichkeit, im Lotto zu gewinnen UND danach vom Blitz getroffen zu werden, bei 1:140000000000000, ist also viiieel warscheinlicher. Wie oft ist dir das schon passiert? Und wie oft sind dir schon zwei mit dem selben Userhash begegnet? Na, klingelts? Das ist praktisch unmöglich.
Zum Geburtstagsparadoxon: Die Wahrscheinlichkeit, das zwei am gleichen Tag Geburtstag haben, liegt bei 1:365 (bzw. 1:366 im Schaltjahr), und das ist gegenüber den obigen Werten doch seeeehr wahrscheinlich ;-)

P.S. Ich hoffe, ich hab mich nicht irgendwo sehr verrechnet. Aber die Größenordnungen dürften in etwa stimmen.

P.P.S. Das Killerargument zum Schluß: Die Hashs der Dateien sind genauso groß. Die werden zwar berechnet aus dem Inhalt der Dateien, aber dieser Inhalt ist ja mehr oder weniger auch zufällig. Und wie oft ist es dir schon passiert, das verschiedene Dateien (also verschiedener Inhalt) den gleichen Datei-Hash haben? Theoretisch ist das durchaus möglich, bloß eben genauso unwahrscheinlich wie ein zufällig gleicher Userhash ;-)

Arwen 26. April 2003 12:08

Schock am Morgen... :shock:

als ich vor 3 Stunden meinen Beobachtungsposten :wink: eingenommen habe, mußte ich 25 Leute in meinem upload sehen und das bei den Einstellungen die ich oben beschrieben habe.
Mein upload schwankt zwischen 34 und 42 kB/s.

Wenn ich bei 34 up 11 Leute drin habe und er geht auf 38 kommen Leute dazu. Geht der speed wieder runter bleiben die Leute drin, aber sobald er wieder Gas gibt kommen wieder Leute dazu.

Ich hoffe, das ist einigermaßen verständlich erklärt :roll:

An meinem Provider können die Schwankungen nicht liegen, weil ich zwischenzeitlich mit einem anderen Muli probiert habe, per messenger getauscht habe und per ftp. Immer konstanter upload.

Ich werde jetzt mal den SUC ausprobieren. Mal schauen wie es dann läuft.

MightyKnife 26. April 2003 12:59

Zitat:

Zitat von Usul
Zitat:

Zitat von MightyKnife
Irgendwie kann ich mir das nicht vorstellen. Ich glaube eher, dass da zwei Leute zufällig die gleiche Hash bekommen haben, da die Hash-id ja komplett nur eine 256 Bit Zufallszahl ist.
Man denke nur an das Geburtstags-Paradoxon aus der Wahrscheinlichkeitstheorie.........

Also mein Userhash ist 32 Zeichen lang, jedes Zeichen repräsentiert 4 Bit, also insgeamt 128 Bit (16 Byte). Ich gehe jetzt mal davon aus, das da keine Prüfbits dabei sind, also alle Bits gewertet werden. Dann haben wir 2^128 verschiedene Userhashs, also 3,4028236692093846346337460743177e+38 verschiedene (Das sind seeeehr viele ;-) ). Die Wahrscheinlichkeit, das zwei Userhashs gleich sind, wäre also ETWA 1:3,4028236692093846346337460743177e+38 (Das ist seeeehr unwahrscheinlich ;-) ) Laut
dieser Seite liegt die Wahrscheinlichkeit, im Lotto zu gewinnen UND danach vom Blitz getroffen zu werden, bei 1:140000000000000, ist also viiieel

Ok, ich hab's grad mal nachgerechnet. Du hast dich aber auch vertan. Deine 1:3,4e^38 stimmt nur, wenn du zwei Userhashs hast, und so kann man hier nicht rechnen - im Donkey-Netz hast du nie nur 2 User gleichzeitig drin, sondern immer mehrere Tausend gleichzeitig. Daher hab ich das ja mit dem Genutstagsparadoxon angeführt.
Um zwei gleiche Hash-Id's bei 128 Bit Länge zu bekommen brauch man 2*10^19 verschiedene Zufallszahlen = User für einen Treffer, d.h. das 2. von dir angeführte Verhältnis ist richtiger - die Wahrscheinlichkeit liegt also sozusagen bei 1:2*10^19. Ist doch etwas mehr (bzw. weniger) als ich getippt hatte.

Zitat:

Zitat von Usul
warscheinlicher. Wie oft ist dir das schon passiert? Und wie oft sind dir schon zwei mit dem selben Userhash begegnet? Na,

Du wirst es nicht glauben, aber öfters ! Zumindest glaube/glaubte ich das.
Ich hab mal in EMule selbst ein wenig Debug-Code eingebaut um zu schauen, warum ständig unbekannte Namen in meiner Freundesliste drin waren. Ergebnis: Die setzen sich nicht selbst rein (wie ich erst gedacht hatte), sondern da wird der Name eines anderen Users in der Freundesliste geändert (eine tolle Debug-Meldung: "Friend changed his name...").
Sowas passiert ja nur bei gleichen Hash-Id's. Daher bin ich bis jetzt immer von Hash-Kollisionen ausgegangen.

Zitat:

Zitat von Usul
klingelts? Das ist praktisch unmöglich.
Zum Geburtstagsparadoxon: Die Wahrscheinlichkeit, das zwei am gleichen Tag Geburtstag haben, liegt bei 1:365 (bzw. 1:366 im Schaltjahr), und das ist gegenüber den obigen Werten doch seeeehr wahrscheinlich ;-)

Ne, genau eben nicht !
Das Geburtstagsparadoxon sagt: Wenn du 23 Leute in einem Raum hast, dann hast du zu 50% Wahrscheinlichkeit zwei mit gleichem Geburtstag !
Wenn du nur 2 Leute hast, ok, dann 1:365. Aber je mehr Leute du hast, desto grösser wird die Wahrscheinlichkeit - und zwar verflixt schnell ! Und im Donkey-Netz schwirren doch etliche tausend Leute rum, deren Hash-Id alle zufällig gezogen wird, und die mal alle bei der Berechnung gleichzeitig berücksichtigen muss.

Zitat:

Zitat von Usul
P.P.S. Das Killerargument zum Schluß: Die Hashs der Dateien sind genauso groß. Die werden zwar berechnet aus dem Inhalt der Dateien, aber dieser Inhalt ist ja mehr oder weniger auch zufällig. Und wie oft ist es dir schon passiert, das verschiedene Dateien (also verschiedener Inhalt) den gleichen Datei-Hash haben? Theoretisch ist das durchaus möglich, bloß eben genauso unwahrscheinlich wie ein zufällig gleicher Userhash ;-)

Tut mir leid, das ist kein Killerargument :P

Das ganze funktioniert nur, wenn alle Zahlen zufällig sind. Hast du schonmal eine zufällige File-Hash gesehen ? Also ich noch nicht. 8)
Bei strukturierten Daten sieht das immer anders aus. Da liegt die Wahrscheinlichkeit noch sehr viel weiter darunter...

cosmic girl 26. April 2003 13:08

Ein Bug - die Frage ist nur: liegt es an der 0.28a, am [lovelace] Mod oder an der Plus.1d? :mrgreen:
So oft den gleichen user in der DL-queue hatte ich seit den uralt-Versionen nicht mehr (0.24 oder wo das noch ein Problem war..)

http://www.xi.awmspace.de/mu/lovelac...lti-Plus1d.png


Der mule läuft nun seit 49 h und die CPU Last hat sich nach dem Ausreisser von 20 % gestern wieder bei gemütlichen < 10 % eingependelt (ok, kaum DL im Moment, da der 24-h-disconnect erst 40 min zurückliegt) - aber auch bei mehr DL nie über 10 % im Schnitt.

Usul 26. April 2003 13:47

@MightyKnife

Ok, der Herr will es genau wissen, machen wir halt Nägel mit Köpfen :twisted: Ich beziehe mich auf diese Seite, dort steht auch, das man 23 Leute in einem Raum braucht für eine 50%ige Chance auf zwei gleiche Geburtstage, also scheint es sich ja mit deinen Informationen zu decken. Die Formel für die Wahrscheinlichkeit auf den gleichen Geburtstag bei n Leuten lautet p = 1 - 365! / ((365 - n) · 365^n). Münzen wir das mal auf Emule um, wir haben 2^128 potentiell verschiedene Userhashs, gehen wir mal von 1 Millionen Nutzer aus. Dann ist die Wahrscheinlichkeit von p = 1-(2^128)!/((2^128-1000000)· (2^128)^1000000) Dummerweise habe ich momentan kein Programm installiert, womit man das berechnen könnte :roll: Hat mal jemand Maple oder Mathematika installiert und kann das mal ausrechnen?
Zitat:

Wie oft ist dir das schon passiert?
Damit wollte ich nur wissen, ob du öfter im Lotto gewohnen hast und vom Blitz getroffen wurdest, als auf Leute mit nem gleichen Userhash zu treffen ;-) Letzteres ist ja laut der Rechnung unwahrscheinlicher als ersteres, passiert aber jeden Tag. Dann ists wohl kein Zufall mehr.

Wie du das mit dem Killerargument meinst, verstehe ich nicht ganz. Mir ist kein einziger Fall bekannt, wo zwei Dateien den gleichen Hash haben und trotzdem verschieden sind. Das es gleiche Userhashs gibt, passiert anscheindend viel öfter. Vielleicht ist ja auch der Zufallsgenerator für den Userhash nicht so zufällig, wie er es sein sollte ;-)

Das mit deiner Freundesliste: Nimm mal an, du hast einen Freund mit seinem Userhash in deiner Liste. Dann kommt jemand anders mit nem geklauten Userhash und seinem eigenen Namen, der Diebstahl wird nicht bemerkt, was passiert? Der User hat scheinbar seinen Namen geändert. Könnte das sein?

Edit: das wird jetzt sehr offtopic, ich halte es bloß für sehr unwahrscheinlich, das zwei Leute den gleichen Userhash haben (immer vorausgesetzt, die Userhashfunktion funktioniert einigermaßen zufällig ;-) )

MightyKnife 26. April 2003 14:33

Zitat:

Zitat von Usul
@MightyKnife
Ok, der Herr will es genau wissen, machen wir halt Nägel mit Köpfen

Meine Güte, jetzt hast du nicht nur mitr dem Hammer draufgeschlagen, jetzt hast du den Abbruchbagger gaholt :wink:

Ich hatte mit der e-Formel gerechnet, da sich so hohe Potenzen nicht ausrechnen lassen... aber es ist das gleiche.

Kurz zu deiner Anmerkung "Könnte das sein ?"
Ja, natürlich könnte das sein, daher hatte ich vorher ja auch geschrieben "glaube/glaubte".

Die Sache mit dem Killerargument könnte ich auch noch erklären, aber du hast schon recht - wird offtopic. Daher lass ich's mal.

MightyKnife 26. April 2003 15:04

So, um aber noch wenigstens ein bischen ontopic zu bleiben noch ne andere Frage an die, die sich mit SUC auskennen:

Ich würde den SUC gerne so einstellen, dass er relativ schnell reagiert. Normalerweise Upload Min 1 Max 15 (Standard DSL über Router, an welchem 4 PC's dranhängen). Wenn ich ne E-Mail mit nem grossen Anhang von einem der Rechner versende oder ne grosse Datei auf nen FTP schiebe, wäre mir das liebste, er reagiert binnen 10-30 Sekunden und schraubt den Upload innerhalb dieser Zeit auf 1 runter. Danach könnte er dann wieder so binnen 1-2 Minuten auf 15 steigen.

Ich hab selbst mal versucht, sowas mit den Parametern hinzubekommen, aber auch ich komme hinter das System nicht 100%ig hinter - er reagiert sehr träge. Ist sowas möglich ? Wie müssten Einstellungen für sowas aussehen ? Irgendjemand eine Idee ?

cosmic girl 26. April 2003 15:13

MightyKnife
Hm, bin auch nicht so wirklich glücklich mit dem SUC2 - auf dem offiziellen Board gibt's einen thread, lovelace hat dort auch mitgemischt:
http://www.emule-project.net/board/i...=15&t=14701&s=

@ all
Um das offizielle Board lesen zu können, braucht man einen account dort (nicht so locker wie hier bei uns auf dem Board ;) ).

burner 26. April 2003 21:36

hier mal ein zitat:
Zitat:

ich habe die 0.28-LSD 8c drauf. In meiner Warteliste befindetein User mit einem Lovelace-Mod. Ist auch ein ********-User und somit in meiner Friendslist.
Ich habe bereits von ihm ca. 40 MB gesaugt. Er von mir 5MB.

Tja, und jedesmal wenn er nun wieder in meinem Upload-Fenster auftaucht wird er nach ca. 38kb wieder rausgeschmissen. Auch finde ich keinen anderen Clienten mit einem Lovelace-Mod in meiner Upload-Liste.

Ergo mögen sich die beiden anscheinend nicht.
kann jemand etwas dazu sagen?
also dass die sich nich mögen glaub ich nich... aber warum war das sonst so? zufall?

CraCker2k 26. April 2003 21:44

Zitat:

Zitat von MightyKnife
So, um aber noch wenigstens ein bischen ontopic zu bleiben noch ne andere Frage an die, die sich mit SUC auskennen:

Ich würde den SUC gerne so einstellen, dass er relativ schnell reagiert. Normalerweise Upload Min 1 Max 15 (Standard DSL über Router, an welchem 4 PC's dranhängen). Wenn ich ne E-Mail mit nem grossen Anhang von einem der Rechner versende oder ne grosse Datei auf nen FTP schiebe, wäre mir das liebste, er reagiert binnen 10-30 Sekunden und schraubt den Upload innerhalb dieser Zeit auf 1 runter. Danach könnte er dann wieder so binnen 1-2 Minuten auf 15 steigen.

Ich hab selbst mal versucht, sowas mit den Parametern hinzubekommen, aber auch ich komme hinter das System nicht 100%ig hinter - er reagiert sehr träge. Ist sowas möglich ? Wie müssten Einstellungen für sowas aussehen ? Irgendjemand eine Idee ?

Genau das ist mein Prob!! Ich brauch auch die Einstellungen, hänge auch an nem Router mit 4 Clients. Und meine Mutter reisst mir jedesmal das Kabel raus, wenn bei ihr die Seite nicht innerhalb von 2 sek. aufgeht. Also bitte postet mal ne Einstellung, bei der man auch noch normal surfen kann!!!

Xantor 26. April 2003 21:47

Ich bin bei 5 LSD Clients in der Queue. Bei einem hab ich bisher 896kb gedownloadet von den anderen noch nichts. Ich werd die Clients mal im Auge behalten obs da Probleme gibt.

sharelook 26. April 2003 21:54

Ich hab von jemandem mit einer LSD 8b Version 4,5 MB bekommen. Vielleicht auch noch von anderen, aber ich hab noch nicht weiter nachgeschaut.
Irgendwie bin ich aber generell mit der V0.28 nicht ganz zufrieden. Zieht sich alles ein bisschen. Aber man darf ja nicht vergessen das das ganze ja nur eine beta ist.

sharelook

Neo000 26. April 2003 23:15

also ich muss wiklich sagen :!: :!: ALLE ACHTUNG :!: :!: diese Mod ist einfach nur geil
zieht bie mir nach kurzer Zeit schon wie sau :lol:

Upload ist auch ziemlich konstant, DL steigt

was will man mehr :?:

[lovelace] 27. April 2003 01:59

oweh, hier ist viel passiert ;) ...jaja, wenn man mal kurz nicht da ist:
(jetzt kommen 3 postings in Serie, find ich eigentlich doof, ich kann ja editieren, ja eigentlich..schon..)

zu Seite 3:
Zitat:

sprich ein Böser kann ihn nachher auch nix mehr rausbekommen
und wie! schau mal unter "man in the middle attack" nach ..

Zitat:

Ich gebe 42 kB/s upload bei 3000 B/s pro slot und habe 11 Leute im upload.
Rechnet sich also irgendwie immer noch nicht.
doch, aber nicht auf den ersten blick, und wenn einem was verschwiegen wird ;)
lovelace mods benutzen auch ein dynamisches slotspeed management wie im offiziellen clienten. je mehr up, desto höher der speed per slot. Ich glaube, es waren 0,5% oder so.
0,5% von 42kB sind dann knapp 800, die müßtest Du noch auf die 3000B/s zuzählen. 3800*11=41,8KB/s. Nu geht's auf :)

Zitat:

Warum hat der Mod eigentlich kein Community Sharing ?
finde ich schlimmer als manuelles kick/ban. Ist keine Gleichberechtigung mehr. Ich habe sogar vor, das eventuell zu unterwandern. So ne Art Hybrid in alle Communities.

userhash theft: schau mal in die known clients, sortiere nach größtem download, und schau Dir mal die anzahl gleicher werte bzw hashs an. Wirst staunen.
Tja, wenn Du öfter die Woche mal 'nen 6er im Lotto machst, dann ist ein zufällig doppelter userhash auch wahrscheinlicher. ;) Usul hats schon und noch besser erklärt...weiterlesen müßte ich können..

[lovelace] 27. April 2003 02:08

und einen ganz großen kuss an cosmic girl :roll: für die aufbauenden postings (und wegen der Namensgeschichte, mußte ich ja nochmal zuschlagen :) ).
das andere mit den vielen usern in der download-queue ist mir auch schon aufgefallen, bei mir sinds aber nicht so viele, so 2 bis drei. Mir scheints, es ist seit 27 (offizieller client? ) so...

[lovelace] 27. April 2003 02:21

empfindlicher wirds, wenn pitch und high pass runtergesetzt werden.
also (700/../2500/..) mal als extremes beispiel. Jetzt müsste nur noch drift so eingestellt (erhöht) werden, daß die fehlalarme, die durch die überempfindlichkeit kommen, augeglichen werden...
Außerdem soll der upload ja auch wieder steigen, wenn kein anderer transfer bremst, daher muß auch low pass gesetzt werden. Bei so empfindlichen sachen sollte das allerdings um die 500 oder höher liegen.

ich poste hier nochmal eine englische erklärung zu den werten.
passend zu der grafic in Suc options explained.
Zitat:

average response time is to random clients. There's done an exponential decaying average over all response times below pitch.

try setting verbose mode and you will see:
Smart Upload Control: (time:1859ms, clip:1424ms, ratio:874) VUR:15988B/s
where time is the actual response time to a random client (not averaged).
if this time is lower than pitch, an exponential average clip is calculated from it.
if additinally 'time' is lower than 'clip' the ratio average is decreased otherwise increased. Values range from 0 to 1000.

if ratio is bigger than high pass upload speed is decreased.
if ratio is lower than low pass upload speed is increased.
if ratio is between high and low pass upload speed is slightly increased by the drift value.

ah, and VUR means "variable upload rate" ;)

min upload, I would set alway to 10 max upload to 16. Only if one shares an internet connection, min=1 could be helpful.

PS: SmartUploadControl is checked more frequently than the output in verbose mode...It would be too much output, so I decided to only print out the relevant ones.

cosmic girl 27. April 2003 02:32

http://www.penthesilea.ch/yabb-smile...plets/grin.gif Ist angekommen.

Da ist mir jetzt nach eMule Neustart gleich noch was aufgefallen:
Besagter user aus dem screenshot von ganz oben erscheint schon wieder - diesmal mehrfach im log:
4/27/2003 1:09:29 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 1:09:30 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is outdated or using a stolen userhash and has been removed.
4/27/2003 1:31:09 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 1:52:49 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 2:14:29 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 2:36:09 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 2:57:50 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 2:57:53 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is outdated or using a stolen userhash and has been removed.
4/27/2003 3:19:30 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed.
4/27/2003 3:24:39 AM: Client 'dsldsldsl[ITA]' and 'Graaaaaaaaaham' have the same userhash or IP - removed 'dsldsldsl[ITA]'
4/27/2003 3:24:39 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is probably using a stolen userhash and has been blocked.

Und dennoch habe ich den Vertreter noch vielfach in der DL-queue für das file.
Müsste der dann nicht mal langsam ganz rausfallen?
Oder ist das besagtes Problem der offiz. Version?

MightyKnife 27. April 2003 08:20

Zitat:

Zitat von [lovelace
]empfindlicher wirds, wenn pitch und high pass runtergesetzt werden.
also (700/../2500/..) mal als extremes beispiel. Jetzt müsste nur noch drift so eingestellt (erhöht) werden, daß die fehlalarme, die durch die überempfindlichkeit kommen, augeglichen werden...
Außerdem soll der upload ja auch wieder steigen, wenn kein anderer transfer bremst, daher muß auch low pass gesetzt werden. Bei so empfindlichen sachen sollte das allerdings um die 500 oder höher liegen.

Also die Erklärung, die du jetzt dazu gepostet hast, ist schon erheblich aufschlussreicher als alles, was ich bis jetzt über die Suchfunktion finden konnte :D
Danke.

Aber als wirklich empfindlich würde ich diese Einstellungen auch nicht bezeichnen. Eher als etwas empfindlicher als der Standard.
Ich hab hier testweise mal eingestellt: 700/525/2500/750 mit Min=1, Max=14.
SuC hielt hier zuerst den Upload konstant auf 14 K. Dann hab ich separat auf nem anderen PC eine FTP-Verbindung zu einem schnellen FTP-Server im Netz aufgebaut und mal ne 1,6 MB-Datei übertragen.
Der Upload lag am Anfang bei 4,5 KB/Sek. Es hat dann ganze 3,5 Minuten gedauert, bis er auf 6,5 KB gestiegen ist - dann war die Datei aber auch schon drüben. In einem 2. Versuch hab ich mal 700/525/2500/50 benutzt. Diesmal fing er mit 5,2 KB/Sek an und war nach 3,5 Minuten bei 6,8 KB/Sek.
Also sehr schnell reagiert SuC dabei nicht grade...
:?

MightyKnife 27. April 2003 08:30

Noch was: Der Mod (und damit auch die aktuelle Orginalversion) hat immer noch diesen Sommerzeit-Bug... scheint das niemanden zu interessieren ?

Schade... :|

Xantor 27. April 2003 10:02

Zitat:

Zitat von [lovelace
]
zu Seite 3:
Zitat:

sprich ein Böser kann ihn nachher auch nix mehr rausbekommen
und wie! schau mal unter "man in the middle attack" nach ..

Hm was meinst du mit "man in the middle attack"? Steig da überhaupt nicht durch und die Suchfunktion im Forum hatt auch nix gefunden *g*

Usul 27. April 2003 12:45

Zitat:

Zitat von [lovelace
]
Zitat:

Warum hat der Mod eigentlich kein Community Sharing ?
finde ich schlimmer als manuelles kick/ban. Ist keine Gleichberechtigung mehr. Ich habe sogar vor, das eventuell zu unterwandern. So ne Art Hybrid in alle Communities.

Ist genau meine Meinung.

Zitat:

Tja, wenn Du öfter die Woche mal 'nen 6er im Lotto machst, dann ist ein zufällig doppelter userhash auch wahrscheinlicher. ;) Usul hats schon und noch besser erklärt...weiterlesen müßte ich können..
Danke für die Blumen ;-)

Usul 27. April 2003 12:56

Zitat:

Zitat von Xantor
Zitat:

Zitat von [lovelace
]
zu Seite 3:
Zitat:

sprich ein Böser kann ihn nachher auch nix mehr rausbekommen
und wie! schau mal unter "man in the middle attack" nach ..

Hm was meinst du mit "man in the middle attack"? Steig da überhaupt nicht durch und die Suchfunktion im Forum hatt auch nix gefunden *g*

Du solltest auch nicht die Suchfunktion im Forum, sondern zum Beispiel google benutzen ;-)

Trotzdem mal ne kurze Erklärung, was ne Man-in-the-middle Attacke (ich nenns im folgenden mal MitmA) ist (damit ich nicht einroste :-) ):Angenommen, Alice und Bob wollen sich über eine sichere Verbindung unterhalten. Um dies tun zu können, müssen sie sich vorher über die Verschlüsselung einig werden (z.B. über den verwendeten Schlüssel). Nachdem das getan ist, können sie sicher kommunizieren. Bei einer MitmA hängt sich der Angreifer vor dem Beginn der Kommunikation zwischen die beiden beiden Clients und gibt sich gegenüber Alice als Bob aus und gegenüber Bob als Alice. Beide denken nun sie kommunizieren mit dem jeweiligen gegenüber, dabei kommunizieren sie beide nur mit dem Angreifer. Jetzt handeln beide eine Verbindung aus (mit Schlüssel etc.), aber halt mit dem Angreifer. Der fungiert praktisch als eine Art Proxy/Relay/wasauchimmer. Wenn dann eine angeblich sichere Verbindung besteht, schickt Alice mit dem mit dem Angreifer vereinbarten Schlüssel verschlüsslte Daten an den Angreifer, der entschlüsselt die, liest sie und schickt sie mit dem Schlüssel von Bob verschlüsselt an diesen weiter -> Alice und Bob denken, sie kommunizieren sicher, dabei liest der Angreifer in der Mitte mit.

Falls das jetzt zu unverständlich ist, such in google ;-) Aber so ungefähr wirds wohl verständlich sein.

MxM 27. April 2003 13:40

schöne kurze Erklärung, wäre mir nicht besser eingefallen :-)

btw, sivka hat eine ANTI community option, was haltet ihr eigentlich von der.


jedesmal wenn ich ANTI lese, kommts mir kalt hoch

Anonymous 27. April 2003 13:55

anti-community.... gibts die nicht auch im mortillo???
also ich halt nix davon ...... aus welchem grund sollte man auch community-user ausgrenzen.
und wenn es schon sowas gibt, dann sollte sie in beide richtungen funktionieren, also wenn ich denen nichts geben will, dann darf ich andererseits auch nichts mehr von denen bekommen .....

@MightyKnife, was für einen sommerzeitbug???

cosmic girl 27. April 2003 14:10

Zitat:

Zitat von MightyKnife
Noch was: Der Mod (und damit auch die aktuelle Orginalversion) hat immer noch diesen Sommerzeit-Bug... scheint das niemanden zu interessieren ?

Schade... :|

Wie macht der sich denn nun einen Monat nach Umstellung auf Sommerzeit bemerkbar?
Bei mir hatte es in der Tat mit zwei Dateien über mehrere Tage das Problem gegeben, daß sie bei jedem Start von eMule neu gehasht wurden, aber seit die Dateien fertig sind, gibt's doch mit den neu hinzugefügten kein Problem mehr, oder doch?

Klar, so ein Bug sollte beseitigt werden - aber wenn die offiz. devs von dem Problem wissen und nichts dagegen unternehmen, läßt das zwei Rückschlüsse zu..

Xantor 27. April 2003 14:13

Danke Usul :) habs kapiert denk ich mal *g*.
Wär zwar für die Diebe mit einigem Aufwand verbunden,
aber ein Diebstahl der Hash ist immer noch möglich :(

Usul 27. April 2003 14:14

Also ich bin mir zwar nich 100%ig sicher, wie Anti-Community-Sharing funktioniert, aber ich könnte mir vorstellen, das es das richtige Gegenteil von Community ist. Community-Mitglieder bekommen einen kleinen Bonus in der Warteschlange, Anti-Community-Mitglieder einen kleinen Nachteil, also nix mit "Ausgrenzung", nur Behinderung/Dämpfung. Inwieweit das Sinn macht, keine Ahnung, ich bin eh gegen Community-Sharing.

Ich finde, man kann Community-Sharing viel besser ad absurdum führen, indem man Mitglied in jeder Community wird ;-)

Das beste war letztens eine Frage, welchen Namen man dort "am besten" reinschreibt. Klar, wenn jeder so vorgeht, hat irgendwann jeder das gleiche als Communitystring, dann können wir es auch gleich wieder sein lassen.

Ich finde es gut, das in Lovelace sowas nicht drin ist. Was ich nicht ganz verstehe, wieso ein "Member Lev. II" so eine Frage in diesem Thread aufwirft, wo sie eigentlich nichts oder nur sehr wenig zu suchen hat :twisted: Oder hat er auf keine Antwort gehofft? Eigentlich wäre das Thema einen eigenen Thread wert, finde ich, oder man müßte es dort diskutieren, wo es auch verwendet wird.

Anonymous 27. April 2003 14:19

Usul, ist sicher ein thema für nen eigenen thread.
aber wie gesagt, wenn es schon anti-community gibt, dann soll sie in beide richtung funktionieren.
aber schon richtig... irgendwann sind wir wohl soweit, das man es wieder bleiben lassen kann.

NaP 27. April 2003 14:21

credits der Community User werde um das vierfache erhöht,
credits der Anti-Community User werde um die hälfte reduziert.
es ist auch möglich den selben Community String in beiden feldern zu haben, dann werden die credits nur um das zweifache erhöht.

*sich mit fremden federn schmückt*

das was oben steht, hat sivka selbst geschrieben

MightyKnife 27. April 2003 18:49

Zitat:

Zitat von renegade
@MightyKnife, was für einen sommerzeitbug???

Haben anscheinend nicht viele Leute mitbekommen, als ich darmals die Mail geschrieben habe. Hier der Link:

http://www.emule-web.de/board/viewtopic.php?t=2869

MightyKnife 27. April 2003 18:58

Zitat:

Zitat von cosmic girl
Wie macht der sich denn nun einen Monat nach Umstellung auf Sommerzeit bemerkbar?

Jetzt: garnicht mehr. Aber in 5 Monaten, dann wieder !
Ich bin nur jetzt drauf gestossen, als ich mir den Quellcode der aktuellen Lovelace-Version mal angeschaut habe...
Zitat:

Zitat von cosmic girl
Bei mir hatte es in der Tat mit zwei Dateien über mehrere Tage das Problem gegeben, daß sie bei jedem Start von eMule neu gehasht wurden, aber seit die Dateien fertig sind, gibt's doch mit den neu hinzugefügten kein Problem mehr, oder doch?

Nur 2 Dateien ? Sei froh.
Bei mir hat er alle Dateien neu gehasht. Und das waren über 120 GB Daten. Das hat sich ganz schön hingezogen. Fand ich nicht sonderlich dolle, insbesondere weil dadurch alle Statistikdaten flöten waren incl. der Informationen, welche Dateien auf Release standen usw....
Ich hab das selber bei meiner Version korrigiert, da mir die Statistik wichtig war. Aber mal abgesehen davon wächst auch die known.met um das doppelte an (sofern man die neu gehashten Dateien hinterher nicht mit den alten wieder von Hand zusammenmischt)

Zitat:

Zitat von cosmic girl
Klar, so ein Bug sollte beseitigt werden - aber wenn die offiz. devs von dem Problem wissen und nichts dagegen unternehmen, läßt das zwei Rückschlüsse zu..

Tja, das ist die grosse Frage...
Ich hatte das hier ins Forum (genauer: ins Forum "EMule allgemein") gepostet. Lovelace hat's definitiv gelesen, aber ich hab keine Ahnung, ob irgend einer der offiziellen Entwickler Wind davon bekommen hat. Bei über 300 Treffern auf den Thread kann ich nur hoffen, dass es zu denen durchgedrungen ist...

MightyKnife 27. April 2003 19:03

Zitat:

Zitat von MightyKnife
(sofern man die neu gehashten Dateien hinterher nicht mit den alten wieder von Hand zusammenmischt)

Ohm, da seh ich grade, dass das bei der Lovelace-Version garnicht geht !

Bei meiner alten Morph-Version konnte ich das. Da konnte ich alle bekannten Dateien einblenden und Duplikate automatisch eliminieren lassen.
Wär vielleicht auch mal ne Idee für ne Erweiterung...

cosmic girl 27. April 2003 19:30

Zitat:

Zitat von MightyKnife
Nur 2 Dateien ? Sei froh.
Bei mir hat er alle Dateien neu gehasht. Und das waren über 120 GB Daten. Das hat sich ganz schön hingezogen. Fand ich nicht sonderlich dolle, insbesondere weil dadurch alle Statistikdaten flöten waren incl. der Informationen, welche Dateien auf Release standen usw....

Ich hatte damals den Vorlost Mod laufen und 8 aktive files im download und ca. 30 im share - er hat nur 5 von den 8 nach dem ersten Neustart von eMule nach der Zeitumstellung gehasht! Keine der im share befindlichen Dateien! Warum eMule nur 2 files bis zu ihrer Vollendung bei jedem Start erneut hashen musste, kann ich nicht nachvollziehen.

Zitat:

Zitat von MightyKnife
Ich hatte das hier ins Forum (genauer: ins Forum "EMule allgemein") gepostet. Lovelace hat's definitiv gelesen, aber ich hab keine Ahnung, ob irgend einer der offiziellen Entwickler Wind davon bekommen hat. Bei über 300 Treffern auf den Thread kann ich nur hoffen, dass es zu denen durchgedrungen ist...

Meinst du nicht vielleicht statt lovelace vorlost? Ich hatte ihn damals auf das Problem aufmerksam gemacht und er ist zumindest derjenige, der in deinem thread gepostet hat.

Im offiz. Board ist das Problem bekannt:
http://www.emule-project.net/board/i...ight+saving&s=

MightyKnife 28. April 2003 20:34

Zitat:

Zitat von cosmic girl
Meinst du nicht vielleicht statt lovelace vorlost? Ich hatte ihn damals auf das Problem aufmerksam gemacht und er ist zumindest derjenige, der in deinem thread gepostet hat.

Ups... Sorry :oops:

Hast recht :wink: Weiss gezz auch nicht, wie ich auf lovelace komme...

Dann muss ich mich aber sogar doppelt entschuldigen, dass ich diesen Post mit der Sommerzeit in den Lovelace-Thread gepackt hab. Da hatte er dann eigentlich nichts zu suchen...

cosmic girl 28. April 2003 21:00

[lovelace] wird's schon überleben. ;)
Ist ja auch mal interessant, da sich wohl noch keiner der offiz. devs an das Problem rangetraut hat..
Hast du mal bei dem von xrmb gestarteten thread (link habe ich weiter oben ja gepostet) deine code-vorschläge gepostet?


Davon abgesehen: was ist los Leute? Keine Feedbacks mehr?
Läuft der Mod so spitzenmässig, daß es nichts zu berichten gibt?
Das wäre doch auch mal einen post wert! ;)

Ich bin jedenfalls sehr zufrieden!

Ein feature request hätte ich aber doch:
manuelles Neuladen von Quellen - mit den neuen mules geht öfter mal der "Schnarchanfall" durch - d.h. eine Quelle ist vorhanden, auch willig zu geben und dann bleibt er bei 0.0 kB/s stehen.
Oder fragt gar nicht mehr nach, auch wenn man mit dem client direkt Kontakt hat (per eMule-chat) und sogar auf dem gleichen Server ist. (Heute erst erlebt)
Dann hilft nur noch file auf stop stellen und anschliessend wieder resumen.
Mit Quellen neu reinladen hab ich da meist auch recht gute Erfolge gehabt.

Usul 28. April 2003 21:05

Nochmal was zum Thema CPU-Last: ich hatte heute auch massive Probleme mit zu hoher Last, so das sich Emule kräftig verrechnet hat (150kb/s down bei Standard-DSL, man kennt das ja). Ich hatte etwa 25 Dateien im Download, Hardlimit auf 400, Anzahl der Quellen lag bei etwa 5200. Also hab ich das Hardlimit auf 200 gesenkt, die Anzahl der Quellen sank dadurch (das dauert aber schon eine Weile ;-)) auf 2700 ab, und die CPU-Last ist wieder in Ordnung. Nur so als Tipp, was die Betroffenen mal probieren können. Vielleicht läßt sich das Ergebnis auch auf anderem Wege erreichen, und jedes System verkraftet sicherlich andere Werte, aber vielleicht hilft die Beobachtung ja manchem.
Ansonsten wieder einer diesen Spitzenmods, die den Glauben an Emule aufrecht erhalten ;-)

Noch ein Feature-Request: Kann man nicht irgendwie die Quellen absolut angeben? Z.b. gebe ich an, das ich insgesamt max. 3000 Quellen haben will, so das bei 30 Dateien, die runtergeladen werden sollen, für jede Datei 100 Quellen zur Verfügung stehen und bei 15 Dateien für jede 200. Und dann am besten noch unter den Dateien dynamisch, also wenn eine Datei nur 20 Quellen hat statt den 100 maximal erlaubten, können die anderen die 80 übrigen mitverwenden. Aber die Zahl der absoluten Quellen bleibt gleich, damit gleicher Aufwand, und man muß das Hardlimit nicht mehr an die Anzahl der Dateien anpassen. Was haltet ihr davon?

Anonymous 28. April 2003 21:27

Usul, würd ich begrüßen den vorschlag. sowas hätt ich mir auch schon länger gewünscht.
aber wichtig sind beim lovelace erst mal die möglichkeit die nicht benötigten quellen zu droppen.
ich hab immer einige files, die sehr schlecht verbreitet sind und damit immer um die 200 quellen ohne benötigte teile pro file.

Usul 28. April 2003 21:34

Zitat:

Zitat von renegade
aber wichtig sind beim lovelace erst mal die möglichkeit die nicht benötigten quellen zu droppen.
ich hab immer einige files, die sehr schlecht verbreitet sind und damit immer um die 200 quellen ohne benötigte teile pro file.

*unterschreib*


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:23 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102