Fibre Optique FREE:!PB de débit!!!

XP n'est pas terrible pour le très haut débit. Un ordinateur de 5 ans, ce n'est pas terrible pour le très haut débit
enfin quand même,
il ya longtemps que les PC fonctionnent en réseau local, à des débits bien supérieurs, il n'y a pas que les box et internet dans l'infomatique, les réseau 100Mbit/s sont monnaie courante ne entreprise et les cartes réseau gigabit sont apparues sous xp.
tout ça est d'abord une question de pilotes et on sait faire des pilotes de carte réseau depuis longtemps.
pour le reste entièrement d'accord :-)

Salut brupala!

Ton objection n'est pas forcément valable: D'abord il ne s'agit pas tellement de la capacité physique de la carte réseau, ni même de la capacité du lien fibre vers Internet, mais bien de la manière qu'a XP d'exploiter cette capacité: À fond, ou pas. Et justement, dans certaines conditions, XP se montre clairement incapable d'exploiter à fond le débit. Ces conditions défavorables impliquent en général: Internet, un ping supérieur à 10 ms, une ligne de plus de 30 Mbits/s, et le téléchargement sur une session TCP unique (ce qui est le plus courant, sauf avec des accélérateur de téléchargment multi-sessions, et sauf avec certains protocoles genre Torrent). Tout aussi clairement, les conditions qui règnent dans un LAN, fast ou Gigabit, avec des pings inférieurs à la milliseconde, lui sont favorables: XP peut y faire très bonne figure.

Il ne s'agit pas non plus d'un problème de pilotes (enfin pas toujours), mais plutôt d'un problème plus fondamental de comportement de la pile TCP/IP au coeur du système. Une histoire de RWin trop petite d'origine. Et pas assez dynamique.

En gros, XP d'origine gaspille un peu ou beaucoup du débit qui est pourtant physiquement disponible sur la ligne Internet. XP gagne beaucoup à être optimisé par des réglages adaptés au très haut débit. Par exemple TCPoptimizer fait des miracles sur XP. Mais même optimisé, XP n'arrive pas à la cheville d'un Seven d'origine (qui dispose d'une grosse RWin, qui de plus s'adapte automatiquement aux conditions réelles de la session, individuellement pour chaque session TCP)... Plus d'infos dans cet intéressant article de vivien:

Impact du ping sur le très haut débit en fonction du système d'exploitation

ouais,
une fenetre tcp classique est capable d'inonder le débit de n'importe quel lan sur une liaison symétrique.
après, ce sont les retransmissions sur erreur qui font la différence.
la fenetre reste toujours ouverte sur une connexion équilibrée et quand elle se ferme, c'est signe de problème (liaison trop lente, système trop lent,erreurs de transmission) donc, plus la liaison est rapide, moins il est nécéssaire d'optimiser.
que ces considérations jouent pour un modem RTC ou RNIS, je veux bien, mais au niveau du très haut débit, ça influe de moins en moins.
Tout ce n'est que des tailles de buffer et des délais de traitement: on peut recevoir si on la capacité, mais traiter, c'est le rôle de l'application est une autre chose.
bref, même si xp, est mois optimisé que seven sur des liaisons sans erreur, ce n'est pas fondamental au niveau des capacités de transmission qui reste bien au dessus des standards du web.
PS,
je ne sais pas d'où sortent les courbes que tu fournis, ou plutôt quelles sont les conditions du test, mais elles me paraissent assez peu réalistes au vu du fonctionnement réel.

Ce que tu dis à propos de LAN est à la fois vrai, et à coté de la plaque. Le problème dont je parle ne se produit pas en LAN. Il se produit sur Internet, exclusivement. Et son impact est d'autant plus fort que le serveur est "loin" à l'étranger (c'est la latence qui compte, en fait).

Ce que tu dis à propos de retransmission sur erreur a un fort rapport... le problème affecte en effet la remontée en régime suite à ces erreurs: Il affecte la pente de cette remontée, et il affecte le niveau auquel le débit va se stabiliser. Mais le problème se produit même sur liaison parfaite de bout en bout sans aucune erreur.

Ce que tu dis à propos de RTC et de RNIS est l'inverse de la réalité: Au contraire, en bas débit le problème ne se voit pas du tout, et il n'apparait qu'en très haut débit. Et son impact est d'autant plus fort en pourcentage que le débit est haut. Dans le cas présent, un abonnement Freebre, l'impact est très fort, à mon avis quasiment inratable.

Il suffit d'essayer pour s'en apercevoir: L'article de Vivien propose d'ailleurs un test de démonstration à faire soi même. Si tu as un XP non-optimisé sous la main... Moi pas, mais j'ai un Seven 64 bien optimisé, et pourtant l'expérience est très très parlante quand même: J'obtiens environ 5 fois moins de débit sur le 2ème serveur (avec latence artificielle +90 ms), avec 2,32 Mio/s, que sur le 1er serveur (ping 5 ms), avec 11,2 Mio/s (mon tuyau Numéricâble fait 11,3 Mio/s exactement). Et voilà CQFD: Mes mesures réelles collent à peu près à la courbe bleue (celle de Seven 64) du graphe.

Les courbes, il y en a deux assez proches pour XP:

- La courbe jaune correspond à un calcul théorique, dont la formule est donnée dans l'article, et dont les données sont celles d'un XP d'origine.

- La courbe rouge est le résultat en pratique, les mesures réelles de débit d'un XP brut d'install, pas optimisé du tout, sous diverses latences.

À chaque fois, il s'agit du débit de téléchargement sur une session TCP unique. Parce que si on télécharge 5 fichiers à la fois, sur 5 sessions TCP, on peut éventuellement quintupler le débit cumulé, peut être même remplir à fond le tuyau (les 100 Mbits/s de la fibre).

Bon, je n'ai pas de connexion fibre (adsl à 6 Mbit/s ip environ):

Microsoft Windows XP [version 5.1.2600]     
(C) Copyright 1985-2001 Microsoft Corp.     

C:\Windows\system32>ftp testdebit.info     
Connecté à testdebit.info.     
220 Vivien FTP     
Utilisateur (testdebit.info:(none)) : anonymous     
331 Anonymous login ok, send your complete email address as your password     
Mot de passe :     
230 Bienvenue anonymous sur TestDebit.info....     

ftp> get 20Mo.png     
200 PORT command successful     
150 Opening ASCII mode data connection for 20Mo.png (20000000 bytes)     
226 Transfer complete     
ftp : 20075652 octets reçus en 28,22 secondes à 711,42 Ko/sec.     
ftp> bye     
221 Goodbye.     

C:\Windows\system32>ftp 90ms.testdebit.info     
Connecté à 90ms.testdebit.info.     
220 Vivien FTP     
Utilisateur (90ms.testdebit.info:(none)) : anonymous     
331 Anonymous login ok, send your complete email address as your password     
Mot de passe :     
230 Bienvenue anonymous sur 90ms.TestDebit.info....     
ftp> get 20Mo.png     
200 PORT command successful     
150 Opening ASCII mode data connection for 20Mo.png (20000000 bytes)     
226 Transfer complete     
ftp : 20075652 octets reçus en 58,70 secondes à 341,99 Ko/sec.     

ftp> bye     
221 Goodbye.     

C:\Windows\system32>     

la différence est environ du simple au double en ftp ligne de commande, quasi invisible sous filezilla.

je relance sous linux ubuntu:

brupala@nc6120:~$ ftp testdebit.info    
Connected to testdebit.info.    
220 Vivien FTP    
Name (testdebit.info:bruno): anonymous    
331 Anonymous login ok, send your complete email address as your password    
Password:    
230 Bienvenue anonymous sur TestDebit.info....    
Remote system type is UNIX.    
Using binary mode to transfer files.    
ftp> get 20Mo.png    
local: 20Mo.png remote: 20Mo.png    
200 PORT command successful    
150 Opening BINARY mode data connection for 20Mo.png (20000000 bytes)    
226 Transfer complete    
20000000 bytes received in 25.65 secs (761.4 kB/s)    
ftp> bye    
221 Goodbye.    
brupala@nc6120:~$ ftp 90ms.testdebit.info    
Connected to 90ms.testdebit.info.    
220 Vivien FTP    
Name (90ms.testdebit.info:bruno): anonymous    
331 Anonymous login ok, send your complete email address as your password    
Password:    
230 Bienvenue anonymous sur 90ms.TestDebit.info....    
Remote system type is UNIX.    
Using binary mode to transfer files.    
ftp> get 20Mo.png    
local: 20Mo.png remote: 20Mo.png    
200 PORT command successful    
150 Opening BINARY mode data connection for 20Mo.png (20000000 bytes)    
226 Transfer complete    
20000000 bytes received in 27.44 secs (711.9 kB/s)    
ftp> bye    
221 Goodbye.

le ping pour vérifier les 90ms:

 
brupala@nc6120:~$ ping testdebit.info    
PING testdebit.info (89.84.127.55) 56(84) bytes of data.    
64 bytes from 89.84.127.55: icmp_req=1 ttl=52 time=61.8 ms    
64 bytes from 89.84.127.55: icmp_req=2 ttl=52 time=60.9 ms    
^C64 bytes from 89.84.127.55: icmp_req=3 ttl=52 time=61.4 ms    

--- testdebit.info ping statistics ---    
3 packets transmitted, 3 received, 0% packet loss, time 10303ms    
rtt min/avg/max/mdev = 60.927/61.408/61.876/0.437 ms    

brupala@nc6120:~$ ping 90ms.testdebit.info    
PING 90ms.testdebit.info (89.82.180.22) 56(84) bytes of data.    
64 bytes from 89.82.180.22: icmp_req=1 ttl=54 time=152 ms    
64 bytes from 89.82.180.22: icmp_req=2 ttl=54 time=151 ms    
^C64 bytes from 89.82.180.22: icmp_req=3 ttl=54 time=151 ms    

--- 90ms.testdebit.info ping statistics ---    
3 packets transmitted, 3 received, 0% packet loss, time 10445ms    
rtt min/avg/max/mdev = 151.074/151.501/152.160/0.472 ms    
brupala@nc6120:~$ 

Effectivement, l'impact des 90ms rajoutées est quasi nul sous linux, mais bon, 90ms c'est énorme et ce n'est pas un fonctionnement proche du réseau local.