Ratio vitesse download/upload

Votre pseudo ici · 17/04/2010, 16h22

Plop !

Lorsque j'effectue un téléchargement quelconque, je remarque que ma bande passante ascendante est également toujours utilisée.

Par exemple là, je télécharge à ~600KB/s sans rien faire d'autre, et je remarque que le pc upload à ~30KB/s.

Je ne pense pas que cette vitesse soit uniquement due aux TCP ack, bien que ça doit jouer.

Cependant, peu importe le protocole, que ce soit sur usenet, http ou peu importe, j'obtiens des vitesses similaires.

Sur usenet par exemple, quand je télécharge à 2,2MB/s, j'upload à une vitesse hallucinante qui est de près de 100KB/s !! C'est très très gênant car vu que j'ai une vitesse maximale de 1Mb/s en upload, ma ligne sature, mon ping augmente à vitesse grand V etc, etc...

Quelqu'un connaîtrait-il la raison de cet upload ?
Est-ce uniquement du aux ack tcp ?

Quelqu'un aurait-il un peu de lecture à ce sujet ? Je n'ai rien trouvé de concret via google, malheureusement

.

De plus, si jamais je m'amuse à upload intentionnellement à côté, sur un FTP par exemple, ma bande passante descendante est directement bridée.
Par exemple, si j'upload un gros fichier sur mon ftp à 110KB/s (débit maximal de ma ligne), je ne peux en parallèle télécharger qu'à ~200KB/s, jusqu'à ce que je coupe l'upload, auquel cas ma vitesse de téléchargement remonte jusqu'à 2,2MB/s.

Merci d'avance

Velocy · 17/04/2010, 16h31

Tu n'as pas un petit Wireshark d'installé ? Il pourrait t'en dire beaucoup plus

Arendallan · 17/04/2010, 17h11

Citation :

Publié par Votre pseudo ici

Est-ce uniquement du aux ack tcp ?

Probablement pas : les ack TCP n'ont lieu que pour plusieurs paquets, eux mêmes beaucoup plus gros qu'un simple acquittement.

Votre pseudo ici · 17/04/2010, 17h14

Wireshark ne me montre que les ACK TCP...

Ca m'étonne juste que c'est si important comme débit, 30KB/s pour ~580KB/s, ça veut dire que les ack représentent 5% du débit total, ce qui me semble juste énorme.

@ ci-dessus:

voici un extrait de wireshark lorsque je ne fais aucune autre activité que le d/l sur usenet (NNTP)

Code:

No.     Time           Source                Destination           Protocol Info
   6131 7.377486000    192.168.1.2           69.16.176.253         TCP      [TCP Window Update] 50300 > nntp [ACK] Seq=53 Ack=509758 Win=65340 Len=0

No.     Time           Source                Destination           Protocol Info
   6132 7.378655000    69.16.176.253         192.168.1.2           NNTP     Response: \315~\032\2726=}\031\006P6\237\035\tfNF\230=M\360\354k\331\321\323=J\232\251h\032v_\242yx,j \366OV\234\345V\327\201-*\262$z\204\236\303\316_>:\275\324\004`*Z[\241\214z+**)$\256\216\361\265<\256-\\211\373eSC\352_rt\026Z,\235\267\247csw[/j\355\262\323S\277\262\212

No.     Time           Source                Destination           Protocol Info
   6133 7.378667000    192.168.1.2           69.16.176.253         TCP      50299 > nntp [ACK] Seq=209 Ack=1552044 Win=65340 Len=0


No.     Time           Source                Destination           Protocol Info
   6134 7.380658000    69.16.176.253         192.168.1.2           NNTP     Response: o\20019\204B:\261\021\34044\276<X\031'i\365))))\323\001=}*0\315d\2322\313<v\357N\006\335\370\362\241\275\267\223G}x\375ZZ\216\2155W****+\340\206f\226.kp\374\031A\235\377c\023\\250\355=J\356\023=J\361\375;I\316


No.     Time           Source                Destination           Protocol Info
   6135 7.380697000    192.168.1.2           69.16.176.253         TCP      50299 > nntp [ACK] Seq=209 Ack=1553496 Win=65340 Len=0

No.     Time           Source                Destination           Protocol Info
   6136 7.383103000    69.16.176.253         192.168.1.2           NNTP     Response: \253\312mG\002H\223\372\342\002RhI\025\227_.\022Zh;'@\204<FT\355\326L\035\320\004ty\305F\243\377Z\245Q\361yZ\236\277Ms\005\b=@\213\227\022\341\347\026e\004\235\f\321\245\004\201


No.     Time           Source                Destination           Protocol Info
   6137 7.383114000    192.168.1.2           69.16.176.253         TCP      50299 > nntp [ACK] Seq=209 Ack=1554948 Win=65340 Len=0

Et c'est bien sûr juste ça sur des millions de pak... je ne vois vraiment rien d'autre qui sort que des ack :s

Arendallan · 17/04/2010, 17h17

Aurait tu une ligne avec des paquets de très faible taille ?

Votre pseudo ici · 17/04/2010, 17h32

C'est de la PPPoE, donc la longueur maximale des packets est d'environ 1500bytes, or là les packets reçus ont tous une longueur exactement de 1452, ce qui me semble donc correct...

Eno · 17/04/2010, 17h58

T'es bien sûr que t'upload à cette vitesse ? Sinon pour les ACK c'est dans les deux sens aussi, enfin ça dépend ce que tu appelle ACK, parce que pour ceux ou tu 'réponds' ils ont une taille presque nulles ( ~~54octets )

Votre pseudo ici · 17/04/2010, 18h32

Citation :

Publié par Eno

T'es bien sûr que t'upload à cette vitesse ? Sinon pour les ACK c'est dans les deux sens aussi, enfin ça dépend ce que tu appelle ACK, parce que pour ceux ou tu 'réponds' ils ont une taille presque nulles ( ~~54octets )

Je n'ai pas inclu les données du pak dans mon bump, ce sont les "infos" des pak simplement. Le contenu des pak reçu fait bien 1452B de long.

Si tu parles des ACK que j'envoi moi, oui, un ACK TCP fait bien ~54B dans son entièreté.

Si je fais le calcul donc, en partant sur une base de 1500B par pak.
à 500KB/s, j'obtiendrais 333,33... pak/s. Sachant qu'un ack fait 54B, si j'en envoi 333,33/s alors j'obtiens un débit de 17,57KB/s !

Mes résultats en pratique sont un peu plus élevés que ça (~25KB/s d'upload pour du 500KB/s download).

Mais je n'avais jamais pensé que les ack pouvaient prendre autant de bande passante.

Là où ça devient gênant c'est vraiment quand j'utilise toute la capacité de ma ligne. Parce que quand je télécharge à plein régime, j'utilise quasiment l'intégralité de ma bande passante ascendante (~100KB/s sur 110KB/s) ce qui me laisse très peu de marge derrière, et si j'upload même pas à très haute vitesse, genre 50KB/s, mon download s'en ressent très fortement.

Donc à bas les offres 20Mb/1Mb je dirais, non ? Pour pouvoir supporter du 20Mb/s faudrait au moins 2Mb en upload didiou !

Si des gens ont de la lecture intéressante à ce sujet et des chiffres concrets surtout, ça m'intéresse fortement !

Eno · 17/04/2010, 19h07

Je vais te donner mon exemple, j'ai pris un ISO de Linux, c'est dl en HTTP à environ ~~850ko/sec :
Edit: 2sec

Votre pseudo ici · 17/04/2010, 19h24

J'attend tes résultats avec impatience

Eno · 17/04/2010, 19h38

Et voilà, donc j'ai 850ko/sec en DL et un peut moins de 1ko/sec en UL, j'ai laissé tourné 5min pour qu'on voit bien :

Il n'y a quasiment pas d'upload ( presque 0 ). Il faudrait que tu utilise Netlimiter pour voir exactement qui fait quoi, comme ça on pourrait voir d'où vient le problème :
http://www.netlimiter.com/betas.php

Votre pseudo ici · 17/04/2010, 19h57

Euh.....

Je sais pas comment Netlimiter fait son calcul, mais voici ce que j'ai moi:

On voit bien que Netlimiter affiche quasiment 0 d'upload et ISP Monitor affiche 30KB/s.

J'ai pris aussi le screen de la carte pour montrer qu'il y avait vraiment du traffic qui passe.

à 0.1KB/s j'aurais jamais pu upload 10MB (je viens de reboot) en aussi peu de temps. Netlimiter affiche un résultat faussé ici, ou il ne prend tout simplement en compte que les packets où il y a des données réelles (donc pas les ack et autres joyeuseteries TCP)

http://img685.imageshack.us/img685/3355/uploadv.th.png

(l'upload qu'on voit dans Netlimiter c'est moi qui upload le screen (j'en ai pris 2 en fait

), et j'ai coupé le d/l pendant ce temps)

Eno · 17/04/2010, 20h01

Je vais tester avec ton truc ISP monitor. Sinon sur ton screen avec Netlimiter, quand on regarde en bas à droite le graph on voit que t'avais 50ko/sec d'upload au début.

Votre pseudo ici · 17/04/2010, 20h04

Citation :

Publié par Eno

Je vais tester avec ton truc ISP monitor. Sinon sur ton screen avec Netlimiter, quand on regarde en bas à droite le graph on voit que t'avais 50ko/sec d'upload au début.

cf mon edit ^^

Si tu veux pas t'embêter avec ISP Monitor, regardes l'état de ta carte réseau pendant que tu télécharges, tu verras qu'il y a bien plus que 0.1KB/s qui passe en upload.

P.S.: mon screenshot que j'ai upload 2 fois faisait juste ~200KB

Votre pseudo ici · 17/04/2010, 20h14

Je reposte pour pas partir dans une bataille d'edit:

Je confirme, Netlimiter n'affiche que les vitesses d'échange de données. C'est pour ça que la vitesse de Netlimiter est très proche de celle qu'affiche Grabit. ISP Monitor mesure la vitesse brute utilisée de la bande passante.

Eno · 17/04/2010, 20h23

Je viens de regarder en prenant des screens, juste en regardant la carte réseau c'est toujours pareils :
En 5min j'ai DL 148.283Mo et UL 2.848Mo ça nous donne bien les bonnes valeurs du dessus :

( si tu fais le envoyer du screen 2 - le envoyé du screen 1 / par le temps ) ça donne un truc juste. Le problème c'est quand regardant la carte réseau, tu prends en compte tout ce que fais ton pc, c'est à dire les requêtes DNS, Windows, ton routeur ect ...
Je maintiens ce que je dis, tu peux DL un iso à 850ko/sec sans uploader quasiment !

Ysengwen · 17/04/2010, 20h24

C'est normal d'avoir du trafic en upload quand on télécharge, dû au protocole de transmission et aux échanges annexes autour du fichier proprement dit, et c'est normal que le débit descendant sature voir chute si on sature (ou à l'inverse bride complètement) l'ascendant.

3 à 10% d'overhead sont à prévoir, 30 Ko occupés en up pour 600 Ko en down ça ne me semble pas si scandaleux.

Eno · 17/04/2010, 20h42

Je prends un autre exemple sur Linux cette fois et c'est encore plus facile à voir :
Avant le DL :

Citation :

RX bytes:974968634 (929.8 MiB) TX bytes:517202920 (493.2 MiB)

Après le DL à 50% d'un ISO de Debian :

Citation :

RX bytes:1331789285 (1.2 GiB) TX bytes:523311608 (499.0 MiB)

Votre pseudo ici · 17/04/2010, 20h45

@Eno: c'est vraiment très étrange, je vois pas comment tu obtiens ces chiffres, c'est juste à la limite du théorique. ~3Mo pour ~150Mo ça fait que 2%, or moi j'obtiens un upload de l'ordre de 5%. Les requêtes DNS toussa sur une période de 5minutes ça va te faire à tout péter quelques bytes, rien qui va dramatiquement changer le résultat.

@Ysengwen: Oui je sais que c'est normal, je n'ai pas dit le contraire. Sauf que 100KB/s pour 2MB/s je trouve ça juste énorme. 5% de BP pratique pour aucune donnée réelle, je trouve ça très cher payé quand même.

Retournons vite à l'UDP bordayle

@ci-dessus: Tu as donc 2% d'overhead. Je vais voir sur linux, brb.

Votre pseudo ici · 17/04/2010, 20h56

Vraiment très étrange, j'obtien un ratio de l'ordre du double sous windows !

Voir screenshot:

Velocy Prophète	Tu n'as pas un petit Wireshark d'installé ? Il pourrait t'en dire beaucoup plus
17/04/2010, 16h31

Arendallan Alpha & Oméga	Citation : Publié par Votre pseudo ici Est-ce uniquement du aux ack tcp ? Probablement pas : les ack TCP n'ont lieu que pour plusieurs paquets, eux mêmes beaucoup plus gros qu'un simple acquittement.
17/04/2010, 17h11

Arendallan Alpha & Oméga	Aurait tu une ligne avec des paquets de très faible taille ?
17/04/2010, 17h17

Votre pseudo ici Alpha & Oméga	C'est de la PPPoE, donc la longueur maximale des packets est d'environ 1500bytes, or là les packets reçus ont tous une longueur exactement de 1452, ce qui me semble donc correct...
17/04/2010, 17h32

Eno Alpha & Oméga	T'es bien sûr que t'upload à cette vitesse ? Sinon pour les ACK c'est dans les deux sens aussi, enfin ça dépend ce que tu appelle ACK, parce que pour ceux ou tu 'réponds' ils ont une taille presque nulles ( ~~54octets )
17/04/2010, 17h58

Eno Alpha & Oméga	Je vais te donner mon exemple, j'ai pris un ISO de Linux, c'est dl en HTTP à environ ~~850ko/sec : Edit: 2sec
17/04/2010, 19h07

Votre pseudo ici Alpha & Oméga	J'attend tes résultats avec impatience
17/04/2010, 19h24

Eno Alpha & Oméga	Et voilà, donc j'ai 850ko/sec en DL et un peut moins de 1ko/sec en UL, j'ai laissé tourné 5min pour qu'on voit bien : Il n'y a quasiment pas d'upload ( presque 0 ). Il faudrait que tu utilise Netlimiter pour voir exactement qui fait quoi, comme ça on pourrait voir d'où vient le problème : http://www.netlimiter.com/betas.php
17/04/2010, 19h38	Télécharger la pièce jointe

Eno Alpha & Oméga	Je vais tester avec ton truc ISP monitor. Sinon sur ton screen avec Netlimiter, quand on regarde en bas à droite le graph on voit que t'avais 50ko/sec d'upload au début.
17/04/2010, 20h01

Votre pseudo ici Alpha & Oméga	Je reposte pour pas partir dans une bataille d'edit: Je confirme, Netlimiter n'affiche que les vitesses d'échange de données. C'est pour ça que la vitesse de Netlimiter est très proche de celle qu'affiche Grabit. ISP Monitor mesure la vitesse brute utilisée de la bande passante.
17/04/2010, 20h14

Ysengwen Alpha & Oméga	C'est normal d'avoir du trafic en upload quand on télécharge, dû au protocole de transmission et aux échanges annexes autour du fichier proprement dit, et c'est normal que le débit descendant sature voir chute si on sature (ou à l'inverse bride complètement) l'ascendant. 3 à 10% d'overhead sont à prévoir, 30 Ko occupés en up pour 600 Ko en down ça ne me semble pas si scandaleux.
17/04/2010, 20h24

Eno Alpha & Oméga	Je prends un autre exemple sur Linux cette fois et c'est encore plus facile à voir : Avant le DL : Citation : RX bytes:974968634 (929.8 MiB) TX bytes:517202920 (493.2 MiB) Après le DL à 50% d'un ISO de Debian : Citation : RX bytes:1331789285 (1.2 GiB) TX bytes:523311608 (499.0 MiB)
17/04/2010, 20h42

Votre pseudo ici Alpha & Oméga	Vraiment très étrange, j'obtien un ratio de l'ordre du double sous windows ! Voir screenshot:
17/04/2010, 20h56

Ratio vitesse download/upload

Connectés sur ce fil