La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Bouygues Telecom => 
5G/4G box Bouygues Telecom => Discussion démarrée par: Azurha le 17 mars 2017 à 16:55:25
-
Bonjour à tous, j'habite au milieu des champs,près d'une ville de 4500 habitans, avec une connexion adsl free de 6mbs et 40 secondes de ping (avec tout de même pas mal d'erreures). Ce qui était déjà très bien pour une ligne de 4.5km dont au moins 1.5 en l'air sur du très vieux câble.
J'ai depuis deux ou trois jours la 4gbox de bouygue. Je suis très satisfait :), j'ai 80mb/s en descente, 30-40 en montant et 35ms de ping avec nettement moins de problème de régularité de ping.
(https://lafibre.info/images/4g/201703_4gbox_azurha_1.jpg)
(https://lafibre.info/images/4g/201703_4gbox_azurha_2.jpg)
(https://lafibre.info/images/4g/201703_4gbox_azurha_3.jpg)
Ce qui est surprenant c'est que j'ai cette qualité à toute heure de la journée (je n'ai pas encore essayé en weekend).
La dessus j'ai quelques questions.
1°) Vous pouvez le voir sur la première photo n'est pas au top niveau esthétique^^, je vais devoir choisir une antenne extérieur, laquelle devrais-je acheter selon ? Si toute fois c'est possible, je voudrais m'orienter vers un modèle qui améliore le ping.
2°) Quand je télécharge des fichiers depuis ma seedbox via filezilla et en lançant un "ping -n 1000 www.free.fr" je plafonne à 8-10 mo/s tout en gardant un ping de 35ms environ (et avec une pointe à 1 secondes toutes les minutes environs...) Ce qui est très bien.
Je peux regarder les vidéos youtube en 4k sans devoir attendre une mise en buffer :)
Par contre ! je ne sais pas si ça vient de twitch, mais impossible de regarder mes streamers en qualité source. La vidéo se coupe toutes les 10 secondes pour se mette en tampon. ce qui est très étrange, c'est que pendant ce temps je vois bien mon "ping -n 1000 www.free.fr" m'indiquer une très forte hausse du ping, du genre entre 1 et 3 secondes Oo. Et dès que je coup twitch ça marche tout seul. ça me fait ça quand je regarde depuis chrome ou une appli windows. Avez vous une idée ?
PROBEME RESOLU grâce à Iwan avec ce lien : https://developers.google.com/speed/public-dns/
Il faut aussi spécifier la passerelle par défaut qui va bien (192.168.1.1 de base)
Voilà, dsl pour le pavé, j'ai au moins essayé d'être clair ^^.
Merci de m'avoir lu.
-
Vu tes débits tu captes très bien.
Je ne pense pas qu'une antenne te permette d'avoir beaucoup mieux..
Idem pour le ping. Je ne pense pas que tu descendra plus bas.
Pour twich, ca te le fais n'importe quand ou uniquement le soir ?
-
Oui, je viens d'essayer encore. En fait même en qualité moyenne le ping monte à 350ms, c'est vraiment très étrange. 9a le fait aussi sous le navigateur EDGE
-
essayez de changer de server twitch, ils ne semblent pas tous se valoir.
Vous pouvez faire un test de streaming en rajoutant ?bandwidthtest=true après votre streamkey dans OBS par example
Trouvez un server qui tient le coup avec 0% de dropped frames (celui de milan semble très bon, il a dailleurs un bien meilleur ping que celui de paris)
-
essayez de changer de server twitch, ils ne semblent pas tous se valoir.
Vous pouvez faire un test de streaming en rajoutant ?bandwidthtest=true après votre streamkey dans OBS par example
Trouvez un server qui tient le coup avec 0% de dropped frames (celui de milan semble très bon, il a dailleurs un bien meilleur ping que celui de paris)
Attention, je ne suis pas streamer, je parle de regarder des stream :)
En ce moment ça va mieux, j'ai 30 secondes de buffer, donc je peux regarder sans coupures. Cela dit le ping reste nettement moins stable que quand je dl à fond via filezilla alors que le tream demande nettement moins de bande passante, c'est très étrange.
(https://lafibre.info/images/4g/201703_4gbox_azurha_4.jpg)
-
et si vous basculez en public DNS sur votre carte réseau?
ça peut paraitre idiot mais ça a résolu pas mal de mes problèmes de lenteur et de timeout (bien avant d'avoir une 4Gbox) avec tout un tas de sites (google et ses dérivés en tête).
https://developers.google.com/speed/public-dns/
-
et si vous basculez en public DNS sur votre carte réseau?
ça peut paraitre idiot mais ça a résolu pas mal de mes problèmes de lenteur et de timeout (bien avant d'avoir une 4Gbox) avec tout un tas de sites (google et ses dérivés en tête).
https://developers.google.com/speed/public-dns/
Effectivement, le ping est nettement plus stable, il reste une pointe à 500ms toutes les 15 secondes qui n'existe pas quand je télécharge bien plus fort mais c'est déjà mieux, merci :)
Il reste mes hésitations sur le choix d'une antenne.
Merci encore.
-
Pour la pointe à 500ms je ne sais pas, pour me part j'ai un débit bien inférieur au votre (antenne 800mhz) mais le ping est ultra stable (entre 30 et 55ms même après 200 pings - j'ai arrêté ensuite).
-
Pourquoi faire un ping vers Free.fr ? même si l'interconnexion avec Bouygues doit aller, Free n'est pas le FAI avec le réseau le moins sujet à saturation.
Le mieux serait de faire soit un ping vers le site de bouygues, ou un site distant (google, twich, lafibre.info et etc ... )
-
Je peut expliquer l'augmentation du ping : quand tu satures ta connexion, des buffers se remplissent sur le réseau mobile avec tous les paquets en attente. Le ping augmente.
Twitch evoit les paquets a un débit de 1 Gb/s par burst, donc les buffer se remplissent rapidement et qui se vident quand twitch n’envoie plus de données.
Avec une èmetteur qui ne sature pas ta connexion, le ping va rester faible, car les buffers ne seront pas remplis.
Normalement avec Youtube en HD tu devrais avoir le même pb d'augmentation des buffer qu'avec twitch.
-
J'ai un problème de latence aussi sur chrome en regardant des vidéos youtube, sur firefox je n'ai pas ce problème.
Je suis connecté sur le serveur DNS de mon synology.
-
Pourquoi faire un ping vers Free.fr ? même si l'interconnexion avec Bouygues doit aller, Free n'est pas le FAI avec le réseau le moins sujet à saturation.
Le mieux serait de faire soit un ping vers le site de bouygues, ou un site distant (google, twich, lafibre.info et etc ... )
J'ai pris free.fr par hasard, par habitude. Maintenant j'essaie avec google.
Je peut expliquer l'augmentation du ping : quand tu satures ta connexion, des buffers se remplissent sur le réseau mobile avec tous les paquets en attente. Le ping augmente.
Twitch evoit les paquets a un débit de 1 Gb/s par burst, donc les buffer se remplissent rapidement et qui se vident quand twitch n’envoie plus de données.
Avec une èmetteur qui ne sature pas ta connexion, le ping va rester faible, car les buffers ne seront pas remplis.
Normalement avec Youtube en HD tu devrais avoir le même pb d'augmentation des buffer qu'avec twitch.
Non, je n'ai pas ce problème avec youtube, et je n'ai pas de soucis lorsque filezilla sature ma connexion, d'ailleurs twitch est TRES loin de saturer ma connexion. En règle générale il a besoin de 6Mb/s pour fonctionner correctement, et j'en ai environ 80.
-
En règle générale il a besoin de 6Mb/s pour fonctionner correctement, et j'en ai environ 80.
6 Mb/s en moyenne, mais en réalité ce sera ton débit maximum pendant quelques secondes puis plus rien, puis de nouveau débit max pendant quelques secondes.
J'ai un problème de latence aussi sur chrome en regardant des vidéos youtube, sur firefox je n'ai pas ce problème.
Youtube sur Chrome est en IP + UDP + QUIC.
Youtube sur les autres navigateurs est en IP + TCP.
Explications sur Quic qui sera dans quelques années intégré a une nouvelle version de TCP :
https://www.youtube.com/watch?v=hQZ-0mXFmk8
En TCP/IP, la couche 4 est géré par le système d’exploitation et donc pas souvent mis à jour (il reste encore de nombreux Windows XP).
En UDP/QUIC, la couche 4 est géré par le navigateur et donc mis à jour de façon très régulière, ce qui lui permet de profiter des dernières amélioration.
Google veut accélérer Internet avec QUIC
QUIC (Quick UDP Internet Connections, prononcé 'quick' NdT : 'couic' en français) est un protocole de transport multiplexé au dessus d'UDP avec comme but principal de ne pas ajouter de délai de connexion supplèmentaire.
Robbie Shade, un Développeur de Google, a introduit QUIC dans une vidéo récente, avec comme avantages principaux :
- Tous les avantages de SPDY (multiplexage, priorités, etc.)
- Connexions sans délai supplèmentaire
- Régulation de la vitesse d'émission de paquets pour diminuer les pertes
- Propagation de la correction d'erreurs pour réduire les latences de retransmission
- Gestion de congestion adaptative (proche de TCP), diminuant les reconnexions pour les clients mobiles
- Chiffrement équivalent à TLS
- Chrome peut communiquer avec Google par QUIC dès aujourd'hui
QUIC gère la retransmission, les paquets manquants ou dans le désordre, quelque chose qu'UDP ne fait pas par défaut. Le multiplexage dans QUIC siginifie que le protocole utilise plusieurs canaux pour envoyer les données, donc si un paquet est perdu dans un des flux de données, les autres ne sont pas bloqués en attente de celui-ci, comme c'est le cas pour SPDY, qui fait du multiplexage mais sur un seul canal. Cette approche dans QUIC résoud le problème de Head-of-line blocking (blocage d'un ensemble de paquets en attente du premier) qui peut arriver durant les retransmissions TCP, d'après Shade.
Un des bénéfices majeurs de l'utilisation de QUIC est le fait qu'il ne requiert pas de phase de handshake au premier contact entre le client et le serveur, d'une façon plus ou moins proche de TCP Fast Open, qui a été en discussion depuis 2011 mais n'a pas connu de large adoption. Selon Shade, le handshake TCP peut prendre jusqu'à 300 ms sur une connexion transatlantique si TLS est utilisé, alors que QUIC peut réduire cette latence à 100 ms.
Un autre avantage de QUIC est que les canaux de communication ne sont pas définis par le couple IP+port mais par un ID, ce qui permet de continuer une connexion même en changeant de réseau, par exemple quitter une zone Wi-Fi et entrer dans le réseau mobile.
Toutes les connexions QUIC sont chiffrées selon un mécanisme spécifique détaillé dans le QUIC Crypto document.
Quand on lui demande pourquoi ne pas utiliser une version améliorée de TCP + TLS, Shade répond que tandis que TCP et TLS subissent des améliorations, les itérations du protocole et leur déploiement sont très lents, alors que QUIC est déployé au niveau client et non au niveau du noyau, permettant des itérations beaucoup plus rapides - "des semaines plutôt que des années".
D'après Shade, SPDY peut fonctionner au dessus de QUIC dans le futur, le rendant encore meilleur qu'actuellement. Certaines des leçons apprises et testées par Google en pratique avec QUIC pourraient se retrouver dans TCP dans le futur.
Actuellement, il y a un client et un serveur disponible dans Chromium, et QUIC est utilisé par google.com, GMail, YouTube, et d'autres services Google.[/size]
Source : InfoQ (http://www.infoq.com/fr/news/2014/04/quic) le 15 avr. 2014 par Olivier Bourgain
-
A l'occasion d'une mise à jour d'un jeu je me rend compte qu'il y'a (un peu) le même problème sur steam. Le débit est de 8/9 MB/s ce qui provoque une montée du ping à 350ms.
Ca ne me choque pas en soit, je trouve ça même très logique, mais je ne comprend pas pourquoi ça ne le fait pas avec filezilla, différence de protocole ?
-
Problème entièrement résolu pour ce qui est du stream et de certain DL.
En plus de mettre les DNS qui vont bien (8888 8844), ce qui avait déjà atténué les soucis j'ai rajouté une passerelle par défaut (192.168.1.1 du coup) et tout fonctionne bien maintenant :D
-
C'était bien QUIC, en TCP je n'ai plus de problème sur chrome.
Je me demande pourquoi l'overthebox à du mal avec l'UDP.
Est-ce à cause des paquets invalides qui peuvent survenir ?
-
OVH utilise TCP-MP, pour UDP, il me semble que ce n'est pas loadbalancé.
-
OVH utilise TCP-MP, pour UDP, il me semble que ce n'est pas loadbalancé.
Ils utilisent UDP Glorytun apparemment.
-
C'était bien QUIC, en TCP je n'ai plus de problème sur chrome.
Je me demande pourquoi l'overthebox à du mal avec l'UDP.
Est-ce à cause des paquets invalides qui peuvent survenir ?
Comment fais tu pour changer ça ?
-
http://lmgtfy.com/?q=disable+quic ?
-
Alors après essai ça marche moins bien avec QUIC désactivé. j'ai remis sur "par défaut" du coup.
-
Youtube sur Chrome est en IP + UDP + QUIC.
Pas tout le temps ! Sur Ubuntu avec la version fournie j'ai eu à l'activer dans les flags (http://"chrome://flags/#enable-quic"). Et ce serait surprenant que Google active un protocole expérimental par défaut sur toutes les sessions ;)