Bloß das kaum ein Esel diese Datei ausliest...(Plus Versionen nicht, offiziell ebenfalls nicht)
In der preferences.dat ist die ID gespeichert. Hatte man also irgendwie einen neuen Esel mit einer alten preferences.dat zum laufen bekommen so behält man die ID, also einfach immer nur die emule.exe in dem Ordner überschreiben.
Am besten ältere preferences.dat Dateien aufbewahren falls neuere irgendwann inkompatibel geworden sind...

Starte mal einen Esel in einem Ordner ohne die alten file und schau nach dem beenden ob eine userhash.dat erzeugt wurde, falls nicht wird sie auch nicht unterstützt...

[EDIT] Blödsinn habe gerade nachgesehen stimmt die Datei wird immer wieder erneuert also ist das im eMule0.22c Plus 4 tatsächlich eingebaut mit der userhash.dat....

Also immer schön kucken ob die Userhash.dat auch erneuert wird oder eine alte preferences.dat benutzen und danach die Preferences als erstes korrigieren.
[/EDIT]

Vorlost

Hi@all
Hab den mod 22c vorlost auch ma getestet und hab in 24 std 67 mb dl gehabt nicht grad der hit.Hat aber gut quellen gefunden.
Hab win 2000,router,high id!!
Was ist da los hab ich zur zeit nur noch.Test jetzt den Plus 24b 3a.

darf ich widersprechen? ;P

auch wenn die gekickten quellen wieder reinkommen (kann man kaum verhindern), ist trotzdem die CHANCE da, dass statt dessen andere quellen geladen werden.

also glaube ich, dass es nicht das bringt was man gerne haette, aber dennoch eine verbesserung.

muaB

Wie gesagt am besten wäre es noch wenn die max. Anzahl der erlaubten sources pro file erreicht ist, dann die NONEEDEDPARTS-Sources zu ersetzen.
Nun es scheint auch noch andere Probleme zu geben(jeder mod):
Wenn wir es nicht schaffen auf Grund von zu vielen Sources jede source nach 60min. erneut nach unserem Platz in der Warteliste zu fragen beginnen wir von neuem !!!

Und noch was zu "Entfernen von NO_NEEDED PARTS":
1. Wir fragen eine source nach parts die wir noch brauchen.
2. Keine da(noneededparts) also raus damit.
3. Diese source ist aber der Meinung das wir etwas haben könnten und nimmt uns als source auf.
4. Diese source fragt uns nun nach dieser Datei was dazu führt das wir diese source SOFORT wieder drinne haben.
5. Falls wir dann wirklich noch die Zeit haben sofort zu antworten - sprich Gegenfrage werden wir über kurz oder lang GEBANNT bei dieser source.
6. Weiterhin wird diese source noch alle paar minuten vom Server geladen, über stored-sources, na ja und von anderen usern die uns als source gerade vom server bekommen haben oder ebenfalls uns als source über storedsources einladen.

Dabei habe ich noch gar nicht von ExchangedSources geredet.

Um dieses wilde rein und raus zu unterbrechen ist es am besten ALLE noneededparts zu behalten, zumindest bis wir welche ersetzen wenn die max. Anzahl an sources pro File erreicht ist.

Warum wollt Ihr eigentlich immer das die "Noneededparts" verschwinden, das erzeugt nur unnötigen Traffic !!! und andere quellen können wir gar nicht mehr abfragen weil wir nur noch damit beschäftigt sind die "NoNeededParts" wieder zu kicken...ja und wie gesagt nach 60min. verlieren wir unseren Platz in der Warteliste !!!

Vorlost...

Könnte es sein, das genau sowas in der neuesten Tarod-Mod implementiert ist?

Nun ich glaube das heißt das die "NONEEDED" rauskommen wenn neue sources kommen -> wird aber wohl so sein das jeweils alle "NONEEDED" einer Datei raus gehen.
Da die sources aber immer nacheinander eingetragen werden könnte man auch immer nacheinander davor 1 noneeded löschen WENN die sources pro file auf max. sind.

hallo pinki,diene links hauen nicht hin,wo kan man den eMule 0.22c Plus 4 - Vorlost.1c noch downloaden oder bekommen ???

gar nicht im Moment(außer über dem eDonkey-Link), das Downloadkontingent für diesen Monat bei meinem Provider ist erschöpt.

Scheint extrem beliebt zu sein der MOD, könnt euch ja mal ausrechnen wie oft man die binary hätte runterladen können.

Kann vielleicht jemand etwas Webspace zur Verfügung stellen ?

Ich arbeite gerade daran den Mod zu einer Version 1d zu machen.
Ich habe Aufgrund einer Anmerkung zu einer meiner Features von einem Beta-Tester:skynetman festgestellt das jeder eMule folgendes Problem hat:

Alle 60minuten müssen wir unsere Anforderung nach einer Datei bei einem client wiederholen ansonsten wird man aus seiner Uploadwarteschleife gekickt.
Dadurch das eMule viele Quellen finden kann und auch dort anfragt kommt es regelmäßig dazu das diese Zeit nicht eingehalten werden kann.
Die 1d so wie sie jetzt ist erlaubt eine doppelt so hohe Nachfragezeit für andere eMule´s(also zwischen zwei 1d eMules fast kein Problem mehr), die erweiterte Nachfragezeit(um mehr eMules als normal abfragen zu können) wurde verändert um vor Ablauf der 60min. die Anfrage zu ermöglichen -> leider reicht das aber immer noch nicht aus(arbeite zur Zeit daran, anstatt das neue Menu(secret) von DonGato für meinen MOD zu portieren).
Nun es gibt somit auch eine neue Fehlermeldung falls man den Platz in einer Warteschleife verliert.
Die Anzeige welcher Block in welchem Part gerade geladen wird verbraucht nun weniger CPU-Power.

Vorlost

HIER gibts den auch noch, meine kleine persönliche Sammlung an eMules.

Bloß Schade das der Link auf einen anderen MOD zeigt...

Vorlost

Danke für den Hinweis, ist geändert :wink:

übrigens danke Winki. Ich persönliche bevorzuge die Oxygen Varianten, wegen AMUC und Server-Rating. Die BadWolf Variation habe ich nirgends anders gefunden. Ich denke es werden sich jetzt einige User freuen. Just in diesem Augenblick saugen 2 Leute mit 13 K und einer mit 6 K bei mir.

und über hohe uploadraten freue ich mich persönlich. logisch entweder bediene ich 15 Leute mit 2 K ...oder eben eine Handvoll mit hohen Raten.
Jetzt bemerken nur einige Leute, dass da jemand mit etwas mehr ihnen was sendet. :-P In jedem Falle haben alle in beiden Varianten davon, ich persönlich gehe aber davon aus, wenn die Chunks bei einer einzelnen Person schneller fertig sind, kann er den kompletten Chunk viel eher weiter teilen. Er lädt dann diesen Chunk mit hoher Wahrscheinlichkeit mit 2K Stückchen weiter... und insgesammt kommt man insgesamt gesehen nach Kurzer Zeit sehr schnell wieder zu der gleichen Userzahl, die den Chunk bekommt. Das Schneeballprinzip verteilt sich nur eben schneller, wenn zwischendrin einzelne Uploader die Datei schnell komplett weitergeben.

Ist meine persönliche Philosophie und anscheinend auch die von BadWolf und ich danke dir für den Link, weil ich woanders noch nicht gefunden habe. :-)

Wichtig ist ja nur, dass der Upload maximal ist.

danke winki für deinen wink :oops:

@plottera0: bitte, gern geschehen, null Problemo :wink:

@MxM: Ich teile Deine Philosophie bezüglich Oxygen. Vielleicht hast Du in einem anderen Thread gesehen, dass ich genau das bei andern Mods bemängle, die teilweise sehr vielen Uploadslots. Ich bin eben der Meinung, dass es vorteilhafter ist, mit 2*6kb hochzuladen als mit 4*3 oder gar 6*2, deshalb benutze ich auch gern den Oxygen-Mod. Er hat leider gegenüber Tarod, DeltaHF, Morph und Sivka einen entscheidenden Nachteil: da er auf der Plus-Version basiert, findet er grob über den Daumen gepeilt nur ca. 1 Drittel der Quellen, die die o.g. Mods finden. Das ist der Nachteil der Plus-Version (die ich aber ansonsten auch gut finde).

Svika ? wo finde ich den denn, oder infos über den Mod ?

HIER findest Du den unter anderem.
Die Originalseite lautet wohl http://www.sivka.de/, nur steht da glaub ich net viel

Donge :lol: :) :D

Na und ?

Was bringt das schon wenn die MODS nicht in der Lage sind die große Menge an sources zu verarbeiten ???
Andererseits werden euch auch weniger sources angezeigt wenn ein MOD in der Lage ist viele sources zu verarbeiten da die ungültigen sources bereits rausgeschmissen wurden...
Also nicht wundern wenn es so aussieht als wenn dieser MOD weniger sources findet, er wird in Zukunft noch weniger finden... :wink:
Dafür habt Ihr dann einen noch besseren Download.
Nun stellt sich also die Frage was Ihr lieber sehen würdet:
Einen MOD der viele sources anzeigt oder einen MOD der schneller lädt als alles andere was bisher da war(in Planung).
Dieser MOD und spätere zeigen am Anfang tatsächlich weniger Quellen und er lädt auch langsamer am Anfang. Nach 2 spätestens 4 Stunden hat er aber alles aufgeholt und wird schneller.
Weiterhin sollte man einen MOD nicht daran messen wie viel er über Nacht geladen hat(kann sich zu stark nach dem Uploadraten einiger sources ändern) sonder viel mehr wie viele Downloads gerade laufen und von wie vielen Quellen man gerade Download bekommt !!!(Naja und natürlich wie schnell seltene Sachen fertig werden...)
Sacht mal euren Ratio, meiner ist nach 15h 1:1.36

Vorlost...

hi vorlost!

erstmal danke für deine arbeit...habe deinen mod ca 72h getestet anstatt der üblichen 30...ist schon ein paar tage her...ich habe auch sehr lange den 22c3d von plus benutzt mit ca 50-60kb down entspricht einer ratio von 1:2...die werte deines mods sind ungefähr genauso...

thema quellen (meine meinung):

es macht schon einen unterschied wie viele quellen ein mod findet, nicht bei den mainstreamfiles, da kriege ich wahrscheinlich mit dem esel oder OV ähnliche raten (wäre mal einen test wert), sondern bei files mit <25 quellen.
beispiel: ich hatte ein file bei dem immer nur 1-2 volle quellen angezeigt wurden, nach dem umstieg auf deltahf ganze 6...und da ist schon ein unterschied ob mir ein mod 2 oder 6 volle quellen anzeigt.

sicher bin ich ein einzelfall, ich habe auch schon mehrere mods getestet, wenige laufen wirklich gut.
tarod=crash,
plus(v24)=schlechter ul,
23er codebase allgemein= schlechter dl, hohe cpu-auslastung
(ausnahme: rectencle=niedrige cpu, da angepasst, fand ich eine gute idee genauso wie das connection-prefetching)

morph findet viele quellen und ich hab einen ul:dl von 1:2,5

deltahf ist immer noch mein absoluter favorit 1:3 manchmal 1:4, und ich warte nicht lange bis der erste dl startet...

meiner ansicht nach sind da schon unterschiede...die mit dem finden von quellen zusammenhängen...

...das alles ist natürlich rein subjektiv...

...so nun habe ich meinen senf dazugegeben...

mfg
NJ

nach 22 Stunden UL:DL 1.34:1
bei 28,6kb/s UL pro Schnitt (32 max.)
und ganz ehrlich...das ist der beste Uploadschnitt nach einem Tag.


Version e+ 24b2 oxygen3 badwolf

@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.

moin moin,

wie schon gesagt, da hilft nicht algebra, das ist wahrscheinlichkeitsrechnung (hab ich zumindestens in meinem informatikstudium so gelernt).
erst wenn der ansatz stimmt hilft algebra weiter

wenn es dir gelingt, dass mal einfach so auszurechnen, nur zu, ich fühle mich dazu nicht in der lage (mit der annahme, dass sich alle meine phänomene auf beide modelle immer gleich auswirken, fällst du bei der berechnung aber auf die nase).

das war auch nicht so gemeint. ich kann bei konstantem upload die sache so einstellen, dass leute von bestimmten dateien mehr oder weniger bekommen.

also beim release einer datei lieber jemand mit 2 kB upload, der begriffen hat worum es geht, als jemand mit 14 der keinen check hat.

grüsse

ok. un jetzt ... wo du zugegeben hast ,dass du es nicht berechnen kannst... jetzt hätte ich gern die Erklärung dafür... wie du darauf kommst ... dass 16x 2kb besser ist.



das ein 2kb upload viel länger dauert ist doch klar oder ? und das es störungen gibt wirst du auch nicht abstreiten... also wo ist deine logik ....die dazu führt...dass dieser längerdauernde ...störanfällige (unterbrechungsanfällig... ) Variation besser ist ?

ich gehe nach wie vor nicht von dem Modell aus, dass ALLE das so machen sollen... sondern dass es zwischendrin einzelne gibt... Die Effektivität wird sicher erreicht, wenn es von beidem genug gibt.


Meine Meinung für ein einzelnes Release ist nach wie vor...dass der Releaser möglichst Einzel-Slotabfertigung machen sollte. Diejenigen die es weitersharen, nach Möglichkeit dann Viel-Slot Variante.



Quasi wie ein Wasserturm im Netz der Wasserversorgung, der den Druck auf das ganze erhöht.




PS: für Deine LKW's mit unterschwelliger Blödheits-Erklärung könntest Du Dich auf jeden Fall entschuldigen, dann wären wir 3 Schritte weiter.

moin moin,

nur kurz, da ich gleich was tun muss.

wenn irgendwo der eindruck entstanden ist, das ich dich für blöd halte kann ich mich dafür entschuldigen. kein problem.
ich halte dich in diesem forum für einen der wenigen, mit denen man solche fragen überhaupt nur erörtern kann.

das lkw modell war für mich nur eine darstellung meines denkansatzes in anderen zusammenhängen.

mein modell beruht auf der annahme, dass alle ähnliche situationen vorweisen (d.h. download und upload von dateien)

wenn du z.b. nur eine datei releasen willst und volle pulle an einen abgibts kann dein ansatz vielleicht sogar besser sein, wenn der dem du die datei gibst auch begreift was er zu tun hat, wenn nicht geht es in die hose.

die wahrscheinlichkeit, dass bei meinen 10 einer dabei ist, der begreift worum es geht ist aber höher.

ansonsten hätten wir nicht so schöne beispiele wie mit einer version der türme, wo es 200 dateien mit erstem und letzten chunk gab (und wahrscheinlich noch gibt) und 7 fertige und nach tagen sieht die situation immer noch so aus.

da ich es aber selbst aus guten wahrscheinlichkeits berechnungen kenne, das die unbekannten dazu führen können, das bei einem ergebnis meins besser wäre und bei dem anderen deins, hilft nur der versuchsaufbau

womit wir nach eine unbekannte ins spiel bringen, wieviele emule user, machen sich darüber gedanken und wieviele begreifen was abläuft.

grüsse und schönen sonntag
und entschuldigung dafür, dass ich dich mit meinen ironischen beitragen genervt habe (werde in den nächsten ein auge drauf haben)

wobei mich solche aussagen natürlich dazu reizen mal ein wenig in dem busch zu stochern, da du mit solchen sätzen genau das machst, was du mir vorwirfst, nämlich die anderen für blöd erklären. daher auch der balken. 8)

durch weniger slots habe ich persönlich übrigens weniger traffic und auch weniger last.



und ich habe nochwas überprüft. in meiner statstik sind meine "my own rate at other client" oder wie auch immer es jetzt heißt ... natürlich weit höher als normal.


angenommen ich share eine datei die sich allgemein im umlauf befindet. die vollständigen dateien jedoch sind rar gesät .... ich habe festgestellt ,dass ich bei denen denen ich sende ...auch ziemlich schnell an empfang komme ...logisch ...wenn ich bei 10-12kb oder mehr an den sende..krieg ich ratings bei 900 rum ...gerade nach mehreren MB (hier hast du recht, wenn er den komplett hat den file ...vielleicht löscht er ihn schnell aus dem verzeichnis) ...aber die chance...dass ich ein paar rare teilchen mitnehme ..ist gerade nach diversen patches von LOAD RARE PARTS ist sehr hoch.... und er löscht ihn ja erst...wenn er ihn komplett hat...


ich persönlich lösche den ja nicht...da ich ihn für einen festen zeitraum X auf die besagte weise weitershare... ...meine netzwerkstatistik auf den einzelnen files bestätigt mir im übrigen bis jetzt meine annahme ...dass der file auf jeden fall nicht verloren geht deswegen weil er schneller woanders ist ...und evtl. eher gelöscht wird.... (ich sprach ja nämlich auch von chunks und nicht von files) aber ich behalte das im moment weiter sehr im auge.

Gleich kommt was,
hier noch einmal ein Auszug eines meiner Postings: