Pages: 1 [2] 3 4   En bas

Auteur Sujet: Bufferbloat : Noyau Linux 3.5 => réduction de la latence réseau en charge  (Lu 16927 fois)

0 Membres et 1 Invité sur ce sujet

Branco

  • Expert
  • Abonné CanalBox
  • *
  • Messages: 80
La première bataille contre le bufferbloat a été gagnée...
« Réponse #12 le: 09 août 2012 à 11:51:34 »
Pour info, allez voir les dernières nouvelles de Jim Gettys, l'homme qui a découvert ce foutu pb de latence sur Internet.
Il a présenté à l'IETF semaine dernière l'avancement des travaux pour réparer le bufferbloat.
Lire l'article

Pour rappel : Le bufferbloat touche les serveurs Linux  :(, mais aussi les PC (chrome, Windows, FireFox)  :(, les MAC OSx  >:(, les routeurs WIFI  :(, les routeurs de l'opérateur  :-\, mais aussi les modems :()

Par exemple : L'industrie du cable aux Etats-Unis a modifié leur standard DOCSIS cette année pour implèmenter le contrôle du buffer sur les modems et les CMTS. J'en parle en détail dans ce post
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #13 le: 10 août 2012 à 17:13:23 »
A noter que le noyeau 3.6 qui va sortir à la rentrée semble avoir d'autres amélioration concernant «Bufferbloat» : Autre apport important, « TCP small queues » est une modification de la pile réseau, conçue pour prévenir le phénomène de «*Bufferbloat*». Il se produit lorsqu’un excès de paquets dans la mémoire temporaire cause une dégradation importante au réseau.
Source : Developpez.com, le 7 août 2012.
IP archivée

corrector

  • Invité
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #14 le: 10 août 2012 à 20:18:06 »
Citation de: Branco le 09 août 2012 à 11:51:34
Pour rappel : Le bufferbloat touche les serveurs Linux  :(, mais aussi les PC (chrome, Windows, FireFox)
Je ne vois pas le rapport avec les applications...
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #15 le: 10 août 2012 à 21:14:04 »
C'est tout ce qui rajoute des buffers : applications, équipements réseaux,...
IP archivée

corrector

  • Invité
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #16 le: 10 août 2012 à 23:48:46 »
Les applications rajoutent des buffers?


IP archivée

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #17 le: 11 août 2012 à 00:33:24 »
Citation de: corrector le 10 août 2012 à 23:48:46
Les applications rajoutent des buffers?
Si elles sont écrites pour ... (limitation débit au niveau applicatif ?)
IP archivée

corrector

  • Invité
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #18 le: 11 août 2012 à 07:35:09 »
Je ne comprends pas ce que les applications viennent faire ici.

Seuls les routeurs, les commutateurs, les ponts réseaux, les modems ... peuvent rajouter des buffers - les applications ne traitent même pas les paquets!
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #19 le: 11 août 2012 à 09:32:42 »
Le firewall de Windows a forcèment un buffer sinon, si il ne peux pas traiter l'information, où irait le paquet ?
IP archivée

corrector

  • Invité
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #20 le: 11 août 2012 à 17:45:31 »
Je ne pense pas qu'un pare-feu ai besoin son propre tampon, du moins si c'est un greffon sur du sous système IP (comme netfilter). Il peut utiliser les files d'attentes du sous système IP.
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #21 le: 11 août 2012 à 21:45:37 »
Certains firewall sous windows rajoutent 10ms de ping (à vide quand seul un ping est effectué) d'où la demande régulière de faire un SpeedTest en "Mode sans échec avec prise en charge réseau"

FAI : Kiwi fibre optique sans Kiwi box (qui limite le débit à 30 Mb/s)
Système d'exploitation : Windows 7 Ultimate.
Antivirus : Avast Home version 6.
Firewall : Celui de Windows 7.
Navigateur : Firefox 7.
PC : Pentium 4 3.2Ghz en socket 775 avec 2Go de DDR2, un disque dur de 500 Go pour le système et un de 500 Go pour le stockage.

Windows 7 en mode normal :


Windows 7 en mode sans échec avec prise en charge réseau :


Un logiciel prend 8ms de ping en plus !
IP archivée

corrector

  • Invité
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #22 le: 12 août 2012 à 00:13:18 »
Il faut voir qu'un pare-feu refait une classification des paquets en plus de celle de la couche IP.
IP archivée

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 607
  • FTTH orange
Noyau Linux 3.5 : réduction de la latence réseau en charge
« Réponse #23 le: 20 septembre 2012 à 19:31:11 »
bon si ça vous intéresse je suis entrain de faire la comparaison entre le 3.4.7-1 et le 3.5.4-1

Code: [Sélectionner]
[****@*** ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=32.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=31.7 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=32.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=34.1 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=47 time=32.7 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=47 time=32.8 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=47 time=34.6 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=47 time=32.0 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=47 time=32.7 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=47 time=40.0 ms  <------------
64 bytes from 8.8.8.8: icmp_req=11 ttl=47 time=65.8 ms
64 bytes from 8.8.8.8: icmp_req=12 ttl=47 time=60.7 ms
64 bytes from 8.8.8.8: icmp_req=13 ttl=47 time=72.8 ms
64 bytes from 8.8.8.8: icmp_req=14 ttl=47 time=81.0 ms
64 bytes from 8.8.8.8: icmp_req=15 ttl=47 time=82.4 ms
64 bytes from 8.8.8.8: icmp_req=16 ttl=47 time=81.6 ms
64 bytes from 8.8.8.8: icmp_req=17 ttl=47 time=55.7 ms
64 bytes from 8.8.8.8: icmp_req=18 ttl=47 time=72.6 ms
64 bytes from 8.8.8.8: icmp_req=19 ttl=47 time=78.4 ms
64 bytes from 8.8.8.8: icmp_req=20 ttl=47 time=45.7 ms
64 bytes from 8.8.8.8: icmp_req=21 ttl=47 time=48.1 ms
64 bytes from 8.8.8.8: icmp_req=22 ttl=47 time=52.8 ms
64 bytes from 8.8.8.8: icmp_req=23 ttl=47 time=58.6 ms
64 bytes from 8.8.8.8: icmp_req=24 ttl=47 time=104 ms
64 bytes from 8.8.8.8: icmp_req=25 ttl=47 time=74.4 ms
64 bytes from 8.8.8.8: icmp_req=26 ttl=47 time=67.9 ms
64 bytes from 8.8.8.8: icmp_req=27 ttl=47 time=78.0 ms
64 bytes from 8.8.8.8: icmp_req=28 ttl=47 time=50.8 ms
64 bytes from 8.8.8.8: icmp_req=29 ttl=47 time=55.3 ms
^C
--- 8.8.8.8 ping statistics ---
29 packets transmitted, 29 received, 0% packet loss, time 28043ms
rtt min/avg/max/mdev = 31.799/55.979/104.083/20.132 ms

uname -a
Linux **** 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux

edit: la suite après la maj:

Code: [Sélectionner]
[*****@*** ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=32.4 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=33.4 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=36.0 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=32.5 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=47 time=33.0 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=47 time=32.7 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=47 time=32.8 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=47 time=32.4 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=47 time=32.2 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=47 time=32.4 ms
64 bytes from 8.8.8.8: icmp_req=11 ttl=47 time=32.0 ms
64 bytes from 8.8.8.8: icmp_req=12 ttl=47 time=82.7 ms <-------------
64 bytes from 8.8.8.8: icmp_req=13 ttl=47 time=66.4 ms
64 bytes from 8.8.8.8: icmp_req=14 ttl=47 time=90.0 ms
64 bytes from 8.8.8.8: icmp_req=15 ttl=47 time=50.2 ms
64 bytes from 8.8.8.8: icmp_req=16 ttl=47 time=52.7 ms
64 bytes from 8.8.8.8: icmp_req=17 ttl=47 time=58.8 ms
64 bytes from 8.8.8.8: icmp_req=18 ttl=47 time=66.8 ms
64 bytes from 8.8.8.8: icmp_req=19 ttl=47 time=73.9 ms
64 bytes from 8.8.8.8: icmp_req=20 ttl=47 time=49.5 ms
64 bytes from 8.8.8.8: icmp_req=21 ttl=47 time=62.4 ms
64 bytes from 8.8.8.8: icmp_req=22 ttl=47 time=63.8 ms
64 bytes from 8.8.8.8: icmp_req=23 ttl=47 time=61.1 ms
64 bytes from 8.8.8.8: icmp_req=24 ttl=47 time=74.2 ms
64 bytes from 8.8.8.8: icmp_req=25 ttl=47 time=85.8 ms
64 bytes from 8.8.8.8: icmp_req=26 ttl=47 time=77.7 ms
64 bytes from 8.8.8.8: icmp_req=27 ttl=47 time=62.4 ms
64 bytes from 8.8.8.8: icmp_req=28 ttl=47 time=58.3 ms
64 bytes from 8.8.8.8: icmp_req=29 ttl=47 time=49.8 ms
64 bytes from 8.8.8.8: icmp_req=30 ttl=47 time=58.1 ms
64 bytes from 8.8.8.8: icmp_req=31 ttl=47 time=32.1 ms <------------
64 bytes from 8.8.8.8: icmp_req=32 ttl=47 time=32.3 ms
64 bytes from 8.8.8.8: icmp_req=33 ttl=47 time=31.9 ms
64 bytes from 8.8.8.8: icmp_req=34 ttl=47 time=32.2 ms
^C
--- 8.8.8.8 ping statistics ---
34 packets transmitted, 34 received, 0% packet loss, time 33053ms
rtt min/avg/max/mdev = 31.918/51.077/90.086/18.587 ms
[***@*~]$ uname -a
Linux *** 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux


voila au final pas trop de différences je trouve...
fait sur une ligne adsl orange @ 10mbps

a+
« Modifié: 20 septembre 2012 à 23:46:48 par butler_fr »
IP archivée
Pages: 1 [2] 3 4   En haut