La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
Adeli => Opérateurs grand public alternatifs => Espace technique internet Adeli => Discussion démarrée par: romduf le 16 avril 2012 à 11:18:09
-
Bonjour à tous,
Après plusieurs essais avec différents cables, voici enfin un bon test sur Marignieu qui vient juste d'être relié à la fibre :
(https://lafibre.info/images/adeli/201204_speedtest_romduf.png)
Merci encore au support super rapide de Adeli pour réaliser les tests. Nous avons quelques coupures internet appremment pas tres longues, mais la qualité est au rendez vous.
Romain Marignieu 01300
-
Le débit est top, le ping est assez étonnant.
Si tu pouvais faire le test en démarrant windows en "Mode sans échec avec prise en charge réseau (https://lafibre.info/tutoriels/windows-mode-sans-echec/)" cela permettrait peut-être d'améliorer le ping, certains firewall dégradent le ping.
Toujours pour mieux comprendre les problèmes de très haut débit, je serais intéressé par un test de téléchargement sur le serveurs ci-dessous.
Les résultats en bleu sont ceux d'un abonné Orange FTTH sur Toulouse. Le débit est fortement dégradé avec les noyaux linux < 3.0 avec Orange FTTH dès que le ping augmente.
Fichier de 1Gb (119 Mo) :
- http://m.testdebit.info/1000Mo.dat (http://m.testdebit.info/1000Mo.dat) => noyeau 3.2
1915 ko/s
- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat) => noyeau 3.0
1720 ko/s
- http://bouygues.testdebit.info/fichiers/1000Mo.dat (http://bouygues.testdebit.info/fichiers/1000Mo.dat) => noyeau 2.6.24
6.1mo/s
Fichier de 10Gb (1,2 Go) :
- http://m.testdebit.info/1000Mo.dat (http://m.testdebit.info/1000Mo.dat) => noyeau 3.2
1917 ko/s
- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat) => noyeau 3.0
1750 ko/s
- http://bouygues.testdebit.info/fichiers/1000Mo.dat (http://bouygues.testdebit.info/fichiers/1000Mo.dat) => noyeau 2.6.24
8.0mo/s
-
Salut Vivien
Voici le test effectué en mode sans échec (Xp sp3) :
(https://www.speedtest.net/result/1897277511.png)
En fait pas tres différent du précédant.
Par contre je rencontre un drole de probleme : j'ai installé une deuxieme carte réseau pour recevoir les flux vidéos sous vlc directement du boitier optique. Lorsque je branche cette deuxieme carte, j'ai une connexion erratique sous internet, qui se coupe parfois et reprend sans raison. Des que j'enleve le cable branche sur la deuxieme carte reseau tout semble fonctionner normalement ? Peut etre qq chose a parametrer dans les proxi du naviguateur ?
Enfin voici les resultats en download de tes fichiers (en Mo/s):
3.4
3.7
4.6
3.5
3.7
4.6
Romain
-
Il faut vérifier que tu n'as pas deux accès à Internet à la fois!
-
Il faut effectivement une règle de routage pour que les flux multicast soient envoyés vers la seconde carte réseau (avec une IP privée je suppose) et envoyer tout le reste sur la passerelle par défaut qui doit être celle de l’accès à internet.
-
Vivien, c'est un peu hors sujet, mais peux tu m'en dire un peu plus sur cet histoire de multicast ? Comment paramétrer ? Je suis plutot débutant. Tu peux aussi déplacer le sujet, ca pourrait en intéresser d'autres ! Merci
-
Salut Vivien
Voici le test effectué en mode sans échec (Xp sp3) :
(https://www.speedtest.net/result/1897277511.png)
En fait pas tres différent du précédant.
Par contre je rencontre un drole de probleme : j'ai installé une deuxieme carte réseau pour recevoir les flux vidéos sous vlc directement du boitier optique. Lorsque je branche cette deuxieme carte, j'ai une connexion erratique sous internet, qui se coupe parfois et reprend sans raison. Des que j'enleve le cable branche sur la deuxieme carte reseau tout semble fonctionner normalement ? Peut etre qq chose a parametrer dans les proxi du naviguateur ?
Enfin voici les resultats en download de tes fichiers (en Mo/s):
3.4
3.7
4.6
3.5
3.7
4.6
Romain
Comment avoir un speedtest à 93 méga en DL et des résultats de moins de 5 Mo/s sur les téléchargements de fichiers ??
Personnellement avec ma connexion kiwi, sur les 6 tests de téléchargements je suis à 10.2, 10.4, 10.0 et 10, 10.9, 10.9 (dans l'ordre donné par Vivien) soit environ le taquet de ma connexion, bien que dans mon parefeu (IpFire), il me donne du 12000 kb/s au même moment soit 11.7 Mo/s (mais ou passe ce qu'il manque !!)
(https://www.speedtest.net/result/1899802976.png)
Cdt
Nico
-
2 explications :
- testdebit.info est un serveur proche de Paris.
- SpeedTest utilise 4 connexions en // afin de diminuer les différents problèmes de montés en débit. Il est donc plus facile de voir la différence entre deux noyaux avec un seul téléchargement.
romduf et Larsouille, serait-il possible de faire un SpeedTest sur des serveurs sur Paris ?
Les 4 intéressants sont :
- Massy
- Aubervilliers
- Paris (par médiactive, pas l'autre)
- Clichy
peux tu m'en dire un peu plus sur cet histoire de multicast ? Comment paramétrer ? Je suis plutot débutant. Tu peux aussi déplacer le sujet, ca pourrait en intéresser d'autres ! Merci
Lionel à répondu et j'ai déplacé le post : https://lafibre.info/adeli-tv/recuperer-les-flux-tv-sur-pc/ (https://lafibre.info/adeli-tv/recuperer-les-flux-tv-sur-pc/)
-
Voilà les résultats depuis une box ITTOPCTV (sur le même réseau que nos clients)
Je fais un test depuis la box en mode terminal avec wget car avec firefox je n'ai pas la moyenne (cela oscille entre 8Mo/s et 15Mo/s)
Fichier de 10Gb (1,2 Go) :
- http://m.testdebit.info/1000Mo.dat (http://m.testdebit.info/1000Mo.dat) => noyau 3.2
Cela donne un ping de 9.5ms
localhost ~ # wget http://m.testdebit.info/1000Mo.dat (http://m.testdebit.info/1000Mo.dat) -O /dev/null
--2012-04-18 09:48:32-- http://m.testdebit.info/1000Mo.dat (http://m.testdebit.info/1000Mo.dat)
Résolution de m.testdebit.info... 194.158.118.250
Connexion vers m.testdebit.info|194.158.118.250|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1250000000 (1,2G) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[===========================================================================================================>] 1 250 000 000 13,2M/s ds 92s
2012-04-18 09:50:04 (12,9 MB/s)
Soit 103 Mbits/s (il rame un peu ce serveur en face....)
Pour celui-ci
Ping de 8.5 ms
- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat) => noyau 3.0
wget http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat) -O /dev/null
2012-04-18 09:54:16 (11,2 MB/s) - «/dev/null» sauvegardé [1250000000/1250000000]
bon celui aussi il rame.... il doit être limité à un port 100Mbs/s!
et le dernier
Ping de 8.3 ms
- http://bouygues.testdebit.info/fichiers/1000Mo.dat (http://bouygues.testdebit.info/fichiers/1000Mo.dat) => noyau 2.6.24
wget http://bouygues.testdebit.info/fichiers/1000Mo.dat (http://bouygues.testdebit.info/fichiers/1000Mo.dat) -O /dev/null
2012-04-18 09:56:52 (27,8 MB/s) - «/dev/null» sauvegardé [1250000000/1250000000]
Oh que c'est beau :) 222 Mbs/s :) (il faut aussi dire que la box est sur un port giga :) )
Donc il n'y a pas de problème de transit ni de problème de ITTOPCTV :)
Si vous n'avez pas les performances de notre petite ITTOPCTV, A ADELI , on vend aussi des ordinateurs Surpuissants, mais ils sont plus chers que nos box... c'est vrai je l'avoue :)
Quand je vois ces chiffres, on devrait la vendre plus cher notre ITTOPCTV :) Et nos concurrents ils sont ou?
Bon en voyant ces résultats, là je me suis dit, je n'arrive pas à aller jusqu'à saturation de la box , donc j'ai fait une essai depuis notre (GROS) serveur... (qui plafonne à 993Mo/s soit 7.9Gbs/s donc ce ne ne sera pas ce serveur qui limitera le débit)
wget -O /dev/null http://s4.adeli.fr/video//1000Mo.dat (http://s4.adeli.fr/video//1000Mo.dat)
2012-04-18 10:09:47 (44,4 MB/s)
Soit 355 Mbs/s (cool)
-
wget -O /dev/null http://s4.adeli.fr/video//1000Mo.dat (http://s4.adeli.fr/video//1000Mo.dat)
2012-04-18 10:09:47 (44,4 MB/s)
Soit 355 Mbs/s (cool)
Même un peu plus : 44,4 Mio/s = 44,4 x 8 x 1024 x 1024 / 1000000 = 372,5 Mb/s applicatif.
Wget affiche les débit en multiple de 1024 (j'ai vérifié) or les débits sont des multiples de 1000.
En-tête TCP : 20 octets + option timestamps activé par défaut (12 octets) => 32 octets
En tête IPv4 sans option : 20 octets
En-tête Ethernet : 14 octets + VLAN (4 octets) => 18 octets
On peut transporter au maximum 1448 octets de données utilisateur en TCP pour 1518 octets au niveau Ethernet.
On a donc un ratio de 1518/1448 soit 1,05
Le débit Ethernet est donc de 391 Mb/s.
-
Le calcul est faux, les en-tête Ethernet sont de 22 octets, j'ai oublié les 4 octets de CRC.
La bonne formule est sur Calculer le débit Applicatif à partir du débit brut (https://lafibre.info/tester-son-debit/calcul-du-debit/)
-
Il me semblait que ton calcul était bon!
-
Non :
En-tête Ethernet : 14 octets + VLAN (4 octets) => 18 octets
Il manque les 4 octets du CRC :
(https://lafibre.info/images/tuto/201204_Ethernet_Type_II.png)
-
Pourtant, l'ami corrector me répondait plus tôt :
Le débit Ethernet (10 M, 100 M, 1 G) est toujours un débit utile : il ne contient pas les préludes, les checksums et les blancs obligatoires entre les paquets!
Tu n'aurais donc bien que 14 ou 18 octets (selon VLAN tagging) dans ta trame Ethernet.
-
C'est à vérifier, disons que pour les blancs et le préude j'en suis sûr de chez sûr, et pour le checksum à 90 %...
-
Le débit est un débit utile sur la couche 1 du modèle OSI
Il est possible que la couche 1 ait de la détection ou correction d'erreur => ces checksums ne comptent pas pour le débit annoncé, le débit au niveau 2.
L'Ethernet est au niveau 2. Les CRC ne peuvent être inclus dans le débit annoncé, sinon le débit physique devrait augmenter en cas de petits paquets Ethernet (plus de CRC pour un même nombre de bit transmis sur le média). C'est donc une certitude que ces 4 CRC de l'adresse Ethernet ne sont pas inclus dans les 100 Mb/s.
Je pensais que les CRC au niveau 2 étaient optionnels (il n'est pas nécessaire d'en mettre au niveau 2 si il y en a au niveau inférieur) mais visiblement ce n'est pas le cas.
-
Ça me semble plutôt bancal comme explication, dans la mesure où la taille d'une trame Ethernet est variable.
Edit : d'après cette page (http://sd.wareonearth.com/~phil/net/overhead/), le CRC est bien inclus dans l'overhead du protocole Ethernet.
-
Je vais donner un exemple :
On considéré que les checksum ne font pas parti des 100 Mb/s.
- Si tu transmets des trames Ethernet de 64 octets, il va falloir rajouter des checksums de 4 octets tous les 64 octets soit 1563 octets de checksum tous les 100000 octets.
- Si tu transmets des trames Ethernet de 1500 octets, il va falloir rajouter des checksums de 4 octets tous les 64 octets soit 67 octets de checksum tous les 100000 octets.
Il faudra donc envoyer plus vite au niveau physique afin de transmettre en plus des 100 Mb/s les 1563 octets de checksum.
Pour moi, cela permet de dire avec certitude qu'ils sont comptabilisés dans les 100 Mb/s
-
Et encore un doc (http://www.scribd.com/doc/52729778/Ethernet-Throughput#) qui indique que le CRC (FCS) est inclus dans la trame Ethernet :
The Ethernet Frame comprises the IP Packet plus MAC header (MAC DA and MAC SA), Length/Type and FCS bytes. The number of error-free frames that can be sent over an Ethernet link represents the L2 throughput for that link
The Ethernet Frame Space comprises the Ethernet Frame plus IFG and Preamble bytes. The number of error-free frame-spaces that can be sent over an Ethernet link represents the L1 throughput for that link