Tests de débit avec l'offre 50 mb/s Neuf FTTH sur Pau

[lepalois]

Non pas trop mais ca te permet de faire beaucoup de chose à la fois. Ne pas oublier que la TV n'influe pas sur le débit Data (net).

Médiafibre à eut des hauts et des bas mais celà fait un moment que les débits étaient correct car certains ports sont bridé (emule par exemple).
Médiafibre achète de la bande passante sur Paris à un prix de 30€ le Mbits/s (à des euros prêt), Neuf c'est beaucoup beaucoup beaucoup moins et ils ont une infrastructure derrière.
Quand on a de l'argent on peut proposer des services de meilleure qualité (ou un plus grand choix).

L'infrastructure du PBC permet bien plus de chose encore, elle n'est pas en fin de vie

[vivien]

C'est ca pour la conversion, on ne teste pas la symétrie là juste ce que peut donner le débit max en upload PUIS en Download. Si tu fais des tests de symétrie tu verras que l'on toujours 66 Mbits/s mais partagé (~ 15 en up et 45 en down).

NON !

Plus haut j'ai écrit :

En faisant des test simultanément uplaod + download, nous obtenons es débits de 72 Mb/s (upload + download) mais il semblerais que les performances de la machine ceinte bride ces résultats (le Duron 850 Mhz doit supporter une interface graphique + de forts débits)

Mais je reste persuadé que c'est a cause du CPU. Je suis pret a refaire des tests sur tes 2 PC simultanément. L'un testeras l'upload et l'autre le download. Les tests en TCP avec upload et download simultané sont plus complexe. Je pense qu'il fauras utiliser l'UDP pour avoir de bonnes performances en Up et Down simultané.

3 solutions :
- tester avec 2 PC différents coté client
- tester avec un CPU + performant (Pentium 4 ou Athlon 64 ou sup)
- retester avec linux sans interface graphique (l'interface graphique prend une partie non négligeable du CPU sur des processeurs à 850 Mhz)

[willemijns]

- retester avec linux sans interface graphique (l'interface graphique prend une partie non négligeable du CPU sur des processeurs à 850 Mhz)

un gnome-monitor ou equivalent et on connait la valeur

[feyb64]

Tests UDP ? mmmmm

Celà peut être 'correct' à condition que la 'route' ne soit chargée (clean de bout en bout), car le UDP n'est jamais prioritaire sur du TCP, et sans 'garantie' d'aller au bout, d'où risque de pertes de paquets sur la route, donc débit indiqué peut être moindre que la réalité.

[vivien]

Celà peut être 'correct' à condition que la 'route' ne soit chargée (clean de bout en bout), car le UDP n'est jamais prioritaire sur du TCP, et sans 'garantie' d'aller au bout, d'où risque de pertes de paquets sur la route, donc débit indiqué peut être moindre que la réalité.

Les débits sont meilleurs que le TCP même avec seulement l'upload ou seulement le download a condition d'êmere juste au bon débit (il faut faire de nombreux essais)

En cas d'upload et de download simultané, TCP dont je le rappel le débit est négocié automatiquement chute énormément (essayez sur 2 PC en local, vus verrez) En UDP je forcerais 70 Mb/s dans les 2 sens et je ne compte que les paquets réellement arrivé (il y a ura de la perte c'est sur)

IPERF est trés bien pour faire ca.

[feyb64]

Je voulais dire qu'un test UDP n'est fiable que dans des conditions 'réseau' optimales (pas de charge du réseau, bande passante dispo, ...).
Dans le cas contraire, perte de paquets au niveau des routeurs car le traffic UDP est non 'garanti' par nature.
Et perte de paquets faussera le compteur de réception.

[willemijns]

Celà peut être 'correct' à condition que la 'route' ne soit chargée (clean de bout en bout), car le UDP n'est jamais prioritaire sur du TCP

c'est l'inverse

, et sans 'garantie' d'aller au bout, d'où risque de pertes de paquets sur la route,

vrai

[vivien]

En UDP les pertes de paquets si elles existent diminue + le débit qu'en UDP car il faut envoyer un paquet pour redemander le paquet manquant.

Mon but n'est pas d'avoir tous mes paquets a la fin mais de calculer le débit max. Exemple : j'envoi les paquets à 80 Mb/s et je regarde combien arrive.

En TCP, le débit est systématiquement inférieur (légèrement) car le protocole ne peut se permettre de perdre autant de paquet (et donc de devoir les renvoyer)

[feyb64]

Celà peut être 'correct' à condition que la 'route' ne soit chargée (clean de bout en bout), car le UDP n'est jamais prioritaire sur du TCP,

c'est l'inverse

tu veux dire que udp est plus prioritaire que tcp ?
Faudra m'expliquer alors que je mette à jours mes cours, certe ancestraux, de protocol IP ...

[feyb64]

En UDP TCP les pertes de paquets si elles existent diminue + le débit qu'en UDP car il faut envoyer un paquet pour redemander le paquet manquant.

Mon but n'est pas d'avoir tous mes paquets a la fin mais de calculer le débit max. Exemple : j'envoi les paquets à 80 Mb/s et je regarde combien arrive.

En TCP, le débit est systématiquement inférieur (légèrement) car le protocole ne peut se permettre de perdre autant de paquet (et donc de devoir les renvoyer)

J'ai corrigé ta phrase Maintenant mon commentaire :

Tu as raison sur le principe, TCP en pure performance est plus 'lent' que UDP
Mais celà dépend d'un facteur essentiel pour ce qui est de la 'vitesse' maximale atteignable car à 'condition égale de route' tu entre dans deux cas de figures suivant justement la 'condition' de la route au moment du test :
 1 - Route 'clean', sans goulot, suffisement libre pour supporter les débits max réels des deux extrémités, donc aucune perte de n'importe quel paquet :
    UDP sera 'meilleur' que TCP, je suis d'accord, et encore, ce sera très dépendant de la config de la pile (rwin et mtu entre autres) et dans plus optimisée des configs TCP, très 'minime' comme différence.
 2 - Route largement 'occupée' pendant la durée du transfert complet,  avec donc perte de paquets :
   UDP sera le premier à 'jecter' au niveau des routeurs ayant un lien saturé, et bien que tcp devra peut être redemander la transmission de paquets perdus, si la route est vraiment trop saturée même pour du tcp seul, tcp aura au final le compte juste, et donnera probablement une meilleure valeur de perf que udp à cet instant de test.
   Bien entendu une config tcp optimale pour une route 'clean' fera chuter les perf tcp car avec un rwin élevé, il y aura plus à retransmettre en cas de perte de paquet (on renvoi l'équivalent en taille de la rwin, même si c'est le dernier paquet qui est hs)

Comme ici, tu n'es jamais sûr de l'état de la 'route', et que udp est rarement utilisé par les programmes de transfert couramment utilisés, pour vraiment donner une 'bonne' idée du débit max, c'est plus le test "tcp sur route clean" qui donnera une valeur de capacité max de la ligne vraiment significative pour les internautes
 Indiquer xMo/s max en UDP ne leur dira probablement rien et ils ne l'atteindrons jamais dans la réalité, alors qu'un tcp, ils peuvent l'atteindre dans les meilleurs conditions et de 'route' et d'optimisation.

(ceci montre encore que les réglages optimums tcp sont très dépendant de la condition 'moyenne' de routes fréquement utilisés, et que les réglages optimums sur 'route clean' ne sont probablement pas les meilleurs)

[vivien]

UDP sera le premier à 'jecter' au niveau des routeurs ayant un lien saturé, et bien que tcp devra peut être redemander la transmission de paquets perdus, si la route est vraiment trop saturée même pour du tcp seul, tcp aura au final le compte juste, et donnera probablement une meilleure valeur de perf que udp à cet instant de test.

Je n'ai jamais entendu parler de cela, tu aurais une source pour que je m'instruise ?

udp est rarement utilisé par les programmes de transfert couramment utilisés, pour vraiment donner une 'bonne' idée du débit max, c'est plus le test "tcp sur route clean" qui donnera une valeur de capacité max de la ligne vraiment significative pour les internautes
 Indiquer xMo/s max en UDP ne leur dira probablement rien et ils ne l'atteindrons jamais dans la réalité, alors qu'un tcp, ils peuvent l'atteindre dans les meilleurs conditions et de 'route' et d'optimisation.

TCP : impossible de fixer le débit (au pire on fixe un débit maximum a ne pase dépasser mais on ne peut fier de débit minimum

UDP : Jamais utiliisé pour tout ce qui demande du débit variable (exemple : transfert de ichier) car UDP ne peut fonctionner si on ne lui donne pas de vitesse. La vitesse d'émission est strictement égale au débit fixé (aprés les paquets ils passent ou pas c'est une autre histoire). Pour mes tests, je test en fesant varier le débit par pallier de 5 Mb/s afin de trouverl là ou il y a l e max de paquets recus (si je noie le destinataire sur un débit bien supéreieur, on a moins de paquets recus que si j'envoi 10% au de la des capacités de la ligne.

[willemijns]

c'est l'inverse


tu veux dire que udp est plus prioritaire que tcp ?
Faudra m'expliquer alors que je mette à jours mes cours, certe ancestraux, de protocol IP ...

http://www.linux-france.org/prj/inetdoc/securite/tutoriel/tutoriel.securite.destruction.dos.html
lis "udp flood"

[vivien]

De la même manière que pour le SYN flooding, l'attaquant envoie un grand nombre de requêtes UDP sur une machine. Le trafic UDP étant prioritaire sur le trafic TCP, ce type d'attaque peut vite troubler et saturer le trafic transitant sur le réseau.

[TITI]

Je viens de tester en envoyant un fichier sur un serveur dédié OVH (connexion : 100 mpbs) et un mutualisé (mediaplan ovh), et je suis limité à 1.2 Mo /sec...  (10 mpbs)

Le dédié n'est pas limité, il télécharge et envoi bien au delà vers d'autres destinations...

Limitation entre Neuf et OVH ? Ou quoi ?!

[Auré]

essayes plusieurs d'envoyer plusieurs fichiers en meme temps

Je suis monté à plus de 3.5 Mo/s hier en envoyant 2 fichiers.