Problème ( MS ) sur internet

avez-vous tenté de faire ce test en dehors de l'application?

traceroute to 109.131.65.5 (109.131.65.5), 15 hops max, 60 byte packets
1 *
2 85.190.64.246 (85.190.64.246) [AS64476] 1.484 ms
3 89.30.1.193 (89.30.1.193) [AS31216] 1.328 ms
4 89.30.1.193 (89.30.1.193) [AS31216] 1.211 ms
5 cr1.eqx3.par.fr.bsonet.net (89.30.32.134) [AS31216] 3.641 ms
6 cr1.eqx3.par.fr.bsonet.net (89.30.32.134) [AS31216] 3.533 ms
7 *
8 *
9 *
10 *
11 80.84.23.95 (80.84.23.95) [AS6774] 8.082 ms
12 lg-11-100.ssr02mar01.isp.belgacom.be (91.183.241.167) [AS5432] 128.968 ms



Voici un autre test, ligne 12 a 128ms !

Bonsoir Sinik001,

Je confirme que vous pouvez rencontrer un ping plus élevé en soirée, nous sommes au courant du problème et à la recherche d'une solution.

@romain mon problème empire en soirée.
Mais en journée j’ai aussi une variation des MS.

Comme montré sur les photos !

Bonjour,

Je vois qu'on est 1 an après, et je rencontre le même soucis que @Sinik001. Pareil, j'utilise Shadow et je viens de déménager. Je suis en fibre optique (nouveau batiment), et j'ai le même résultat sur le même serveur : lg-11-100.ssr02mar01.isp.belgacom.be (91.183.241.167) [AS5432] 198.348 ms

Ce serveur ou je ne sais quoi qui est à cette adresse ralenti tout le tracé. Je suis à moins de 2ms partout ailleurs, mais arrivé à ce composant Proximus, ça ralenti tout. Impossible donc d'utiliser mon PC Shadow dans de bonnes conditions.

J'en déduis donc que le message de RomainM était pas super vrai, vu que le problème persiste encore et toujours.

Bonsoir Sinik001,

Je confirme que vous pouvez rencontrer un ping plus élevé en soirée, nous sommes au courant du problème et à la recherche d'une solution.

Des idées ?

Bonsoir,

la seule valeur qui compte pour mesurer la latence est la réponse à un ping vers le serveur de destination. Les valeurs intermédiaires d’un tracert ne sont absolument pas représentatives, elles représentent seulement le temps que met ce routeur à répondre au tracert, mais ne représente en rien le temps mis à router les paquets.
Comme vous dites, vous êtes à moins de 2ms partout ailleurs, or ces machines se trouvent *après* le noeud en question, leur réponse transite forcément par ce noeud...

Sur un trajet en voiture de 100km, si dans les 5 derniers km vous avez des ralentissement, l'heure d'arrivée ne sera pas impacté peut-être ? Bien sûr que si.

Dans notre cas, le Shadow demande un minimum de latence sur l'entièreté du chemin, sinon on ressent directement les effets. Dans mon cas, c'est une latence réellement perceptible dans l'utilisation du PC, un son qui crachotte,... Et j'ai déjà contacté le support Shadow, et après plusieurs tests et vérification, la cause est bel et bien ce nœud lors du routage.

Et ayant effectué les tests à mon travail, aussi en fibre, ici le dernier nœud est un autre, plus récent je suppose, car il comporte l'adresse "proximus.com", alors que chez moi, c'est une adresse "belgacom.be". Peut-être que c'est de l'extrapolation de ma part, mais ça expliquerait pourquoi c'est plus efficace au travail que chez moi.

Si c'est le cas, à quoi sert d'avoir de la fibre si après, ça ne suit pas ? Me vendre une Ferrari avec un moteur de Lada... 😞

Sur un trajet en voiture de 100km, si dans les 5 derniers km vous avez des ralentissement, l'heure d'arrivée ne sera pas impacté peut-être ? Bien sûr que si.

Réfléchissez ou renseignez-vous sur la façon donc tracert fonctionne. Si *tous* les noeuds à partir de celui-là rapportait une valeur élevée, alors oui ce noeud serait le problème. Or, ce n'est pas le cas, d'après ce que vous dites.

Je ne dis pas que vous n'avez pas de problème de latence, ni que le problème ne vient pas de Proximus, mais la cause est à chercher ailleurs.


Comme dit plus haut, c'est toujours la ligne 12 ou 11 qui est toujours impacté par un temps de réponse super haut.

Jusqu'à ce jour, aucune réponse ou solution n'a été apporté. Je vais arrêter mon abonnement a Shadow pc, car celui ci est inutilisable avec un temps de réponse pareil.

Personnes pour solutionné ce soucis ? Proximus ??

Votre PC est bien en cablé ?

Oui, le pc est bien câblé .

Direct a la BBOX ou a un switch ?

A un switch netgear.

@Sinik001
Je vais me permettre d'intervenir sur votre thread de forum si vous me le permettez.
Visiblement on vous renseigne mal, on vous conseille mal et y a une certaine quantité de gens qui ne connaissent pas leur travail ou qui ne connaissent que le B.A.B.A en réseau.

Première chose à faire serait de faire un état des lieux des problèmes.
J'ai également un shadow donc la première chose à faire aurait été de montré un screen de votre écran de statistiques de votre shadow.
Je vous mets deux exemples du mien.

Comme vous pouvez le voir je peux avoir jusque 15% de perte de paquets et ce en étant relié par câble.
J'ai une relativement bonne ligne vdsl2 et pourtant voilà. Mais en effet mon ping est relativement stable comme vous pouvez le constater. Donc est ce que c'est à partir de cet outil là que vous avez visualisé votre ping ou à partir d'autre part? Cet outil est disponible comme vous devez probablement le savoir en bas à droite dans la barre des tâches, c'est l'icône de l'entreprise et puis vous devez cliquer sur le bouton statistiques dans cet outil pour afficher les stats( bouton en bas de la fenêtre qui ressemble à un histogramme).

La service technique de blade et d'ailleurs celui de proximus, est rarement convenablement formé à lire correctement un traceroute et en tirer des conclusions correctes. Un traceroute n'est qu'une information parmi d'autre et est en réalité quelque chose de plus complexe que simplement voir qu'il y a une valeur plus haute sur le tracé.
Comme vous pouvez le voir sur mon imprime écran de traceroute moi aussi j'ai une valeur bien plus haute lors de la rencontre avec le premier noeud réseau de proximus. Mais quand je ping ce même noeud, il répond tout à fait normalement.
En réalité un traceroute ne fournit pas les valeurs du tracé en tant que tel. Il vous montre le tracé qui est pris par la succession de l'envoi de probe (sonde) pour arriver à une destination. En réalité c'est donc un probe par noeud réseau qui est envoyé et non pas un seul paquet qui est envoyé dont on aurait le tracé. Et d'ailleurs, souvent, pas tout le temps, vous n'avez pas le même tracé d'une seconde à l'autre.
En ce qui concerne blade oui car ils sont à un niveau de réseau très élevé et donc dès que vous passez sur le circuit international, sauf problème de route BGP (=comme régulièrement ces derniers mois), votre paquet suivront toujours le même chemin.
https://www.zdnet.com/article/china-has-been-hijacking-the-vital-internet-backbone-of-western-countries
https://americanmilitarynews.com/2019/06/china-hijacked-70000-european-internet-routes-analysts-say
https://en.wikipedia.org/wiki/BGP_hijacking
Dans un second temps, traceroute va vous fournir, en fonction de son implémentaiton car ce n'est pas la même entre UNIX linux ou windows, des valeurs de temporalité sur une boucle de votre point au noeud réseau qui est testé. Vous avez typiquement 3 infos de temps pour donner une consistance à l'information mais c'est configurable, de même que comment le test doit être effectué est configurable aussi(en fonction du type de paquet) .Mais cette information de temps, n'est pas implémentée correctement en réalité en suivant la RFC1812 qui précise que la réponse au test par le noeud réseau doit être faite via la même gateway dont la demande de test est originaire. Or c'est pas ça qu'il se passe puisque le noeud réseau répond toujours par une autre interface et donc cette réponse parcourt un tout autre chemin.
En réalité pourquoi, on utilise du coup cette valeur de temporalité, c'est parce que si il y a consistance durant le tracé d'une augmentation de valeurs significatif à partir d'un certain point jusqu'à la fin du tracé, alors c'est le signe qu'il y a un encombrement. Mais de nos jours, ce genre de problème se produit relativement peu du au niveau d'expertise des opérateurs(des techniciens et architectes du réseaux, pas des gens du support sans vouloir être méchant mais c'est juste un fait) et de leur qualité.
Tout ceci est très bien expliqué ici dans ce pdf : https://major.io/wp-content/uploads/2012/06/RAS_Traceroute_NANOG_slides.pdf Désolé pour le lien car normalement ce pdf est issu d'une grosse entreprise internationale mais il semblerait qu'ils l'aient déplacé et donc qu'il ne soit plus accessible. Ce pdf est donc une copie mis en ligne par un autre expert sur son blog.

Ce que le support de blade ne dit pas aussi ou ne prend jamais en comtpe c'est ce que fait à ce moment-là votre colocataire de shadow, ni la charge réseau à ce moment là dans leur datacenter particulier.
Sachez aussi que quand vous éteignez complètement votre shadow et que vous le rallumez, vous n'êtes plus sur la même machine physique que vous étiez y a quelques minutes. En effet, les disques durs/SSD que vous utilisez au sein des machines virtuelles qui sont calculées par la machine "serveur" que le système vous a automatiquement attribuée ne sont pas dans les machines elles-mêmes. Ce qui se trouvent dans les machine, sont des disques durs système d'un OS hôte, dans le cas de shadow c'est le système linux Red Hat entreprise, et qui lui va aller chercher votre machine virtuelle sur un système de disque dur RAID de type NAS autre part dans le datacenter. Donc votre système peut être virtuellement chargé à partir de n'importe où vers n'importe où.
Vous pouvez constatez cela par différentes chose, notamment dans le gestionnaire de ressources de widnows qui pourra vous montrer un modèle de processeur différent que précédemment utilisé. Il y en a de deux modèles dans les datacenter de blade.
https://en.wikipedia.org/wiki/Data_center
https://en.wikipedia.org/wiki/Hardware-assisted_virtualization
https://en.wikipedia.org/wiki/Virtualization


Donc avec toutes ces informations, j'espère que la situation est un peu plus claire maintenant.

Donc cocnernant le tracé, ce qu'il faudrait c'est le faire juste au moment où ça se passe. Le faire dans les deux sens.
Faire un speedtest.
Un ping test dans les deux sens si possible, sur les différents noeuds réseaux.
Et à côté de ça voir votre écran de statistiques shadow,
voir l'activité qui y est faite à ce moment précis,
le modèle de CPU utilisé à ce moment-là,
votre propre charge processeur sur votre machine client(donc votre pc).
Voir aussi si vous avez le même problème à partir d'un autre pc chez vous, branché de la même façon.
Ensuite voir si ce n'est pas votre switch qui est défaillant (peu probable mais on sait jamais)
Avoir fait l'état des lieux de ce qu'il y a sur votre réseau à ce moment-là=> télé, pc, téléphone
Essayé les applications clientes stables de shadow mais aussi beta.
Que l'on sache sur quel système vous vous trouvez également (mac, windows, linux)
Essayer avec une autre bbox si vous pouvez.

C'est un problème complexe, les gens de chez blade veulent en faire quelque chose de simple mais jamais ça sera possible d'en faire quelque chose de simple quand vous donnez la possibilité aux gens d'avoir un système virtualisé complètement. google stradia peut être quelque chose de simple, parce que le système est sur toutes les machines le même, que le problème est donc très limité et que les interactions de l'utilisateur sont très restreintes. C'est pas le cas ici. Et donc en réalité pour même jauger du problème complètement il nous faudrait également le relevé d'activité de la machine shadow dans son intégralité, savoir ce que votre colocataire était en train d'effectué en même temps, depuis quand la machine n'avait pas été éteinte, etc. Car il n'y a pas que le cpu ou la RAM qui souffrent mais une tonne d'autres composants dont le chipset etc qui peuvent rendre une machine beaucoup plus lente parce que tout n'est pas bien tenu en ordre sur toute la longueur de son utilisation. Vous pouvez faire le test rien que vous même en laissant un pc desktop tourner pendant un mois sans même rien faire dessus, juste les processus windows et de sécurité tourner et vous verrez que le niveau de réactivité n'est pas le même entre le début et la fin du mois.

Donc non ça peut venir de bien autre chose que le réseau, ça peut venir de leur système d'accès à distance, de la machine elle-même, etc etc