@netzjunkie,

man könnte auch einen anderen MOD der mehr quellen findet 15min. vor meinem laufen lassen(die quellen werden ja gespeichert) und danach meinen.
Ich könnte auch mal nachsehen wie deltahf mehr quellen findet, wäre natürlich schön wenn für seltene Dateien mehr Quellen gefunden werden.
Falls jemand einen Patch oder eine andere Lösung hat bitte schreiben.
Werde bald den Code für die Serverkommunikation aus einen der neueren MODS versuchen zu übernehmen, vielleicht reicht das dann schon(und evtl. aussagekräfitgere Server-Fehlermeldungen).

Bitte sage mir welche Version genau von Deltahf diesen Vorteil hat & mehr Quellen für seltene Dateien bekommt. Wie verhält sich das mit dem Quellenfinden(seltene Files) bei den neueren Plus Versionen(immer angeben).
Wie verhält sich das Quellenfinden bei Tarods aktuellen MODS, er hat ja das komplette eDonkey-Protokoll eingebaut...

Vorlost...

moin moin,

die version mit mehr quellen beim suchen ist bei mir
24b morph v3a und 24b v1 deltahf dsl

wie es mit der morph 4 ist weiss ich nicht, da ich nach dem testlauf ohne suchen wieder umgestiegen bin (irgendwie würde da einiges mit neuen funktionen verschlimmbessert, so dasss der download schlechter wurde)

grüsse

ich benutzte 24b v1a deltahf powerup 10-ul-slots

winki2099 und MxM werden wahrscheinlich nicht so begeistert sein, mache damit aber einen guten ul bzw. dl...

was mich wirklich mal interresieren würde ist woher dieser hohe overhead kommt, den ich mit der 0.25a original angezeigt bekommen habe...6-10kb...uppe ich mit 30, uppe ich in wirklichkeit mit 40, nachts mit 40, also mit 50...ich habe keine übertriebenen einstellungen oder so, hab sie in den letzten tagen sogar nach unten korrigiert...150 hard limit...16 files...ich finde schon das 6-10kb etwas zu viel ist, wenn diese anzeige stimmt...


dieses gefühl habe ich auch, je mehr funktionen ein mod hat desto niedriger mein dl und ul, scheint mir irgendwie so zu sein, das er alles mögliche macht nur nicht das was er soll nämlich uppen und saugen...paradebeispiel plus24...ein haufen funktionen aber cpu-auslastung hoch, ul schlecht und dl mittelprächtig...übermoddet würde ich das nennen...ein wunderbare wortkonstruktion aber leider zutreffend...ich sehe den muli nicht als vollintegriertes entertainmentsystem sondern als filesharing-client...vielleicht ist das mein fehler...

mfg
NJ

Ich sprach natürlich von brauchbaren Quellen. Ich stelle meine Mods so ein: Drop no needed Sources, Max Quellen 100. Nach spätestens einer Stunde hat er in der Regel die 99 brauchbaren Quellen gefunden und er muss net weitersuchen, und natürlich sind das auch, aus meiner Sicht, keine grossen Mengen.
In dem Punkt hast Du natürlich Recht. Deshalb hab ich auch noch nie geschrieben "lädt besser, höherer Download", denn bis jetzt bin ich mit den entsprechenden Files noch mit jedem Mod an die Obergrenze gekommen.
Ich beurteile einen Mod nach anderen Kriterien, nie nach dem Download.

ich weiß warum ihr so gut saugt. *lach


ihr seid bestimmt die beiden die in meinen uploadslots gerade mit jeweils 15,9 UL drin hängen *lach


scherz beiseite ;-)


aber die chunks sind garantiert schon in den nächsten minuten zu den nächsten unterwegs



und zu der POWER Version mit den 10 UL Slots.... sicher dass ist der andere Weg... und wenn alle gleichzeitig und immer online bleiben würden, würde das auch funktionieren... aber die meisten werden irgendwo mitten in der übertragung unterbrochen... und dann steht er wieder hinten an ...und hat fast nichts bekommen was er weitergeben kann... und gerade bei raren files finde ich die many-slot less UL taktik für völlig falsch...

also wenn dein POWER muli in einer kette steht von files ...wo auch UL Raten von eben mehr als 10 mit drin sind ...ist das völlig ok

dein ganzes konzept geht nur bei massenfiles auf... nicht bei raren files... und schon überhaupt nicht ,wenn du selbst releasen willst.


übrigens dass mp3's und einzelne files auf donkey nicht funktionieren ...liegt u.a. auch an dieser philosophie ... und wenn die mp3 sharer mit hier wären ... und auch nur "aus versehen" nebenbei 2-3 grosse files mit abarbeiten sind wir auch mindestnes ein paar upload .und somit downloadslots mehr ....

unabhängig von den mp3ern aber... und das ist ja eine diskussion für sich ...schliesslich sind wir im netzwerk der grossen files .... halte ich eben auch für grosse files eine hohe übertragungsgeschwindigkeit für wichtig

und DAS funktioniert nicht, wenn mir ein oxygen oder ein e+ oder sonstwas einen MAX Slot von 100 aufzwingt... das geht einfach nicht.

auch der uploadthrottle macht nur bei wenigen slots Sinn... aber das ist meine Einstellung... Upload Throttle finde ich persönlich sowieso den größten Humbug ... bei mir werden komplette Chunks geladen...und wenn er einen fertig hat und nach im Slot ist ... dann soll er auch den nächsten Chunk kriegen.. .bei mir kriegt er innerhalb von einer Stunde wenigstens auch mal nen kompletten File fertig und kann ihn direkt weitersharen.

moin moim mxm,

womit wir wieder bei den lkws sind

stufe 1:
wenn ich zwei slots aufhabe bekommen 2 leute in kurzer zeit viele daten und können die wenn fertig mit dem chunk, wieder den nächsten anbieten,

wenn ich 10 slots aufmache bekommen 10 leute wenig daten und können die wieder anbieten.

d.h. in stufe 2 ist das angebot an quellen schon 5 mal höher

stufe 2:


2 leute mit 2 slots macht am ende 4 quellen

10 leute mit 10 slots macht am ende 100 quellen

in stufe 3 ist das angebot schon 25mal höher

usw das eine ist 2 hoch n das andere 10 hoch n

der einzelne bekommt zwar weniger, durch die grosse verteilung kommt die sache aber in schwung.


womit erwiesen ist, das gerade bei raren files die many slots genau richtig ist, wenn viele leute sie wollen (z.b. release), wenn nur wenig nachfragen sind mag dein system hinkommen.

grüsse

Lieber Hein,


ich habe dir für mein Prinzip mal eine vereinfachte Grafik gebaut.
Einfach um den Irrglauben auch mal mathematisch zu beseitigen

Ganz Links = Zeit in Sekunden
Spalte A: Anzahl User mit komplettem Chunk

http://www.maxmarlow.de/schneeball.jpg

auf der linken seite befinde ich mich. ich bin die Buchstaben B-E.
Aufgabe ist es einen Chunk zu senden der eine Größe von 32 kilobyte hat.
es ist kein File sondern ein bereits ein Chunk.
Rot ist das Zeichen wenn ein Chunk fertig gesendet wurde.

links habe ich 8 Farben bedient ... damit du also sieht welche Farben ich bedient habe (Farbe = User) nach rechts hin siehst du wie diese nun anfangen Chunks zu senden.

Ich sende mit 32 kb/s und zwar maximalen Transer an einen User.
Sprich 1 User ist nach 1 Sekunde abgefertigt.
Die bedienten User haben alle Ihren Upload auf 8kb/s eingestellt. sind somit mit dem 32 kb/block nach genau 4 Sekunden fertiggestellt

ein viereck (zumindest links vom dünnen balken) = 1 x8 kb - block

In 33 Sekunden habe ich also selbst 33 User abgefertigt
Das wird auch so bleiben, wenn ich in 2k brocken an 16 user sende. dazu aber gleich mehr.

die von den jeweiligen Farben fertiggestellten Chunks an wieder andere werden rechts von dem grauen dünnen Senkrechtbalken dargestellt.

obendrüber die Kategorie hellgrau, grau , dunkelgrau... die wiederum die von diesen fertiggestellten sind.


das prinzip ist überproportional soviel ist dir klar.
die zahlen die links senkrecht verlaufen sind genau die user, die den chunk zum weiterverteilen haben.



jetzt dein beispiel hier in vereinfachter form
die anderen user werden immernoch den chunk in 8 sekunden fertigstellen

Links wieder Zeit in Sekunden


01-1
02-1
03-1
04-1
05-1
06-1
07-1
08-1
09-1
10-1
11-1
12-1
13-1
14-1
15-1
16-17 (+16 User fertiggestellt a 2 kb/s)
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 32+64 (+16 User fertiggestellt a 2 kb/s) +64 [16x4] User fertiggestellt)

wie du siehst HeinBloed, du hast nach 32 Sekunden 99 User ... auf deinem Prinzip


nach meinem Prinzip sind es 144 User also schon 45

beide Systeme werden sich sehr wohl überproportional entwickeln.
Mein Prinzip jedoch basierend auf seiner Zahl, dein Prinzip auf seiner.


wir sind nach 32 Sekunden schon im Unterschied von ca 30%

Nun sag mir , ob du immernoch sicher bist, das 16x2 kb besser ist ...als 1x32


das ist pure Mathematik... mehr nicht. Und ich weiß einfach, dass fast alle eine Philosophie verbreiten wie Du, die mathematisch einfach inkorrekt ist.






Schlussatz: wenn ich 32 kilobyte share, share ich 32 kilobyte. das wird nicht mehr oder weniger. WENN das Netzwerk überhaupt etwas davon hat, dass es sich schneller verteilt, dann NUR ... wenn die Chunks schneller komplettisiert sind.. .. . also möglichst so schnell wie möglich einen Chunk weitergegeben. und das geht nur, wenn der chunk also in KÜRZERER zeit zum weiterverteilen vorhanden ist ... SPRICH UPLOAD KOMPLETT AN EINE PERSON.


ich hoffe, dass das jetzt mal irgendwie klar wird.
und upload throttle ist deswegen der letzte mist, weil er einen Upload unterbricht. scheißegal auf welchem system, upload throtttle ist der letzte mist

prinzipiell eigentlich in meinen augen auch quellenaustausch, der nicht nur die CPU belastet ..sondern auch den netzwerktraffic... gottseidank befindet sich dieser Traffic aber im Bit/Byte Bereich und ist damit für alle Verbindungsarten unrelevant. Möglich, dass er tatsächlich mir schneller mitgeteilt hat wo welche Quellen sind als der Server... Preis/Leistung (CPU-Last / Effekt) finde ich in dem Zusammenhang aber nicht wirklich erwähnenswert...

ich hoffe ein Serverbetreiber belehrt mich hier eines besseren.


Ich habe erst noch überlegt ob ich ein praktisches Beispiel mit einer Feuerlöschkette projiziere, das wird aber zu kompliziert...



mfg
Max

na los HeinBloed,

ein bißchen Blöße muß schon sein.




und noch ne kleine Frage... (zum piesacken wegen der LKW's)
angenommen alle 30 Minuten würde eine Verbindung getrennt. welches System wäre anfälliger dafür, durch das Verlieren von Chunks so massiv Zeit zu verlieren, das sich in der Proportionierung nicht schließbare Lücken ergeben?

Deines oder Meines ?

moin moin mxm,

deine berechnung mag zwar richtig sein (hab nicht weiter nachgerechnet), aber da der ansatz leider falsch ist, ist es relativ unwahrscheinlich, dass das ergebnis richtig ist.
nach meiner meinung kommen wir unserem problem aber eher mit statistik und wahrscheinlichkeit näher als mit algebra.

du gehst davon aus, dass die datei wenn 32kB da sind, sofort an den nächsten weitergegeben wird (Feuerlöschkette).

so funktioniert emule aber nicht.
alle 10 minuten wird nachgefragt ob jemand was hat.

bedeutet das statitisch gesehen nach 5 minuten die erste abfrage kommt. da hast du den ersten fertig, dere zweite ist grad am laden, also werden zwei user gefunden, die was haben. die landen dann bei den anderen usern, nach ner zeit x fangen die an zu saugen.

wenn nach weiteren 10 minuten die nächste abfrage kommt hast du 3 fertig und einen im sinn, macht 2 weitere.

vorausgesetzt wird, das du nur einen chunk pro user abgibts, bei deinem hohen upload kann es aber passieren, dass du sogar 3 oder 4 abgibst, das bedeutet, beim zweiten nachfragen ist es immer noch einer.

bei meinen 10 slots gibt es nach 5 minuten schon mal 10 user die was haben, die wiederum nach der zeit x andere beliefern.

jetzt kommt die zweite unbekannte ins spiel y, das ist die zeit, nach der neue in den slot kommen. wechselst du 10 x schneller als ich, damit du die gleiche userzahl erreichst?

das ist nach meiner meinung (bekannt aus dem lkw thread) falsch, da die fertigen user, wessentlich weniger am verteilen beteiligt sind als die nichtfertigen (ul/dl modifier).
jeder mit meinen fitzelchen bringt für den download mehr als dein fertiger
SPRICH UPLOAD AN VIELE PERSONEN.

es geht nicht um schneller sondern darum das die server damit überlastet sind, weil die wenigen rechner dann alle user verwalten müssten, während deiner doch schon nicht mit den paar für dich relevanten klarkommt und überlastet ist.

Was aber siehst du den Splitter, der in deines Bruders Auge ist, den Balken aber in deinem Auge nimmst du nicht wahr. (Matthäus 7:1-5)


grüsse euer seelsorger heinbloed

herrje bist du kompliziert.


der ganze mist den du da oben von kommunikation aufschreibst gilt doch für beide.


und dann hast du was übersehen. ich rede nicht von FILES ...sondern von CHUNKS


sprich diesen einzelnen teilchen. genau die von denen du redest ,dass die beim austausch wichtig sind. ich hab nirgends geschrieben, dass ich komplette 700 MB Files mit 32kb/s innerhalb einer sekunde hochladen kann


und überhaupt wie du von meiner berechnung von 1 sekunde auf solche dimensionen schliesst. Der Rest deines Postings ist irgendwie nur blabla... nichtmal die Mühe zum Nachrechnen hast du dir gemacht.


Also alles was den Austausch der Chunks verhindert , wird bei allen beiden versionen gleich verhindert. egal ob deine oder meine.


du messias... und hiermiet verweise ich dich nochmals auf die grafik und mein vorposting. es würde echt sinn machen, wenn du versuchst zu verstehen wovon du redest... bevor du deine albernen LKW's und deine Balken herausholst.

fitzelchen = chunk ...und dann vergleiche nochmal mein vorposting und deinen thread. du mußt mal komplett lesen.

nö fitzelchen sind teile von chunks bei mir.

das mit dem SPRICH UPLOAD KOMPLETT AN EINE PERSON.

wenn das sich auf die chunks bezieht habe ich es missgedeutet.

also müssten wir jetzt einen versuchsaufbau machen um herauszubekommen, wer recht hat.

nur deine aufstellung mit den sekunden wird nur bei der feuerwehrkette interessant und nicht bei emule, das prinzip wie du es dargestellt hast habe ich schon begriffen.

wobei um das ganze meinetwegen auch ohne versuchsaufbau zu beenden:

wenn die user ihre dateien nicht freigeben, weil sie eh nur ihren download im auge haben, dann ist es eh egal ob 1 slot oder 100, sie geben einfach nichts raus.

grüsse

das wars was ich vorhin meinte . solcherlei schwierigkeiten hast du woh lbei beiden varianten..und bei denen mit lowupload dürfte mehr zeit verloren gehen... das war ja das was ich sagte.

alle schwierigkeiten die du ansprichst würden sich auf beide varianten gleichstark beziehen...und somit bleibt unterm strich immernoch ein gleiches verhältnis übrig.

entschuldigung!!!

ich wollte hier keine grundsatzdiskussion auslösen...
...lesen musste ich es trotzdem...leider war mathe bzw. logisches denken nie meine starke seite...

mein fazit (sollte ich falsch liegen, erklärt es mir bitte, aber möglichst einfach):

MxM geht von der optimalen situation aus, das jeder chunk nachdem er ihn weitergegeben hat, sofort wieder weitergegeben wird...und so weiter...die sicherlich stimmen würde wenn alle nur die von MxM weitergegebenen files saugen würden...

...nachdem aber nicht alle nur diese files saugen, und diese fertigen chunks normalerweise nicht sofort weitergeben, sondern auch chunks von anderen files...geht diese optimalrechnung nicht auf....

...auf der anderen seite sind 10-ul-slots die länger brauchen, aber die wahrscheinlichkeit höher ist, das von diesen 10 leuten jemand sofort wieder etwas weitergibt...und so weiter...

...so dass zu viele variablen in diesen rechnungen sind und somit nicht aufgelöst werden können...wenn jetzt jemand mit stochastik anfängt, höre ich auf zu lesen...

also rausfinden wer jetzt recht hat, kann man nicht, und somit ist es egal...

mfg
NJ

ach Leuuuuuuuute...


ich muß zum berechnen Optimalsituationen benutzen.
Wenn es Dinge gibt wie ...die Leute laden auch andere Chunks... oder Verzögerung durch Slots etc...

dann beeinflußt das BEIDE...also sowohl den mit niedrigem UL und vielen slots, als auch den mit wenig Slots und viel UL

Fakt ist .... und mein Herzinfarktstatus, wenn ich das lese ist schon so weit, dass ich das gleich auch nochmal berechne.... das durch diese Unterbrechungen...diese Möglichen... sogar viel eher die "viele Slots, wenig UL" Strategie angreifbarer ist...

aber ich werde euch jetzt alle in eurem sakralen Chor euer heiliges Liedchen von eurer Philosophie singen lassen... auch wenn das mathematischer Voll-Blödfug ist...

aber ganz richtig Hein.... wenn die Leute sich entscheiden nicht 14,12,10 ...und auch nicht 8 kb upzuloaden.... dann ist es sowieso fast nurnoch wurscht


bei 2kb ...ist nachher sowieso auf beiden Einstellungen nur ein Slot offen.