A voir ces tcpdumps (downloads vers xp) et celui que tu m'as fait parvenir (uploads depuis xp), il y a un pb de perte de paquets.
Seulement les seuls tcpdumps 'unilatéraux' que tu montres ici ne montrent malheureusement que le 'pendant', pas l'aboutissant (ou l'inverse).
Pour analyser tout ça, il faut les tcpdumps des deux côtés pour la même session (pour un download et pour un upload) pour voir qui envoie quoi quand et qui reçoit quoi quand
En première analyse avec ces tcpdumps 'unilatéraux' :
- Dans le cas upload (dont j'ai la trace uniquement côté receveur) le windows emetteur aurai 'omi' tout simplement d'envoyer les paquets correspondants que le receveur était supposé attendre ? (au vu des "sequence numbers").
Le tcpdump emetteur windows permettra de tirer au clair le fait que le windows a ou pas envoyé ces paquets (je serais surpris qu'il ne les ai jamais envoyé ... mais sait on jamais).
Dans le cas où il les a bien envoyé, alors le pb n'est pas 'windows' mais sur le réseau (sensible à des 'windows' ? va savoir ... mais au moins on en aura le coeur net si le fautif est le windows ou pas)
- Dans le cas du download (dont tu montres la trace uniquement côté émetteur) le windows receveur peut avoir eu une congestion réseau, ou encore un pb 'réseau' (toujours sensible à du 'windows' ?). A confirmer justement avec le tcpdump de son côté pour voir si les paquets 'perdus' sont bien arrivés jusqu'à sa carte réseau mais ne les a pas traité.
Tu peux me faire ces 'doubles tcpdumps simultanés' (en down et up) Vivien ?
(et me les fournir par le moyen que tu connais
)
En conclusion, je vais encore me faire taper par certains mais nous n'avions pas ce type de comportement quand les testeurs qui fessaient la courbe étaient sous linux.
...
Du moment que c'est étaillé et prouvé, personne ne te tapera dessus
Fournis les 'billes' (les tcpdumps des deux côtés) et je serai le premier à reconnaitre si willou/billou/winbouhouhou a fait encore des siennes
Comme d'ailleurs je l'ai déjà fait pour l'histoire des 'time-stamps' et leur 'sequences initiales' (le résultat était même match 1-1 : les deux ont leur part de fautes à des niveaux diférents)
Linux à une pille IP très agressive qui va perdre beaucoup plus de paquets que Windows (dépassement des buffers à un endroit sur le réseau) mais Linux est trés peu sensible aux pertes de paquets.
Pour ce qui est de la pile 'agressive', cela n'existe pas
(on alors faudra m'expliquer ce que tu entends par 'agressive')
Si on suit la norme à la lettre, on est à la norme point, ni plus ni moins agressif que toute autre pile ip conforme à la norme
Et pour la perte de paquets, si on a une pile 'à la norme' on en perdra pas plus ni moins qu'un autre 'à la norme'
Et on ne sera ni plus ni moins 'sensible aux pertes de paquets' qu'un autre 'à la norme'
Mais malheureusement pour nous, NI Windows, Ni Linux ne le sont (dixit encore et encore le pb 'time-stamps' entre les deux qui a prouvé qu'auncu des deux n'étaient conformes sur ce point)
[HS]
D'ailleurs je n'ai jamais eu de retour ni des uns ni des autres, devs Linux comme Microsoft sur ces 'bugs' times-stamps, malgrès plusieurs relances ...
A croire qu'ils se fichent les uns comme les autres (les deux camps donc) que l'un ne veule pas discuter correctement avec l'autre ...
La guerre c'est la guerre que diable ! Pourquoi donc faciliter la discussion avec l'ennemi éternel (des deux points de vue)
Serait ce la raison de la nom résolution de ces bugs ?
Ce qui me fait dire : TOUS à BSD (FreeBSD, OpenBSD, NetBSD, ...)
Au moins on restera dans le même monde qui ne se querelle pas dans des batailles de 'je suis le meilleurs' et n'a jamais eu la prétention de vouloir 'casser' du machin-chose
Son mérite c'est d'exister, et c'est certainement le meilleurs mais ne le crie pas sur les toits
[/HS]
Sujet: Graphs de débit dans le temps pour Neuf FTTH Pau (Lu 11445 fois)
