Apprenti
•
84 messages
Pertes de connexion et latence aléatoire
Bonjour,
Voila plusieurs mois (des dizaines de mois) que nous avons des problèmes de connexion, que ce soit filaire ou wifi.
Des techniciens sont déjà venus changer le modem (Netgear->Technicolor), vérifier le signal au poteau, vérifier le signal à l’ampli et enfin l’ampli (il aura quand même fallu 2 techniciens pour se rendre compte que l’ampli était mort et faisait le boulot inverse).
Malgré tout cela, nous avions toujours des soucis, c’est pourquoi mon père a décider de vous contacter via Facebook. Après avoir essayé de régler les soucis avec les opérateurs VOO pendant plusieurs jours, j’ai décidé de me pencher sur le problème car à part répéter en boucle les mêmes “techniques” comme reboot/reset du modem (ok si c’était occasionnel mais demander de redémarrer le modem à chaque fois, faites un historique des propositions alors svp….
), changer de canal (AH monsieur vous êtes en canal fixe, mettez le en auto ! Et pourquoi croyez vous qu’il est en fixe ? Peut-être parce qu’en auto c’est encore plus instable non ? ESSAYEZ MONSIEUR !! 
), je passe tout le reste..
Voila donc plus d’une semaine que j’analyse mon réseau wifi ainsi que le filaire au moyen de Netspot, Speedtest et tests de ping et de recherches. Je ne fais qu’exposer mon analyse, je serais ravi que vous me donniez des informations sur mes (mauvaises?) interprétations et observations.
J’ai pu remarquer que lorsque le Rx de la majorité des canaux montait au dessus de +10dBmV nous avions plus de soucis, en effet quand il fait plus froid ou lorsqu’il y a des intempéries, nous avons plus de déconnexions (VOO.évasion, smartTV en wifi/RJ-45 et smartphones) ou de montée de ping.
Je sais cependant que le Technicolor accepte -15/+15 (tout comme la norme DOCSIS QAM256) mais plutôt que de se baser sur les valeurs maximales, je préfère rappeler que la valeur optimale dans ce cas est 0. Il y a aussi un léger changement de valeur Tx.
Le plus de problèmes:
Un peu de problèmes:
Moins de problèmes:
En connexion filaire, je dois dire que nous avons un débit presque parfait, cependant lorsque nous avons des problèmes de déconnexions intempestives sur le wifi, les tests de ping en filaire montrent un nb plus élevés de ping à +100ms (<1ms normalement). Les pings effectués en wifi sont eux variables entre 30ms et 180ms également (+-5ms normalement).
Il y a une dizaine d’appareils connectés au modem dont ± la moitié par wifi.
Exemple connexion wifi normale (que j’ai obtenu après les chgmts des 3$ suivants):
Le temps d’analyser un maximum de données, j’ai essayé de rendre mon réseau le plus stable possible. J’ai donc remarqué qu’en désactivant le routage ipV6 ainsi que le réseau 5GHz, nous avions déjà beaucoup moins de déconnexion sur le wifi ! Voir même plus du tout, du moins, ce type de déconnexion (connecté au wifi mais plus d’accès internet).
J’en ai profité pour mettre les sécurités un poil plus strictes en désactivant la sécurité WPA-PSK et le chiffrement TKIP pour être uniquement en WPA2-PSK chiffrement AES. J’ai également désactivé le partage uPnp. Le pare-feu est réglé en moyen sans filtres d’activés.
Concernant le wifi 2.4GHz il a été réglé comme suit car c’est pour moi les réglages les plus optimaux dans notre cas:
J’ai désactivé le 5GHz et j’ai cru m’apercevoir que la connexion du 2.4 était meilleure. Comme le 5GHz n’est déjà pas très stable à distance et avec les soucis que nous avons, je préfère le laisser désactivé pour le moment. Cependant, j’ai réglé l’interface comme suit:
J’ai également pu remarquer des erreurs à différents endroits:
Si vous vous demandez pourquoi je dis que le mode auto canal est pourri, regardez ceci et comparez le nb de réseaux détectés avec les screen ici dessous.
C’est tout ce que j’ai pu analyser sur l’interface du modem, si vous voulez d’autres informations n’hésitez pas à me le demander.
Je me suis également pencher sur les réseaux wifi qui m’entourent et je dois dire que c’est à ce niveau que je me pose le plus de questions.
En effet, j’ai pu m’apercevoir qu’assez régulièrement, le bruit de mon signal wifi était presque exactement le même que celui d’un wifi voisin VOO.
Et que ceux-ci avaient l’air d’être tiré par un autre réseau wifi voisin:
Voici l’état de la connexion dans ce cas:
Voici un autre exemple, datant d’hier, remarquez également que le RSSI de mon réseau tourne habituellement [-40 - -48] et que lorsque les bruits se synchronisent comme cela je passe à [-48 - -60]:
Un aperçu de mon réseau lorsqu’un maximum de wifi interfèrent (j’en ai cependant rarement autant de captable):
Les problèmes de déconnexions étaient déjà la avant l’arrivée de ceux-ci mais j’ai également 2 Devolo à la maison.
Le premier est un Devolo Magic (wifi_Chambre) qui va à l’étage ou n’est connecté qu’un pont Hue (j’ai désactivé le wifi récemment pour éviter un maximum d’interférences).
Le second est un Devolo VOO Wifi également qui comme son nom l’indique (Wifi_Cuisine) est dans la cuisine car la réception du wifi à cet endroit est déjà pourrave.
Je n’ai cependant pas encore pris le temps de savoir si je pouvais les synchroniser entre eux, l’interface VOO/Devolo ne me donnent pas du tout envie.
J’ai pu remarquer que parfois, un bruit instable passait du réseau VOO à celui des Devolo. Ce qui rendait le signal VOO complètement stable et celui des Devolo complètement instable. Ceux-ci sont chacun réglés en canal fixe (12).
Je ne retrouve malheureusement rien pour illustrer ceci, je me dis que ça pourrait venir du réseau Proximus qui étant d'abord en interférence avec mon réseau sur le canal 6 crée un bruit irrégulier et comme ce réseau est en automatique, en passant sur un canal interférant le 12, crée à nouveau du bruit sur les Devolo au moment ou le bruit sur mon réseau devient stable.
Voila à peu près où j’en suis arrivé… J’espère que quelqu’un pourra trouver une ou plusieurs explications et solutions à mes observations et surtout sur celles-ci:
- Routage du modem à chier lors du routage ipV4/ipV6
- Bruit aléatoire et instable sur le réseau wifi
- Erreurs critiques du modem
- Erreur d’attribution d’adresse ip
- Rx élevé ? Quid du Tx,..?
- Perte de qualité réseau lors d’intempéries = câblage extérieur en bon état ??
Je fais ceci dans le but de trouver une solution à la source, je me doute bien que l’achat d’un routeur digne de ce nom pourra m’aider à avoir un meilleur signal wifi, je pense cependant que le problème ne vient pas uniquement du wifi car nous avons aussi des problèmes de latence par RJ-45 (test de ping sur routeur <1ms et test de ping sur serveur Google qui varie entre 30 et 50ms en faisant des bons à +100ms…
De plus, je vois d’ici les opérateurs/techniciens VOO nous dire “AH MAIS MONSIEUR je vois que vous avez un routeur connecté au modem VOO, le problème vient peut-être de la, essayez de le débrancher et de repasser le modem VOO en mode routage.” !
J’aimerais donc trouver une solution avant de faire cet achat. Achat de toute facon prévu d’ici fin d’année car nous passerons en 400Mbp le mois prochain. Raison de plus de vouloir avoir un signal parfait. Si c’est pour avoir 400Mbp avec latence et déco, Proximus et leurs 85Mbp max nous suffiront amplement en attendant qu’ils nous mettent la fibre…
SVP essayez de chercher une autre solution que simplement dire de “changer le modem” même si ça peut faire partie de cette solution. Comme dit au début, beaucoup de choses ont été changées.
UN GRAND MERCI à tous ceux qui prendrons le temps de lire et de trouver des réponses.
PS: Voici une semaine qu’on a demandé pour désactiver le Homespot, ce qui n’a toujours pas été fait. La demande a été refaite par téléphone ce vendredi.
DDA
Expert
•
3K messages
il y a 4 ans
Diminuer votre bande à 20 Mhz fixe ?
0
0
sokax
Apprenti
•
84 messages
il y a 4 ans
@DDA les réglages sont mis dans le premier message, déjà fait également.
0
0
DDA
Expert
•
3K messages
il y a 4 ans
@DDA les réglages sont mis dans le premier message, déjà fait également.
Ben oui, en 40Mhz fixe, ou alors j’ai mal compris …
Je vous cite :
Quand il y a des perturbation, je vais abandonner la vitesse pour obtenir quelque chose de plus stable moins vite, en fixant à 40 Mhz, c’est la vitesse qui sera privilégiée
0
0
sokax
Apprenti
•
84 messages
il y a 4 ans
@DDA Vous avez en effet mal compris, ce sont les paramètres du 5GHz là, d’ailleurs désactivé comme on peut le voir au canal courant vide. Ceux du 2.4 sont juste avant les paramètres de sécurité.
Soit:
0
0
DDA
Expert
•
3K messages
il y a 4 ans
Oui, je l’avais vu et mal compris la suite du fait d’avoir désactivé le 5 Ghz … autant pour moi
0
0
sokax
Apprenti
•
84 messages
il y a 4 ans
Je viens d’aller refaire un tour dans le modem et je viens de voir ceci:
Hmmmm wtf ?
C’est à cause du changement du délai de bail DHCP sans avoir redémarré le modem ou ça provient de l’erreur DHCP ci-dessus ?
Je ne saurais pas dire depuis quand c’est comme ça.
Encore tout à l’heure lorsque j’ai créé le sujet, il n’y avait aucune IP statique.
0
0
roylion15
Top Expert
•
41.5K messages
il y a 4 ans
Vous confondez dhcp wan et lan , les événements c’est le wan et le réglage dhcp de tout à l’heure c’est sur le lan pour vos appareils…
sûrement parce que vous avez fait le réglage à 2 jours alors il indique n’importe quoi car durée plus longue que dhcp anormale, un bug qui se soigne effectivement par un cool reboot du modem à mon avis
0
sokax
Apprenti
•
84 messages
il y a 4 ans
sûrement parce que vous avez fait le réglage à 2 jours alors il indique n’importe quoi car durée plus longue que dhcp anormale, un bug qui se soigne effectivement par un cool reboot du modem à mon avis
Je ne sais pas de trop, il est vrai que de ce coté la, je n’y connais pas grand chose.
J’ai essayé de reconnecter mon smartphone au WIFI vers 00h20.
Un bail lui a donc été attribué.
J’essaye la même chose 10min plus tard avec mon portable et pareil, il obtient le bail.
Je viens d’aller recheck et il n’y en avait plus aucun. Ils étaient repassés en IP statique (à cause de leur innactivité ?) sans date d’expiration.
Lorsque j’ai été sur mon smartphone et de nouveau réactivé (déco-reco) le wifi, celui-ci est réapparu dans la liste avec une nouvelle date d’expiration au lieu de *** Adresse IP Statique *** et remplaçant son ancien bail. Le Macbook est, lui aussi réapparu.
Tant que la ligne est correcte, je préfère ne pas redémarrer le modem actuellement.
Je verrais la situation demain et effectuerais le reboot avant de revenir vers vous.
0
0
roylion15
Top Expert
•
41.5K messages
il y a 4 ans
bien vite le routeur parce que si voulez trouver des bugs ou bizarreries dans l’interface , vous n’avez pas encore fini. ?
0
0
sokax
Apprenti
•
84 messages
il y a 4 ans
Bonjour à tous,
En reparcourant mes screenshots, je me suis aperçu que les valeurs Tx avaient tendance à être assez différentes suivant le signal Rx des canaux descendants.
Je ne sais pas si ça peut réellement avoir un impact sur la connexion dans un cas ou un autre.
Les différentes données dates entre le 06 et le 11/11.
Je ne dis pas que c’est un problème, je ne sais pas. Je constate et pose la question.
Je veux vraiment que ça bouge cette fois.
J’attends donc l’avis d’un officiel sur l’ensemble de ce sujet.
@roylion15 si même ce n’est en effet que des bugs, c’est malgré tout dommage. Même les clients qui voudraient y comprendre quelque chose ne pourraient pas.
Depuis le temps que ce modem existe, c’est quand même dommage tous ces bugs. Un peu le même constat que pour la VOO.evasion au final.
0
0
roylion15
Top Expert
•
41.5K messages
il y a 4 ans
Ce n’est pas un problème … si le RX monte, le TX a la tendance inverse , les variations de la température extérieure en sont la cause et c’est normal.
Une mise à jour prochaine devrait résoudre certains bugs gênants et améliorer la stabilité mais bon cela dépend du bon vouloir du fabricant Technicolor aussi et non de VOO uniquement.
0
sokax
Apprenti
•
84 messages
il y a 4 ans
De nouveau, après une journée parfaite (vitesses supérieures aux valeurs annoncées).
Voila que, sans réelle raison, le wifi se voit baisser drastiquement de qualité.
Ceci a été fait par wifi, on peut également remarquer le test de pings très variable + le ping perdu:
Et un second effectué 10min plus tard, le signal a repris un peu malgré une baisse de vitesse sur la fin, comme dans les ¾ du temps lors de tests wifi actuellement chez moi:
Je n’ai pas regardé à l’instant T mais tous les canaux montants et descendants du modem sont dans les mêmes valeurs que dans les tableaux ci-dessus.
Le speedtest réalisé par RJ-45 est quant à lui un peu moins bon que normalement avec une courbe de montée moins franche et un débit maximum de 111Mbps.
Les résultats étant 8ms de ping, 109.51Mbps en down et 6,87 en upload.
Et de nouveau, je reviens sur cette histoire de bruit:
Aujourd’hui, tous les signaux wifi ont un bruit stable.
Tous, sauf 2. Mon wifi (VOO-013256) + le wifi voisin (VOO-386550), le Devolo branché dans notre cuisine à quant à lui un bruit totalement stable.
Comment expliquer cette différence ? Y-a-t-il une crasse sur le réseau VOO vu l’exactitude entre les bruits émis sur les 2 wifi ?
(je n’ai affiché que les signaux concernés pour plus de clarté)
0
0
mikL
Top Expert
•
3.6K messages
il y a 4 ans
En tant normal le TX ne bouge pas avec les changements de température.
Si le TX bouge fortement avec les changements de température ça veut dire qu'il y a un défaut dans la ligne. Quand je dis fortement c'est plus de 5 dB.
Les changements de température ici n'affecte pas votre signal car ce n'est que de 2 dB, aussi bien sur le RX que le TX.
0
sokax
Apprenti
•
84 messages
il y a 4 ans
Merci@mikL pour la réponse.
J’ai effectué plusieurs tests de pings en wifi et ils arrivent tous à peu près au même schéma..
MacBook-Pro-de-Florian-2:~ joasflo$ ping -c 50 -s 68 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 68 data bytes
76 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=40.815 ms
76 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=22.875 ms
76 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=33.961 ms
76 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=34.785 ms
76 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=27.659 ms
76 bytes from 8.8.8.8: icmp_seq=5 ttl=52 time=60.207 ms
76 bytes from 8.8.8.8: icmp_seq=6 ttl=52 time=113.321 ms
76 bytes from 8.8.8.8: icmp_seq=7 ttl=52 time=124.502 ms
76 bytes from 8.8.8.8: icmp_seq=8 ttl=52 time=78.400 ms
76 bytes from 8.8.8.8: icmp_seq=9 ttl=52 time=73.747 ms
76 bytes from 8.8.8.8: icmp_seq=10 ttl=52 time=164.459 ms
76 bytes from 8.8.8.8: icmp_seq=11 ttl=52 time=157.293 ms
76 bytes from 8.8.8.8: icmp_seq=12 ttl=52 time=153.442 ms
76 bytes from 8.8.8.8: icmp_seq=13 ttl=52 time=161.350 ms
76 bytes from 8.8.8.8: icmp_seq=14 ttl=52 time=106.662 ms
76 bytes from 8.8.8.8: icmp_seq=15 ttl=52 time=103.198 ms
76 bytes from 8.8.8.8: icmp_seq=16 ttl=52 time=114.125 ms
76 bytes from 8.8.8.8: icmp_seq=17 ttl=52 time=108.362 ms
76 bytes from 8.8.8.8: icmp_seq=18 ttl=52 time=127.916 ms
76 bytes from 8.8.8.8: icmp_seq=19 ttl=52 time=52.659 ms
76 bytes from 8.8.8.8: icmp_seq=20 ttl=52 time=95.704 ms
76 bytes from 8.8.8.8: icmp_seq=21 ttl=52 time=14.506 ms
76 bytes from 8.8.8.8: icmp_seq=22 ttl=52 time=14.202 ms
76 bytes from 8.8.8.8: icmp_seq=23 ttl=52 time=24.862 ms
76 bytes from 8.8.8.8: icmp_seq=24 ttl=52 time=42.081 ms
76 bytes from 8.8.8.8: icmp_seq=25 ttl=52 time=47.045 ms
76 bytes from 8.8.8.8: icmp_seq=26 ttl=52 time=51.885 ms
76 bytes from 8.8.8.8: icmp_seq=27 ttl=52 time=52.488 ms
76 bytes from 8.8.8.8: icmp_seq=28 ttl=52 time=14.566 ms
76 bytes from 8.8.8.8: icmp_seq=29 ttl=52 time=16.172 ms
76 bytes from 8.8.8.8: icmp_seq=30 ttl=52 time=40.020 ms
76 bytes from 8.8.8.8: icmp_seq=31 ttl=52 time=43.575 ms
76 bytes from 8.8.8.8: icmp_seq=32 ttl=52 time=21.201 ms
76 bytes from 8.8.8.8: icmp_seq=33 ttl=52 time=18.519 ms
76 bytes from 8.8.8.8: icmp_seq=34 ttl=52 time=15.129 ms
76 bytes from 8.8.8.8: icmp_seq=35 ttl=52 time=16.338 ms
76 bytes from 8.8.8.8: icmp_seq=36 ttl=52 time=20.596 ms
76 bytes from 8.8.8.8: icmp_seq=37 ttl=52 time=25.350 ms
76 bytes from 8.8.8.8: icmp_seq=38 ttl=52 time=184.010 ms
76 bytes from 8.8.8.8: icmp_seq=39 ttl=52 time=122.397 ms
76 bytes from 8.8.8.8: icmp_seq=40 ttl=52 time=171.553 ms
76 bytes from 8.8.8.8: icmp_seq=41 ttl=52 time=145.152 ms
76 bytes from 8.8.8.8: icmp_seq=42 ttl=52 time=14.847 ms
76 bytes from 8.8.8.8: icmp_seq=43 ttl=52 time=22.166 ms
76 bytes from 8.8.8.8: icmp_seq=44 ttl=52 time=34.120 ms
76 bytes from 8.8.8.8: icmp_seq=45 ttl=52 time=15.370 ms
76 bytes from 8.8.8.8: icmp_seq=46 ttl=52 time=16.047 ms
76 bytes from 8.8.8.8: icmp_seq=47 ttl=52 time=38.207 ms
76 bytes from 8.8.8.8: icmp_seq=48 ttl=52 time=18.945 ms
76 bytes from 8.8.8.8: icmp_seq=49 ttl=52 time=18.389 ms
--- 8.8.8.8 ping statistics ---
50 packets transmitted, 50 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.202/64.704/184.010/52.279 ms
MacBook-Pro-de-Florian-2:~ joasflo$ ping -c 50 -s 512 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 512 data bytes
520 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=49.064 ms
520 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=84.219 ms
520 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=3.506 ms
520 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=4.702 ms
520 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=3.669 ms
520 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=19.960 ms
520 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=1.582 ms
520 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=1.540 ms
520 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=9.216 ms
520 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=2.978 ms
520 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=2.546 ms
520 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=17.845 ms
520 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=243.010 ms
520 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=123.838 ms
520 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=263.581 ms
520 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=132.685 ms
520 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=1.972 ms
520 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=9.579 ms
520 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=2.758 ms
520 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=10.404 ms
520 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=2.841 ms
520 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=10.486 ms
520 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=2.620 ms
520 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=2.719 ms
520 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=3.316 ms
520 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=15.077 ms
520 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=12.137 ms
520 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=40.598 ms
520 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=47.078 ms
520 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=73.343 ms
520 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=5.812 ms
520 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=1.776 ms
520 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=11.951 ms
520 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=6.865 ms
520 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=2.436 ms
520 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=127.738 ms
520 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=2.534 ms
520 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=10.412 ms
520 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=1.704 ms
520 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=1.651 ms
520 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=62.226 ms
520 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=117.024 ms
520 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=99.074 ms
520 bytes from 192.168.0.1: icmp_seq=43 ttl=64 time=6.217 ms
520 bytes from 192.168.0.1: icmp_seq=44 ttl=64 time=11.164 ms
520 bytes from 192.168.0.1: icmp_seq=45 ttl=64 time=12.424 ms
520 bytes from 192.168.0.1: icmp_seq=46 ttl=64 time=18.458 ms
520 bytes from 192.168.0.1: icmp_seq=47 ttl=64 time=1.689 ms
520 bytes from 192.168.0.1: icmp_seq=48 ttl=64 time=1.666 ms
520 bytes from 192.168.0.1: icmp_seq=49 ttl=64 time=1.792 ms
--- 192.168.0.1 ping statistics ---
50 packets transmitted, 50 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.540/34.070/263.581/58.051 ms
J’ai également effectué des tests de pings en RJ-45 venant de plusieurs connexions différentes.. On retrouve quelques pings plus élevés mais seulement légèrement visible (ici, lors du test directement sur le modem). Les montées aléatoire de pings en RJ-45 (notamment sur le modem) s’amplifient lorsqu’il y a un mauvais débit.
Envoi d’une requête 'Ping' 8.8.8.8 avec 512 octets de données :
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=18 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=28 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=12 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=16 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=16 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Statistiques Ping pour 8.8.8.8:
Paquets : envoyés = 50, reçus = 50, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 12ms, Maximum = 28ms, Moyenne = 14ms
C:\Users\Flo>ping -n 50 -l 512 192.168.0.1
Envoi d’une requête 'Ping' 192.168.0.1 avec 512 octets de données :
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=12 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=1 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=6 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=3 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Statistiques Ping pour 192.168.0.1:
Paquets : envoyés = 50, reçus = 50, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 12ms, Moyenne = 0ms
Pourrions-nous en tirer une signification ?
Je fais attention d’effectuer ces tests en utilisant un minimum le réseau.
Cependant, lors de l’utilisation de Netflix, de la TV numérique, de streamings (d’un minimum de bande passante en somme), aurais-je également une montée de ping si j’interroge le modem ou un serveur externe comme ici ?
Qui, du coup, pourrait provoquer ce genre de temps de réponse et dans mon cas pourrait l’amplifier ?
Ou pas du tout ?
Depuis hier soir (tard), et plus souvent aujourd'hui, il m’arrive également d’avoir une “page inaccessible” lorsque je tente d’accéder au modem. Ca m’est arrivé plusieurs fois en 1h cette après-midi puis plus rien. Tant que j’y suis, je transmet l’info.
(mon sujet est en train de tourner un peu en un FAQ, j’en suis désolé, mais c’est peut-être ces questions qui me permettront d’être plus compréhensible avec les futurs techniciens qui viendront à domicile et les opérateurs si de nouveaux problèmes venaient à resurgir)
0
0
roylion15
Top Expert
•
41.5K messages
il y a 4 ans
Hello
Je vous réponds brièvement encore ?
Je ne comprends pas trop ce que vous tentez de démontrer avec vos tests ? Le mauvais wifi ou un problème de connexion filaire ?
je vois pas trop ?
Aussi pourquoi mettre ce paramètre pour tester avec des paquets plus importants de 512 octets dans vos Pings ? 64 c’est pas assez ?
réponse OUI si le réseau local est plus chargé par divers flux de téléchargements ou du streaming, vos tests de pings seront probablement plus élevés et donc faussés dans une certaine mesure…
Notez aussi si vous utilisez le P2P , c’est néfaste car le modem n’aime pas un trop grand nombre de connexions simultanées
Bonsoir
0
0