La Fibre
Télécom => Réseau => 
Baromètre (Comparatif des FAI) => Discussion démarrée par: Pilou42 le 04 février 2024 à 12:17:55
-
Bonjour,
Je ne sais pas où mettre ce sujet, je tente ici, mais si quelqu'un souhaite le déplacer, pas de problème.
Etant chez Bouygues, je pensais que le site ok.ru était un site "mou" pour l'ensemble des FAI, mais je me suis rendu compte de manière accidentelle que chez quelqu'un d'autre, ça marchait très bien, et cette personne est chez Sosh.
Du coup, je me demandais si des personnes pouvaient me donner leur ressenti.
Procédure de test:
- Aller sur cette (https://ok.ru/video/7209052867102) vidéo.
- sur la roue crantée, choisir le mode 1080p
- naviguer dans la vidéo, avec les flèches du clavier (ou souris)
Avec Bouygues, il y a un décalage d'une dizaine de secondes, mais si la vidéo vient d'être uploadée sur ce site, c'est quasiment irregardable, même en 360p, on a le "rond qui tourne" pendant encore + longtemps.
PS: Svp, ne dérivons pas sur de la politique ou la légalité, vraiment, si vous pouvez juste donner votre FAI, confirmer que vous êtes en fibre, et dire si vous êtes comme moi en buffering ou alors si c'est assez rapide, genre Youtube. Merci d'avance.
Edit de mi-février: Désormais OK chez Bouygues !
Orange OK
Bouygues OK
-
Bonjour,
vu de chez Red, j'ai filmé ce que je vois:
https://youtu.be/0NDp7p5zU_8
-
FTTH Orange ici, test sur un PC en Wi-Fi 6 avec Firefox.
En 1080p, la navigation dans la vidéo est quasi instantanée, et même chose en 4K.
Bien plus rapide que sur la vidéo faite par Denis.
-
Bonjour,
vu de chez Red, j'ai filmé ce que je vois:
Hello,
Pareil chez RED.
vd423.mycdn.me
HOST: orangepi5 Loss% Snt Last Avg Best Wrst StDev
1. AS??? box 0.0% 10 0.5 0.8 0.5 1.2 0.2
2. AS15557 1.191.94.92.rev.sfr.net 0.0% 10 8.2 8.2 7.6 8.7 0.4
3. AS15557 82.212.192.77.rev.sfr.net 0.0% 10 8.7 9.8 8.3 17.0 2.6
4. AS??? 220.147.6.194.rev.sfr.net 0.0% 10 9.7 10.3 9.7 11.2 0.5
5. AS??? 220.147.6.194.rev.sfr.net 0.0% 10 9.5 11.6 9.3 19.3 3.9
6. AS9002 ae7-202.RT.THV.PAR.FR.retn.net 0.0% 10 8.6 15.4 8.6 31.0 8.4
7. AS9002 ae34-133.RT.M9.MSK.retn.ru 0.0% 10 61.5 61.7 52.7 71.0 6.5
8. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10. AS47764 45.136.21.26 0.0% 10 52.4 53.2 52.4 54.6 0.7
-
même chose en 4K.
Du coup j'ai testé en 4K aussi, en prenant Brave plutôt que Chrome. J'ai un écran 4K en port display.
C'est parfait pour la cuisine, le sablier tourne comme il faut pour un steack saignant, en bref la cata.
-
Merci pour vos 1ers retours. Je n'avais pas le courage de faire une vidéo, merci pour l'exemple ! J'ai bien le même comportement.
Donc il semblerait que:
Bouygues KO
SFR KO
Orange OK
En attendant un retour sur Free et d'autres FAI locaux.
-
Ok pour K-net
3 secondes de buffering lors d'avance dans la vidéo.
-
Ah. 3 secondes, moi je trouve ça trop lent. :-X
Est-ce que tu as l'impression que c'est du niveau de Youtube ?
Personnellement, j'utilise ok.ru pour regarder des résumés de sport, et pour gagner du temps, j'ai régulièrement besoin d'avancer au clavier (je n'ai pas forcément besoin de voir tous les replays), et 3 secondes à chaque fois, c'est bien trop long. Si en 480p c'était instantané, ça m'irait, mais c'est pas le cas du tout.
-
Aucun soucis côté Orange.
-
je viens de tester et il y a bien entre 2 et 5sec de buffering quand j'avance au pif dans la video
-
Je confirme que ça mouline et bufferise ici sans même avoir à avancer / reculer la vidéo. Un mauvais peering avec RETN ?
-
Je viens de refaire en 4K, pas de problème non plus.
-
Orange le seul qui marche bien ^^
-
Je confirme, ordi en Ethernet, c'est quasi instantané pour la 4k
Orange le seul qui marche bien ^^
Faut pas le dire, les gens chez Free vont pas être content ^^
-
alors je vient de tester en 4k c'est inregardable chez bouygues lol
-
alors je vient de tester en 4k c'est inregardable chez bouygues lol
Je ne sais pas, peut être une histoire de peering avec les pays ? L'avantage d'Orange c'est qu'ils sont présents dans plusieurs pays notamment en Afrique. Mais par exemple j'avais entendu qu'Orange galerait avec un certain opérateur en Allemagne donc bon...
-
oui surement le peering je vois rien d'autre ^^
-
Il manque quelques retours comme Free et des FAI locaux, si des gens ont la motivation de faire le test et me/nous tenir au courant...
-
Je confirme pour la partie SFR (abonnement RED), j'ai le même comportement que les témoignages précedents
-
Idem sur Free, buffering de 5/7 secondes. Ça charge à peine à 350/400 Ko/s.
moon@Freeze:[~] > mtr ok.ru -zwc 10
Start: 2024-02-06T11:48:21+0100
HOST: Freeze Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.254 0.0% 10 0.6 0.5 0.5 0.6 0.0
2. AS??? station11.multimania.isdnet.net 30.0% 10 7.4 7.7 7.3 8.3 0.4
3. AS??? decix.proxad.net 90.0% 10 16.7 16.7 16.7 16.7 0.0
4. AS??? ipv4.de-cix.fra.de.as31133-frnkt-pe-mx960-1.megafon.ru 90.0% 10 16.0 16.0 16.0 16.0 0.0
5. AS31133 83.169.204.111 90.0% 10 50.1 50.1 50.1 50.1 0.0
6. AS31133 83.169.204.69 80.0% 10 50.3 50.1 49.9 50.3 0.3
7. AS31133 83.169.204.113 0.0% 10 49.9 50.0 49.4 50.5 0.3
8. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. AS47764 ip1.147.odnoklassniki.ru 0.0% 10 51.0 51.0 50.4 51.7 0.4
-
Essai avec une connexion SFR Câble : ça bufferise. Mon moniteur me dit que ça charge à 200 ko/s (d'où le temps que ça met, forcément).
-
Hello,
Je viens de tester quelques combinaisons:
- IMS Network (réseau entreprise), ça bufferise 4-5 secondes en 4K
- Free Fibre, ça bufferise une bonne dizaine de secondes
- Avec iCloud Private Relay (l'espèce de VPN de Apple dans Safari), ça bufferise 4-5 secondes
- Avec l'utilitaire Warp de CloudFlare (un wireguard vers Cloudflare) c'est instantané.
Ça sent le mauvais peeing (sauf pour Orange et CloudFlare)
-
Les mecs... depuis avant vous parlez d'une situation sans préciser le serveur qui vous délivre le flux.
Pour ma part,
FAI : Orne THD
La vidéo se lance, ne bufferise pas, c'est clean.
Le seeking (le fait de se déplacer dans la timeline) met 2-3 secondes, et ça repart, là aussi sans bufferiser par la suite
Le serveur : "ok6-31.vkuser.net".
$ mtr -zrwc1 ok6-31.vkuser.net
Start: 2024-02-08T14:18:27+0100
HOST: localhost.localdomain Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 1 0.3 0.3 0.3 0.3 0.0
2. AS41114 vrrp-vl11.cust.rombas.infra.ornethd.net 0.0% 1 0.8 0.8 0.8 0.8 0.0
3. AS41114 213.226.72.63 0.0% 1 1.3 1.3 1.3 1.3 0.0
4. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
5. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
6. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
7. AS60476 srv35-206.vkontakte.ru 0.0% 1 14.7 14.7 14.7 14.7 0.0
-
C'est pas vd423.mycdn.me le serveur qui délivre le flux ? Je ne sais pas comment on peut retrouver ce "ok6-31.vkuser.net".
Mais sans même parler de détail, il y avait la comparaison en secondes du buffering, et au vu des retours, il y a bien une différence entre FAI.
Lors de ton test, tu as donc 2-3 secondes lors de chaque "seeking" ? Donc on est d'accord que ce n'est pas terrible non plus ? Du moins, comparé à ceux chez Orange (ou ceux qui passent par Cloudflare en tant que proxy).
Perso, j'aimerais bien avoir le même temps d'attente sur Youtube que sur ok.ru, c'est à dire quelques millisecondes maximum.
-
C'est pas vd423.mycdn.me le serveur qui délivre le flux ? Je ne sais pas comment on peut retrouver ce "ok6-31.vkuser.net".
Je me fie par rapport à la capture jointe (CDN host).
Mais sans même parler de détail, il y avait la comparaison en secondes du buffering, et au vu des retours, il y a bien une différence entre FAI.
Lors de ton test, tu as donc 2-3 secondes lors de chaque "seeking" ? Donc on est d'accord que ce n'est pas terrible non plus ? Du moins, comparé à ceux chez Orange (ou ceux qui passent par Cloudflare en tant que proxy).
Oui, c'est relativement stable et qq secondes de seeking ça reste agréable (surtout si derrière la vidéo est fluide, tu le vois sur la capture). Avoir une vidéo qui buffer, là par contre, ça me péterai les couilles.
Perso, j'aimerais bien avoir le même temps d'attente sur Youtube que sur ok.ru, c'est à dire quelques millisecondes maximum.
C'est pour ça que le serveur est important.
Si la vidéo est en cache et près de chez toi, oui la différence se voit.
Le topic est intéressant en tout cas, est-ce que le débit envoyé est volontairement faible quand VK renvoie vers du transit VS ceux qui ont du peering (car il faut aller aux pays-bas ou à moscou pour aller les chercher) ? Ca peut donner des idées d'améliorations :)
-
J'ai une nouvelle vidéo (https://ok.ru/video/7379496864495) pour les tests de seeking (attention, elle ne sera surement pas éternelle), tu vas voir, ce n'est pas la même (je dirais 8 secondes après s'être déplacé dans la vidéo). :-X
Mais oui, on n'a pas le même CDN, moi je suis sur vd423.mycdn.me, comme d'autres l'ont mentionné avant, je n'aurais pas pensé qu'il y en avait d'autres !
-
Côté Orange, il y a du peering direct (PNI) avec VK.
-
J'ai une nouvelle vidéo (https://ok.ru/video/7379496864495) pour les tests de seeking (attention, elle ne sera surement pas éternelle), tu vas voir, ce n'est pas la même (je dirais 8 secondes après s'être déplacé dans la vidéo). :-X
Exact, et là, même la lecture en 720p bufferise sans seeker.
Mais oui, on n'a pas le même CDN, moi je suis sur vd423.mycdn.me, comme d'autres l'ont mentionné avant, je n'aurais pas pensé qu'il y en avait d'autres !
Là par contre pour celui-là, il me parait bien plus éloigné niveau ping.
$ mtr vd423.mycdn.me -zrwc1
Start: 2024-02-08T15:19:17+0100
HOST: localhost.localdomain Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 1 0.4 0.4 0.4 0.4 0.0
2. AS41114 vrrp-vl11.cust.rombas.infra.ornethd.net 0.0% 1 0.9 0.9 0.9 0.9 0.0
3. AS41114 213.226.72.63 0.0% 1 0.9 0.9 0.9 0.9 0.0
4. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
5. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
6. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
7. AS??? ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
8. AS47764 45.136.21.26 0.0% 1 56.7 56.7 56.7 56.7 0.0
Côté Orange, il y a du peering direct (PNI) avec VK.
Bon bah voilà, game over ;D
-
Roule bien jusqu'en 480, en 720 ça construit des immeubles, vois plus rien:
-
J'ai une nouvelle vidéo (https://ok.ru/video/7379496864495) pour les tests de seeking (attention, elle ne sera surement pas éternelle), tu vas voir, ce n'est pas la même (je dirais 8 secondes après s'être déplacé dans la vidéo). :-X
RAS depuis ma connexion FTTH Orange, c'est quasi instantané en seek en 720p
-
Un traceroute vers le CDN donne quoi stp ?
Merci.
-
Un traceroute vers le CDN donne quoi stp ?
Merci.
traceroute to vd377.mycdn.me (185.226.52.72), 30 hops max, 60 byte packets
1 livebox.home (192.168.1.1) 0.592 ms 0.866 ms 1.194 ms
2 80.10.255.181 (80.10.255.181) 9.274 ms 9.402 ms 9.599 ms
3 ae83-0.ncren102.rbci.orange.net (80.12.192.154) 9.720 ms 9.835 ms 9.947 ms
4 ae43-0.niidf302.rbci.orange.net (193.252.159.161) 15.929 ms 16.161 ms 16.348 ms
5 ae40-0.niidf301.rbci.orange.net (193.252.103.37) 16.492 ms 16.617 ms 16.734 ms
6 * * *
7 ae300-0.ffttr7.frankfurt.opentransit.net (193.251.131.52) 17.775 ms 18.979 ms 19.117 ms
8 * * *
9 * * *
10 185.226.52.72 (185.226.52.72) 57.787 ms 58.224 ms 58.368 ms
-
Avec free ça traine un peu avec mon vpn pia ç'est plus rapide mais plus lent qu'orange.
-
j'ai ça avec Bouygues :)
C:\Users\Astrania>tracert vd423.mycdn.me
Détermination de l’itinéraire vers vd423.mycdn.me [45.136.21.26]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms bbox.lan [192.168.1.254]
2 3 ms 3 ms 3 ms 128-78-160-2.abo.bbox.fr [128.78.160.2]
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 48 ms * * 83.169.204.69
7 46 ms 46 ms 46 ms 83.169.204.113
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 48 ms 48 ms 48 ms 45.136.21.26
Itinéraire déterminé.
-
Connexion SFR câble
traceroute to vd423.mycdn.me (45.136.21.26), 64 hops max, 52 byte packets
1 192.168.5.1 (192.168.5.1) 0.941 ms 0.623 ms 0.621 ms
2 192.168.0.1 (192.168.0.1) 1.367 ms 1.490 ms 1.321 ms
3 10.71.192.1 (10.71.192.1) 11.869 ms 7.271 ms 7.934 ms
4 217.255.245.213.rev.sfr.net (213.245.255.217) 8.370 ms 6.917 ms 8.156 ms
5 69.237.154.77.rev.sfr.net (77.154.237.69) 8.995 ms 9.701 ms 8.099 ms
6 220.147.6.194.rev.sfr.net (194.6.147.220) 14.054 ms 14.407 ms
71.146.6.194.rev.sfr.net (194.6.146.71) 15.980 ms
7 220.147.6.194.rev.sfr.net (194.6.147.220) 14.008 ms
71.146.6.194.rev.sfr.net (194.6.146.71) 15.499 ms 13.882 ms
8 ae7-202.rt.thv.par.fr.retn.net (87.245.246.248) 23.043 ms 15.643 ms 15.912 ms
9 ae34-133.rt.m9.msk.retn.ru (87.245.232.142) 69.369 ms 59.374 ms *
10 * * *
11 * * *
12 45.136.21.26 (45.136.21.26) 57.897 ms 58.021 ms 58.707 ms
-
avec free, moi aussi je veux jouer :
-
Depuis une connexion SFR FTTH sur RIP XP Fibre (mais pendant ma sauvegarde TimeMachine via WiFI qui bouffait bcp d'upload (entre 10 et 50 Mo/sec) :
traceroute to vd423.mycdn.me (45.136.21.26), 64 hops max, 52 byte packets
1 gen8 (192.168.1.1) 1.564 ms 1.279 ms 2.214 ms
2 * * *
3 137.4.128.77.rev.sfr.net (77.128.4.137) 5.120 ms 5.542 ms 3.992 ms
4 220.147.6.194.rev.sfr.net (194.6.147.220) 16.795 ms 19.616 ms 25.188 ms
5 220.147.6.194.rev.sfr.net (194.6.147.220) 22.998 ms 25.109 ms 17.460 ms
6 ae7-202.rt.thv.par.fr.retn.net (87.245.246.248) 25.691 ms 19.045 ms 16.826 ms
7 ae34-133.rt.m9.msk.retn.ru (87.245.232.142) 60.797 ms 60.421 ms 65.351 ms
8 * * *
9 * * *
10 45.136.21.26 (45.136.21.26) 59.020 ms 62.122 ms 62.455 ms
Et en HD 720p, ça galère bien : buffering de plusieurs secondes (8-15 sec) au démarrage, puis régulièrement après (genre toutes les 3 à 8 secondes!) et idem quand on déplace le curseur de lecture en dehors de la zone déjà chargée... En 480p ça va bcp mieux...
-
Depuis K-Net
Détermination de l’itinéraire vers vd423.mycdn.me [45.136.21.26]
avec un maximum de 30 sauts :
1 3 ms 3 ms 3 ms k-box.home [192.168.1.1]
2 4 ms 4 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 14 ms 14 ms 14 ms k-net.covage [10.2.0.5]
5 15 ms 14 ms 14 ms 213.144.168.182
6 * 25 ms 49 ms 195.22.211.57
7 37 ms 37 ms 37 ms 195.22.214.85
8 76 ms 82 ms 78 ms ae34-133.RT.M9.MSK.retn.ru [87.245.232.142]
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
11 71 ms 70 ms 70 ms 45.136.21.26
Itinéraire déterminé.Depuis Renater
tracert vd423.mycdn.me
Détermination de l’itinéraire vers vd423.mycdn.me [45.136.21.26]
avec un maximum de 30 sauts :
1 * 35 ms *
2 31 ms 30 ms 30 ms
3 * * * Délai d’attente de la demande dépassé.
4 34 ms 34 ms 34 ms
5 37 ms 37 ms 36 ms
6 36 ms 36 ms 36 ms et-3-1-3-ren-nr-lyon1-rtr-131.noc.renater.fr [193.51.180.172]
7 44 ms 46 ms 44 ms renater-ias-geant-gw.gen.ch.geant.net [83.97.89.13]
8 53 ms 54 ms 53 ms ae5.rt1.fra.de.geant.net [62.40.98.182]
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
11 92 ms 93 ms 92 ms 83.169.204.117
12 * * * Délai d’attente de la demande dépassé.
13 * * * Délai d’attente de la demande dépassé.
14 90 ms 82 ms 83 ms 45.136.21.26
Itinéraire déterminé.
-
Pour avoir testé sur une connexion fibre orange, une fibre bouygues, mon dédié chez online et une instance chez Oracle Cloud :
chez bouygues les deux vidéos sont servies par vd423.mycdn.me
chez orange j'en ai une sur vd339 et une sur vd377
via online j'ai ok6-31.vkuser.net et ok6-30 (mais les vidéos ne se lancent pas du tout)
via oracle j'ai ok6-14 et ok6-4
Est-ce qu'au final le problème vient pas plutôt du site (ou plutôt de son CDN) qui répartit mal la charge et envoie tout le traffic bouygues/sfr/free sur un seul serveur surchargé plutôt qu'un vrai problème réseau ?
-
Tu penses que ce serait le site qui ferait un tri ? Genre "toi OK tu vas là, toi t'as des baskets tu rentres pas ?" :P
Je pense plutôt que c'est la route qui ne te fait pas rentrer au bon endroit.
Quand vous mettez des traceroutes, n'oubliez pas de dire votre ressenti lorsque vous vous déplacez dans le streaming ainsi que la vidéo que vouz avez testée. La 1ère que j'ai mise restera en ligne longtemps mais n'est pas mise au même endroit, c'est pour ça que je recommande de la mettre en 1080p.
La 2ème vidéo, elle ne durera surement pas longtemps (j'en mettrai une autre au besoin), elle, même en 480p, en général, ça passe son temps à "buffer".
Mais là, j'ai bien compris ce qu'il en était pour les FAI français hélas. Je testerai de temps en temps, voir s'il y a une évolution.
-
Tu penses que ce serait le site qui ferait un tri ? Genre "toi OK tu vas là, toi t'as des baskets tu rentres pas ?" :P
Je pense plutôt que c'est la route qui ne te fait pas rentrer au bon endroit.
Oui c'est évident.
Même Google/Youtube utilise la même méthode. Tu passes par du transit ? Hop, je baisse la qualité, et donc le débit. Bien visible ici sur mes graphs pendant une maintenance.
-
OK, je n'y connais pas grand chose par rapport à vous, mais je suppose que ce n'est pas Google qui choisit vraiment ça, c'est qu'ils doivent s'adapter aux limitations de ce "transit" ?
-
Depuis K-Net
Détermination de l’itinéraire vers vd423.mycdn.me [45.136.21.26]
avec un maximum de 30 sauts :
Argh, j'ai pas tout bien lu.
Depuis K-net, c'est plutôt :
>tracert ok6-31.vkuser.net
Détermination de l’itinéraire vers ok6-31.vkuser.net [95.142.206.35]
avec un maximum de 30 sauts :
1 3 ms 2 ms 4 ms k-box.home [192.168.1.1]
2 4 ms 4 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 13 ms 13 ms 13 ms k-net.covage [10.2.0.5]
5 23 ms 22 ms 26 ms 172.16.120.99
6 44 ms 45 ms 46 ms ams-ix.retn.net [80.249.209.216]
7 * * * Délai d’attente de la demande dépassé.
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 47 ms 48 ms 46 ms srv35-206.vkontakte.ru [95.142.206.35]
Itinéraire déterminé.
-
Chez Orange, le seeking est quasiment instantané, que ce soit sur la première vidéo en 4k, ou bien sur celle d'après.
Start: 2024-02-09T12:07:49+0100
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 10 0.5 0.5 0.4 0.9 0.1
2. AS??? 80.10.234.61 0.0% 10 1.8 1.7 1.3 2.1 0.3
3. AS??? lag-10.nelyn37z.rbci.orange.net 50.0% 10 1.9 1.9 1.5 2.4 0.3
4. AS??? ae107-0.nclyo202.rbci.orange.net 0.0% 10 2.1 2.1 1.5 3.5 0.6
5. AS??? ae41-0.nilyo102.rbci.orange.net 0.0% 10 1.7 1.7 1.3 2.3 0.3
6. AS??? ae40-0.nilyo101.rbci.orange.net 0.0% 10 2.0 2.0 1.5 2.5 0.4
7. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. AS??? ae300-0.ffttr7.frankfurt.opentransit.net 0.0% 10 11.9 14.5 11.4 18.6 2.6
9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11. AS47764 185.226.52.72 0.0% 10 49.3 49.6 48.7 51.7 0.9
-
OK, je n'y connais pas grand chose par rapport à vous, mais je suppose que ce n'est pas Google qui choisit vraiment ça, c'est qu'ils doivent s'adapter aux limitations de ce "transit" ?
On voit que le site oriente les internautes vers différents serveurs selon des critères qu'il a lui même définit (et vu les résultats on serait tenté de penser que le FAI influe bcp)
On voit aussi que ses serveurs sont dans des plages IP différentes et vu les pings sûrement dans des datacenter différents.
Le transit c'est le chemin comment atteindre l'IP, le FAI n'a (partiellement) la main que sur cette partie. Le choix du serveur c'est le site qui le fait.
Si ça se trouve en allant chercher la video sur ok6-31 ou vd377 depuis bouygues/sfr on aurait un bon débit et à l'inverse en allant chercher sur vd423 depuis orange on aurait un mauvais débit.
Ce choix de serveur permet de base d'orienter le client vers le serveur le plus proche ou celui le mieux connecté à son FAI (inutile d'envoyer un français sur un serveur aux US si la vidéo est dispo sur un serveur allemand par ex) pour rendre son expérience la meilleure possible (fluidité de navigation, vitesse de téléchargement, ...)
Mais rien n'empêche non plus de l'orienter vers le serveur le moins cher (du point de vue des accords de peering/transit) pour faire baisser la facture. Surtout qu'un internaute français ça doit pas attirer tant que ça les annonceurs Russes.
Après c'est peut être aussi une bête erreur de configuration qui redirige trop de français vers le même serveur entrainant une baisse de qualité.
Et comme ce n'est pas la cible principale du site il n'est peut être même pas au courant de la situation.
Mais pour moi la balle est dans leur camp, ce sont eux qu'il faudrait contacter pour faire avancer le truc.
-
Si ça se trouve en allant chercher la video sur ok6-31 ou vd377 depuis bouygues/sfr on aurait un bon débit et à l'inverse en allant chercher sur vd423 depuis orange on aurait un mauvais débit.
Ca ne changera strictement rien pour Orange, la qualité sera au RdV car nous avons des interconnexions privées (PNI) à la fois avec VK comme avec RETN.
-
Ca ne changera strictement rien pour Orange, la qualité sera au RdV car nous avons des interconnexions privées (PNI) à la fois avec VK comme avec RETN.
Sauf si le serveur en question est surchargé/bridé et que le problème de débit n'est pas lié au réseau, ce qui reste mon hypothèse principale.
-
Exemple de video (obtenue un peu au hasard via une des suggestion du site) qui marche en 1080 sans problème depuis ma connexion Bouygues : https://ok.ru/video/7413516012210
Serveur vd296 : 185.226.53.5, même plage que vd339 mentionné plus haut pour Orange (185.226.52.60)
On voit qu'on a 15Mb/s et que le buffer se remplit vite et la navigation dans la vidéo est plutôt agréable
La même chez orange en passant par un proxy socks : vd258 (185.226.52.8 ), un pic à 70Mb/s puis oscille entre 10 et 20Mb/s : sensiblement pareil niveau ressenti
Pour moi le fond du problème ça reste la redirection vers les serveurs.
Après au final oui, à cause de ce problème, la navigation sur les vidéos est plus agréable via Orange que Bouygues mais difficile de dire que ça vient des FAI
-
Faire des traceroutes pour diagnostiquer un problème en réception ne va pas aider à grand chose.
Il est bien probable que le trafic passe par un chemin différent dans l'autre sens, dans mon cas les paquets vers l'hôte s'échange directement avec le réseau distant alors que dans l'autre sens les paquets arrivent par Megafon.ru et Mts.ru, deux réseaux pourris.
Le MTS.ru est encore plus pourri qu'habituellement depuis le début du mois sachant qu'il s'adonne à de nouvelles pratiques de censure et filtrage qui dégradent fortement les performances. Donc pas de surprises.
-
Le MTS.ru est encore plus pourri qu'habituellement depuis le début du mois sachant qu'il s'adonne à de nouvelles pratiques de censure et filtrage qui dégradent fortement les performances. Donc pas de surprises.
Oui et c'est à dire que certaines choses sont proposées pleine bille quand d'autres rament, et ce sur le même canal "Звезда (https://en.wikipedia.org/wiki/Zvezda_(TV_channel))" pour mon test.
Tucker Carlson manipulé par Poutine, c'est plein gaz dans tous les sens: https://tvzvezda.ru/video/news/202429212-TyUhp.html
Pour comparaison, la cérémonie de clôture du forum Armée 2023, dont tout le monde se fiche: https://tvzvezda.ru/video/news/20238201336-hvkd3.html
Le tout en m3u avec la chaîne en direct, voir en pj:
-
Ecoutez, j'ai l'impression que ça marche mieux désormais (chez Bouygues) ! Je ne sais pas s'il y a eu un changement du côté de ok.ru ou du côté de Bouygues ou si c'est moi qui m'emballe, mais quand je navigue dans la vidéo, je suis en 720p (ou 1080p selon si c'est disponible), et c'est quasiment instantané !
Exemple avec cette 3ème vidéo (https://ok.ru/videoembed/7391426906863?autoplay=1) (même si la 2ème est encore présente)
-
Tient ca marche mieux en effet en 720P 8)
-
fluide avec free
-
C'est incroyable ce forum, j'avais déjà remonté un problème de peering dans le passé, déjà pour Bouygues je crois, et ça avait été résolu, et bien là pareil, ça marche du feu de Dieu (seeking en Full HD sans problème). Donc je suppose que quelqu'un nous a lus, a remonté ça et du coup ça marche super bien.
Merci à ceux qui ont remonté/corrigé le problème !
Je ne sais pas ce qu'il en est pour SFR, Free et les FAI locaux par contre.
-
SFR ok avec la vidéo du 1er post, instantané en 1080, presque parfait en 4K.
-
Je confirme pour Bouygues nickel ! j'ai même testé en 5G bouygues ya bien une différence 8)
-
SFR aussi ? Etonnant ! Alors ce serait plutôt ok.ru qui aurait fait quelque chose ?
Une autre vidéo récente (https://ok.ru/videoembed/7422856858351?autoplay=1), si vous voulez tester, à mettre en Full HD, et utiliser les touches gauche/droite du clavier, et vérifier que ça charge rapidement.
-
Ça donne ça le dernier lien:
https://youtu.be/ZR40mE7sYg8
-
SFR aussi ? Etonnant ! Alors ce serait plutôt ok.ru qui aurait fait quelque chose ?
Une autre vidéo récente (https://ok.ru/videoembed/7422856858351?autoplay=1), si vous voulez tester, à mettre en Full HD, et utiliser les touches gauche/droite du clavier, et vérifier que ça charge rapidement.
Toujours pareil = aucun problème de mon côté derrière un accès Orange.
-
@Denis: Oula malheureux, n'essaie pas d'uploader des vidéos de foot sur youtube, tu vas avoir des problèmes. Elle a déjà été bloquée.
-
En effet ça va très vite, pourtant c'est loin d'avoir ne serait-ce qu'un bout de match.
L'avantage c'est qu'on sait qui jouait :)
-
Pour moi la différence c'est surtout qu'on n'est plus renvoyé vers vd423 depuis une connexion Bouygues y compris sur les anciennes vidéos
Donc je penche toujours sur un problème de CDN corrigé depuis par ok.ru plus que sur un problème de peering
-
Nickel chez Free sur une Pop.
Instantané en 1080p, 1 seconde en 4K.
En wifi sur mon laptop de travail.
-
Aucun soucis avec Bouygues en 1080p, idem en 4K c'est instant
-
Nickel chez Free sur une Pop.
Instantané en 1080p, 1 seconde en 4K.
En wifi sur mon laptop de travail.
J'ai oublié de préciser, laptop du taff bloqué en ipv4 ;)
-
aucun decallage de son/image ici et chargement instantané lorsque l'on se déplace dans la vidéo
-
Free Ultra
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.254 - 18 | 64 | 53 | 0 | 0 | 0 | 0 |
| station11.multimania.isdnet.net - 53 | 21 | 10 | 11 | 12 | 13 | 11 |
| Request timed out. - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
|ipv4.de-cix.fra.de.as31133-frnkt-pe-mx960-1.megafon.ru - 92 | 12 | 1 | 0 | 23 | 23 | 23 |
| 83.169.204.105 - 58 | 19 | 8 | 0 | 60 | 61 | 61 |
| 83.169.204.81 - 74 | 15 | 4 | 0 | 59 | 60 | 59 |
| 10.222.78.133 - 85 | 13 | 2 | 58 | 58 | 58 | 58 |
| 83.169.204.117 - 0 | 868 | 868 | 57 | 58 | 163 | 58 |
| Request timed out. - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| 45.136.21.26 - 0 | 856 | 856 | 58 | 58 | 60 | 59 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
-
Tant qu'on est dans la Russie, vous savez quel opérateur des 4, possède le meilleur peering là bas ?
-
je dirais MegaFon pour les RS ou Vimpelcom
-
je dirais MegaFon pour les RS ou Vimpelcom
Je me suis mal exprimé, je parlais par rapport à nous français, mais merci quand même je vais pouvoir regarder les noms que tu as donné