|
soul^keeper |
  |
Administrateur
Déconnecté
Niveau : 5
N° de Membre :
1
Ancienneté : 100%
Participation : 19%
Inscription: 22 Feb 2002
Localisation: La Défense
Age: 48
Messages: 16623
Sujets Lancés : 2412
|
Citation:
Message provenant de GENIUS
C valable que si on veut D/L à 60 mais comme personne n'est en mesure physique de le faire... je vois pas ce que cela pénalise...
|
C'est là que je ne te suis pas... Internet ne se résume pas à eDonkey il me semble... si eDonkey télécharge à 20Ko/s chez moi, je suis bien content quand je vais consulter mon compte en banque sur internet de recevoir les pages html à 40Ko/s et non à 10Ko/s parce que mon upload edonkey est à 16 ... donc même si c'est à chaque fois le temps de 1 ou 2 secondes quand je clique sur un lien, j'aime que ce soit instantané plutôt que ça prenne 10 secondes.... de ce point de vue là, je refuse d'attribuer 100% de ressource à UN PROGRAMME et s'empêcher de faire une quelconque autre activité internet avec un confort décent, en rapport avec le prix d'abonnement que je paie....
Citation:
Message provenant de GENIUS
ça reste que des valeurs théoriques.. C comme si je te dis que ton fai t'envois des requetes pour pinger ta connection... ( wanadoo par exemple) et ça n'empeche pas que tu peux atteindre 64 ( le max en valeur) C le meme principe que les accusés de réception....
|
Alors ça c'est complètement faux, en PPPoE on est en état "perpetuellement connecté". Il n'y a pas de ping... dès que tu branches ton modem PPPoE à la ligne téléphonique t'es connecté au DSLAM... c'est pas comme le PPTP où tu dois ouvrir un VPN et t'authentifier.
De plus, en supposant que le DSLAM (et non le provider!) envoie à tous ses clients DSL des pings à interval régulier, ce n'est aucunement comparable aux accusés de réception d'un transfert soutenu à 60Ko/s. un ping et un pong requierent très peu de données, souvent 68 octets suffisent.... alors même si tu as 68 octets à échanger une fois toutes les 10mn, effectivement ça n'influence pas du tout ta connexion....
Citation:
Message provenant de GENIUS
prenons le cas d'un autre P2P....> j'ai D/L 68 réels > j'ai donc dépassé ma valeur max.. > c'était pas un bug.. et en UP les parametres etaient normaux > je n'avais touché à rien..
|
Comment sais-tu que tu as téléchargé à 68Ko/s réels? quels ont été tes outils pour le mesurer de manière fiable et indiscutable? Même si tes paramétrages d'upload n'étaient pas limités lors de ce test, à combien tu uploadais à ce moment là ??? (t'auras beau proposer un upload illimité, si y'av personne qui téléchargeait chez toi à ce moment là, logique que tu n'ai pas été pénalisé)
Citation:
Message provenant de GENIUS
C comme ces jolies thèses sur l'ID > En quoi cela aide -t-il le D/L aujourd'hui d'avoir un ID de 10 chiffres car , qu'il soit élevé ou bas ( cela ne nous permet pas d'échapper à une attente chez la personne).. .. il ne sert qu'a ne pas se faire éjecter par nos chers serveurs FR...
|
Euh... faudrait que tu jette un oeil à la FAQ je crois... parce qu'à mon avis tu as mal compris le fonctionnement des transferts selon l'ID..... En résumé, avec un HighID tu peux télécharger chez tout le monde, alors qu'avec un LowID, tu te prives de downloader et uploader vers les autres LowID, donc si on s'en tient à ta façon de raisonner, c'est autant de bande passante potentielle gaspillée, puisque les clients ne peuvent se contacter...... De plus, qui dit moins de sources accessibles, dit moins de chance de voir les fichiers complet, dit aussi que tu concentres tes "tickets de queue" chez moins de personne (donc leur upload queue augmente en conséquence, au lieu de se répartir chez d'autres sources moins sollicitées)
Sinon autre avantage non des moindres, tu évites de repartir en queue de liste de TOUTES tes sources de download à chaque changement de serveur (et dieu sait que ça arrive souvent, même sans le vouloir)... rien que ça, je trouve que c'est non négligeable!!! Avec un LowID, c'est clair que les files d'attentes sont interminables à cause de ça: moins de sources, retour en queue de peloton à chaque changement de serveur ou déconnexion/reconnexion, dépendance accrue à la qualité du serveur pour obtenir des sources, et comme l'obtention de ces dernieres se fait en UDP, souvent une bonne partie des sources sont perdues avant même d'avoir été transmises au client lowID !!)
Citation:
Message provenant de GENIUS
je répète , les 20 % de préservation de bande passante réservé par le système :
Détermine le pourcentage de bande passante de connexion que le système peut réserver. Cette valeur limite les réserves combinées de bande passante de tous les programmes ouverts sur le système.
Par défaut, le Planificateur de paquets limite le système à 20% de la bande passante d'une connexion, mais vous pouvez passer outre cette valeur à l'aide de ce paramètre.
Si vous activez ce paramètre, vous pouvez utiliser l'option "Limite de bande passante" pour indiquer la quantité de bande passante que le système peut réserver.
Si vous désactivez ce paramètre ou ne le configurez pas, la valeur par défaut (20%) est utilisée.
Important : si la limite de bande passante est spécifiée dans le Registre pour une carte réseau, ce paramètre est ignoré lors de la configuration de cette carte réseau.
Donc selon toute logique .. 64*20/100 > ..... = bande passante réservée..
Ben cela n'a pas empécher personne de D/L à 64 quand le réseau marchait bien ou de UP à 16 max...
Donc ça ne tient pas....
|
Qu'est ce qui ne tient pas... peux-tu réfuter quelquechose de mon post précédent? y-a-t-il un seul truc de faux dans ce que j'ai dit plus haut?
Citation:
Message provenant de GENIUS
Avec ces paramétres, je navigue bien plus rapidement sous IE que les parametres par défaut :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"SackOpts"=dword:00000001
"TcpWindowSize"=dword:0003ebc0
"Tcp1323Opts"=dword:00000001
"DefaultTTL"=dword:00000040
"EnablePMTUBHDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:0003ebc0
|
Là tu parles d'IE, alors que nous on parle d'edonkey depuis tout à l'heure... mais malgré cela, ce que j'ai écrit plus haut tient toujours: si ton upload est SATURE, peu importe tes paramétrages de la base de registre concernant IE, tu rameras comme un malade..... et accessoirement, les clefs évoquées juste ci-dessus n'ont aucun rapport avec l'upload/download, mais il s'agit de paramétrages "réseau" purs.... qui vont gouverner comment vont réagir les paquets TCP lors de leur transit sur internet (en cas de coupure de lien, en cas de non acknowledgement, en cas de timeout, etc...). Effectivement ça permet de mieux surfer, mais ça permet aucunement de contrer le problème d'upload saturé qui fait dégringoler les performances de download.
Citation:
Message provenant de GENIUS
Partons du principe que la valeur par défaut chez la majorité soit de 10.. en augmentant cette valeur à 16 : cela jouera obligatoirement dans les connections entrantes ....
Donc plus de gens qui rentrent , moins de gens qui attendent > C logique ... moins de gens qui attendent > plus de sources disponibles ( bande passante) pour les autres...
le but n'est pas de savoir qui a tort et qui a raison.. Le but c'est de tester ... et voir et ensuite tirer des conclusions, pas de sortir des théories que personne ne peut vérifier... |
C'est pas une question d'avoir tort ou d'avoir raison.... la question est de savoir le bien fondé d'un test que tu justifies en disant que l'upload et le download sont indépendants, alors qu'au contraire le download dépend DIRECTEMENT de l'upload disponible.... il ne sert à rien de faire un test en partant de mauvaises hypothèses, c'était la seule démonstration de mon post..... (en logique A->B est FAUX si A est FAUX ... (peu importe B))
Signaler ce message à un modérateur | IP: Logguée
Temps en ligne : 92 Jours, 20 Heures, 31 Minutes, 0 Seconde en ligne
|
01-08-2002 13:25
lanificateur de paquet Os > réservation de bande passante et là tu mets "0" et tu actives et Ok 
