La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: sazom le 11 mars 2021 à 22:25:23
-
Bonjour/Bonsoir,
Je suis en fibre FTTH 1Gbps chez SFR.
J'ai des problemes avec Microsoft Teams (comme si j'etais encore en adsl 2mb) quand nous sommes plusieurs dans un meeting (collegues US et EU) et quand je partages mon ecran.
Ci dessous quelques resultats de speedtest qui montrent que les debits montants et descendants et la latence varient fortement en fonction du serveur.
Du coup je me demandes si c'est normal: ma fibre est a (au plus ) 1Gbps en France uniquement ?
>speedtest.exe
Speedtest by Ookla
Server: SFR - Venissieux (id = 30993)
ISP: SFR
Latency: 1.76 ms (0.11 ms jitter)
Download: 946.35 Mbps (data used: 473.4 MB)
Upload: 477.79 Mbps (data used: 346.0 MB)
Packet Loss: Not available.
>speedtest.exe -s 14236
Speedtest by Ookla
Server: Frontier - Los Angeles, CA (id = 14236)
ISP: SFR
Latency: 148.06 ms (0.52 ms jitter)
Download: 547.41 Mbps (data used: 768.6 MB)
Upload: 78.11 Mbps (data used: 140.8 MB)
Packet Loss: 0.0%
>speedtest.exe -s 509
Speedtest by Ookla
Server: Login Inc. - Tucson, AZ (id = 509)
ISP: SFR
Latency: 145.61 ms (0.31 ms jitter)
Download: 586.38 Mbps (data used: 798.5 MB)
Upload: 107.59 Mbps (data used: 104.8 MB)
Packet Loss: 0.0%
>speedtest.exe -s 28800
Speedtest by Ookla
Server: PhoenixNAP Global IT Services - Phoenix, AZ (id = 28800)
ISP: SFR
Latency: 137.53 ms (0.37 ms jitter)
Download: 654.96 Mbps (data used: 870.8 MB)
Upload: 66.01 Mbps (data used: 107.3 MB)
Packet Loss: 0.0%
-
Bonsoir,
le débit est impacté par la latence aussi ;) et forcément sur les serveurs aux états unis tu as une latence qui dépasse les 100 ms et qui est incompressible.
Pour teams, ça ne devrait pas consommer + de 20 Mbit/s symétrique en étant large, donc le soucis n'est clairement pas le débit.
Soit tu as des pertes de paquets, soit tu as un soucis de wifi ? (si tu es en wifi), soit c'est le PC qui a du mal avec teams (il y a un coeur au maximum pendant la conférence ?)
-
Je suis en ethernet.
Le pc n'est pas tout recent mais plutot correcte.
Le probleme avec Teams se produit uniquement quand je partages mon ecran:
les gens en face ne voient l'ecran qu'apres x secondes et ne m'entendent pas bien (audio qui coupe).
C'est peut-etre une perte de paquet mais ca sent fortement le debit insuffisant...
Comment je debug ce probleme ?
-
Le probleme avec Teams se produit uniquement quand je partages mon ecran:
les gens en face ne voient l'ecran qu'apres x secondes et ne m'entendent pas bien (audio qui coupe).
Ca n'a pas l'air d'être un probleme réseau:
- contrôler la charge cpu du pc pendant le partage.
- mise a jour drivers video du pc
Apres Teams a bon support si on a un contrat avec MS...
-
Oui, il serait important de contraire le CPU. Team sur un portable demande un PC avec un core de 5ème génération au minimum.
Je confire que la latence à un impact fort sur le débit, surtout en mono connexion.
Tu as réalisé des tests multi-connexion, ce qui permet de voir la taille maximum du tuyau, mais en aucun cas ce que donne ton accès internet en réel.
Pour vérifier ce que faut ton accès internet en réel, il faut demander à speedtest des tests "mono-connexion".
Je t'invite à tester sur différents serveurs Français pour voir si cela a un impact.
-
Mon pc : cpu est un Core i5 4440 3.1Ghz (un quad core) et la ram est de 8 GB
En utilisation il y a un leger pique cpu mais pas 1 core a 100%.
Le driver (nvidia) est a jour. Il a ete updaté (par windows update) en septembre dernier.
Pour le test en mono-connection comment je fais ca avec speedtest ?
-
Pour le test en mono-connection comment je fais ca avec speedtest ?
Il suffit de cliquer sur le bouton rond pour passer de multi à single
-
Le PC est un PC fixe, largement plus puissant que nécessaire, même si c'est de la 4ème génération.
Je pensais aux PC portable en demandant un PC de 5ème génération minimum.
-
Les resultats en mono sur les memes serveurs sont ci-dessous.
On voit donc qu'en mono:
- les debits sur des serveurs US sont catastrophiques
- la latence est du meme ordre qu'en multi
Meme si ces debit sont plutot faibles pour du FTTH ils sont correctes pour Teams (qui necessite 2Mbps)
Microsoft Teams Bandwidth requirement (https://answers.microsoft.com/en-us/msteams/forum/all/microsoft-teams-bandwidth-requirement/acb9d25c-b299-4e9e-9505-38761651040b)
-
Microsoft Teams est en Europe.
Mes chiffres sont vieux et depuis les Rwin ont augmentées, mais il faut voir qu'il est normal d'avoir un débit plus faible avec des latences élevées :
(https://lafibre.info/images/tuto/201106_impact_du_ping_en_fonction_du_systeme_exploitation.png)
-
merci pour ce graphe.
Ca repond a ma 1ere question (tout le monde doit avoir la meme vitesse depuis la France).
Donc le probleme vient d'ailleurs (c'est pas le debit).
-
Mes chiffres sont vieux et depuis les Rwin ont augmentées, mais il faut voir qu'il est normal d'avoir un débit plus faible avec des latences élevées :
Surtout que lorsqu'il partage son écran le flux est sûrement en UDP.
Sazom, tu n'aurais pas un "antivirus" à la con par hasard ? Du genre qui inspecte tout ton trafic réseau...
-
test connectivité MS: https://connectivity.office.com/
Essai avec Google Chat en présentation d'écran pour voir si c'est un souci propre a Teams ou pas.
-
kgersen:
1) connectivity.office.com -> tous les tests sont OK.
pour teams:
Packet Loss: 0%
Latency : 20 ms (target<100ms)
Jitter : 13 ms (target<30ms)
2) Google hangout marche sans probleme en partage d'ecran.
Par contre je notes un leger decalage audio/video en utilisant la webcam.
cali:
pas d'antivirus (a part celui par default de win10)
-
Bonjour,
le probleme semble toucher plusieurs utilisateurs SFR (lien (https://la-communaute.sfr.fr/t5/wifi-connexion-filaire-et-d%C3%A9bit/mauvaise-qualit%C3%A9-du-d%C3%A9bit-montant/td-p/2285970)) et RED (lien (https://communaute.red-by-sfr.fr/t5/R%C3%A9seau/Bug-Microsoft-Teams/td-p/494151))
Il est évoqué IPV4+CGNAT qui pourrait bloquer certains ports UDP de teams mais une personne dit avoir le soucis en IPV4 full.
Comment debugguer ce soucis (a part partir chez la concurrence) ?
-
Est-ce que tu utilises un VPN ? un proxy ?
Pour réaliser des tests d'ouverture des ports tu peux utiliser l'outil d'assessment réseau Teams/Skype : https://www.microsoft.com/en-us/download/details.aspx?id=53885
Il possède un mode pour tester les ports en utilisant le paramètre /connectivitycheck : https://docs.microsoft.com/en-us/MicrosoftTeams/3-envision-evaluate-my-environment#test-for-opened-ports. Il y a un guide complet de l'outil dans le répertoire d'installation si tu veux customiser le test.
-
Le problème est un messager d'erreur, une impossibilité de faire le partage d'écran ?
Quelle est son occurrence ? Systématique ?
-
@Ge
voici le resultat de NetworkAssessmentTool.exe
NetworkAssessmentTool.exe
Skype for Business - Network Assessment Tool
Initializing audio call.
***************
Starting new call
Iteration 1 / 1
Audio call started. Waiting for call to end...
Call should end shortly after configured duration of 17 s.
Call completed.
Packet loss rate: 0.00117785630153121
RTT latency: 23.5 ms
Packets sent: 849
Packets received: 848
Average jitter: 9.635556 ms
Packet reorder ratio: 0
**************
NetworkAssessmentTool.exe /connectivitycheck
Skype for Business - Network Assessment Tool
Starting Connectivity checks
Verifications completed successfully
le fichier output connectivity_results.txt contient alors que des
Relay : xxx is reachable using Protocol UDP and Port 3478
Relay : xxx is reachable using Protocol TCP and Port 443
Relay : xxx is reachable using Protocol HTTPS and Port 443
@vivien
le probleme est une difficulté de faire du partage d'ecran:
initialement l'ecran est noir pendant plusieurs secondes puis quand mon ecran apparait ma voix devient saccadée donc difficilement comprehensible.
Ceci est systematique et il n'a a pas de message d'erreur ni dans Teams, ni dans les logs de Teams.
-
Si tu le souhaite tu peut m’envoyer une invitation Teams en MP pour que l'on teste ça, à partir de 15h30.
Cela serait bien de tenter avec ton mobile en partage de connexion pour être sur que c'est bien le FttH SFR qui pose problème.
-
@vivien merci pour l'invitation mais je teste tous les jours ce probleme en télétravail avec des collegues sur differents continents.
Je n'ai pas testé avec une connexion 4g encore (en partage de connexion) mais une personne l'a fait sur le forum RED (https://communaute.red-by-sfr.fr/t5/R%C3%A9seau/Bug-Microsoft-Teams/td-p/494151):
J'ai testé via une connexion 4G (chez un autre opérateur) et teams fonctionne bien, j'en déduis donc que le problème vient de ma connexion Red SFR.
-
En fait si tu souhaites que je remonte ce problème à SFR, il me faut des preuves du comportement réseau, notamment une capture Wireshak avec la connexion câble et le même action sur le même PC mais sur un autre réseau (la 4G c'est bon si tu n'a pas d'autre box a domicile).
-
JCLB (https://lafibre.info/profile/JCLB/) a proposé un test sur le forum RED (https://communaute.red-by-sfr.fr/t5/R%C3%A9seau/Bug-Microsoft-Teams/m-p/495471#M15310) pour la problématique :
Bonjour,
Le partage de ports IPv4 fonctionne sans problème chez de nombreux opérateurs (technos 4rd, MAP-T/E,...) y compris en France.
Je suppose que la section de code qui gère le NAT-PMP / UPnP au sein du routeur, donc l'ouverture de port à la demande d'application, n'a pas connaissance de ce partage.
Par exemple, J'ai le droit à une IPv4 publique avec la plage de ports 50 000 à 65 535.
Teams demande l'ouverture d'un port pour un échange P2P (hors pont de conférence donc) via UPnP, NAT-PMP ou PCP.
La demande arrive au routeur avec une requête pour le port 3478 UDP par exemple, le routeur voit qu'il est libre côté WAN et l'affecte (ou affecte un autre port aléatoire proche)
Le hic c'est que côté opérateur ce port est affecté à un autre client grâce à la magie du partage de ports.
Pour le savoir, il faudrait qu'un abonné fasse une capture avec Wireshark, et regarde les échanges UDP sur les ports 5350 et 5351 lorsqu'il démarre un appel, un tableau blanc, etc...
Exemple d'analyse ici (https://sudonull.com/post/89833-Open-ports-for-NAT-using-NAT-PMP-and-UPnP-IGD)
Si dans la réponse le champ Mapped External Port donne un port qui ne fait pas parti de la plage affectée au client, plouf, rien ne fonctionnera.
Je renvoie les équipes technique à la section 5.2 de la RFC suivante RFC6269 section 5.2 (https://tools.ietf.org/html/rfc6269#section-5.2)
Des gens se sont déjà posé les bonnes questions, il faut prendre le temps de lire les RFC chers collègues ingés.
Je vois aussi ici des gens qui se plaignent de saccades, signe que votre infrastructure de translation en bordure est probablement sous-dimensionnée.
JCLB
-
Teams fait du STUN/ICE pour le P2P vocal/vidéo : https://docs.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows
Si le P2P n'est pas possible, ca bascule en HTTPS via les serveurs Microsoft.
y'a belle lurette que UPnP, NAT-PMP ou PCP sont des méthodes qui échouent trop souvent pour être exploitables a grande échelle. La plupart des firewall et dispositifs de sécurité en bordures des entreprises ne permettent pas d'ouvrir des ports avec UPnP, NAT-PMP ou PCP
pour tester, il y a : https://test.webrtc.org/
sinon https://webwormhole.io/ qui permet d'échanger en P2P des fichiers entre navigateurs (on peut tester d'un pc fixe a un mobile sur un autre réseau par exemple: sur le pc: create wormhole, mobile: ouvrir le qr code).
-
je vais tenter une capture wireshark ce week end (en mode ethernet derriere la box puis 4g)
Mais je dois regarder quoi dans cette capture ?
-
Le mieux est de me l'envoyer pour que je vérifie ce qu'il se passe au moment ou tu partage ton écran.
Il est important d'arréter tous les autres usage d'internet et de lancer la capture juste avant de lancer Team pour qu'on ait toutes les connexions.
Ensuite repérer le partage de connexion en nombre de seconde depuis le début de la capture ou la fin (au choix) pour pouvoir se focaliser sur ce qu'il se passe à ce moment là.
-
Bonjour,
Je pense rencontrer le même problème que toi ainsi qu'un autre de mes collègues et j'avoue être à court d'idées de tests pour avancer sur la résolution.
Ton problème est-il que la vidéo reçus par te collègues est très mauvaise avec un taux de rafraichissement très bas et le partage de contenu qui reste noir pendant quelques minutes avant d'être visibles par les autres participants mais là aussi avec un faible taux de rafraichissement ?
En revanche coté audio (dans les deux sens) et video en reception aucuns problèmes ?
-
Bonjour,
Je pense rencontrer le même problème que toi ainsi qu'un autre de mes collègues et j'avoue être à court d'idées de tests pour avancer sur la résolution.
Ton problème est-il que la vidéo reçus par te collègues est très mauvaise avec un taux de rafraichissement très bas et le partage de contenu qui reste noir pendant quelques minutes avant d'être visibles par les autres participants mais là aussi avec un faible taux de rafraichissement ?
En revanche coté audio (dans les deux sens) et video en reception aucuns problèmes ?
La même chose.
Selon forum redbysfr.
SFR est dessus.
10 juin 2021
J’ai eu un appel d’un technicien de second niveau de sfr aujourd’hui. Microsoft a remonté le soucis via son propre service support vers SFR. Contrairement au centre d’appel, l’ingénieur a bien compris le soucis et avait l’air compétent. Il a évoqué un potentiel problème de la box v7 et m’a dit espérer arriver au bout de l’histoire dans les prochaines semaines.
https://communaute.red-by-sfr.fr/t5/R%C3%A9seau/Bug-Microsoft-Teams/td-p/494151/page/5
https://communaute.red-by-sfr.fr/t5/R%C3%A9seau/Bug-Microsoft-Teams/td-p/494151/page/6
-
Je suis assez sceptique sur le fait que cela puisse venir de la box, je ne l'ai jamais utilisée, je l'ai remplacé par RB4011. Selon moi il s'agit plus d'un problème entre certains media relay (TURN microsoft) et SFR. J'ai "réglé" le problème chez moi en bloquant tout l'UDP sortant vers 52.112.0.0/14. C'est un peu extrême mais ça marche, la traffic fallback en TCP, en fibre ce n'est pas vraiment gênant.
-
Bonjour, pourriez-vous préciser la manipulation à effectuer pour "bloquer tout l'UDP sortant vers 52.112.0.0/14" ?
Je suis également bloquer avec teams (mais sur K-NET pour ma part) et j'aimerais essayer votre technique !
-
Bonjour, pourriez-vous préciser la manipulation à effectuer pour "bloquer tout l'UDP sortant vers 52.112.0.0/14" ?
Je suis également bloquer avec teams (mais sur K-NET pour ma part) et j'aimerais essayer votre technique !
?
Chez K-NET, tu n'as pas ce bug.
-
K-Net aussi, et je confirme, le bug n'est pas présent. J'ai aucun souci à utiliser Teams.
-
Si si, malheureusement exactement le même problème que celui décrit sur SFR / Red depuis quelques mois (et sur deux PC avec teams, de deux entreprises différentes ...) : teams fonctionne parfaitement en Web ou avec un partage de connexion mais la version Desktop, connecté au réseau fibre, ne fonctionne pas.
Sur mon PC du travail, en me connectant à un VPN "TCP only", ca fonctionne mais mon épouse n'a pas cette option, d'où le test que je voudrai essayer !
Je suis sur le réseau fibre du Val d'oise par K-Net.
-
Bonjour, pourriez-vous préciser la manipulation à effectuer pour "bloquer tout l'UDP sortant vers 52.112.0.0/14" ?
Je suis également bloquer avec teams (mais sur K-NET pour ma part) et j'aimerais essayer votre technique !
Cela dépend d'où vous souhaitez effectuer le blocage, pour ma part je l'ai appliqué au niveau de ma mon routeur (mikrotik) mais j'imagine qu'une règle dans le pare-feu windows peut suffire pour le test.
Néanmoins comme le signal thedark, le problème était identifié coté SFR, pas microsoft et a à priori été résolu.
-
Dans ce cas essayez une règle de pare feu personnalisée: pour tous les programmes, type de protocole: UDP, IP distantes: 52.112.0.0/14, bloquer la connexion, tous les profils.
-
Merci beaucoup, je vais essayer et je vous tiens au courant , cette manipulation pourra certainement en aider d'autres ;) !