La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: jpenuchot le 05 mars 2022 à 23:45:54
-
Bonjour,
Je constate que les debits IPv6 sur ma Freebox Delta S sont absolument honteux.
curl -6 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 -o /dev/nullDebit: ~80ko/s
curl -4 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 -o /dev/nullDebit: ~30Mo/s
Je fais ce test sur une machine raccordee en SFP+ a ma box, sur les speedtests j'arrive a obtenir des debits autour de 7.4gbps.
Un petit apercu du tracepath en IPv4, puis en IPv6... j'ai envie de hurler:
jpenuchot@jpenuchot-nzxt ~> tracepath -4 steamdeck-images.steamos.cloud
1?: [LOCALHOST] pmtu 1500
1: _gateway 0.231ms
1: _gateway 0.170ms
2: 194.149.169.85 2.657ms
3: 193.51.187.209 2.604ms
4: ae2.mpr1.cdg11.fr.zip.zayo.com 1.672ms
5: ae27.cs1.cdg11.fr.eth.zayo.com 10.372ms asymm 10
6: ae2.cs1.fra9.de.eth.zayo.com 10.673ms asymm 9
7: ae27.mpr1.fra4.de.zip.zayo.com 10.416ms
8: no reply
9: a2-16-186-80.deploy.static.akamaitechnologies.com 9.933ms reached
Resume: pmtu 1500 hops 9 back 9
jpenuchot@jpenuchot-nzxt ~> tracepath -6 steamdeck-images.steamos.cloud
1?: [LOCALHOST] 0.004ms pmtu 1500
1: 2a01:e0a:227:6b00::1 0.241ms
1: 2a01:e0a:227:6b00::1 0.237ms
2: 2a01:e00:203a:f836:8d2d::ffff 2.163ms
3: no reply
4: 2a01:e00:203a::2 2.120ms
5: no reply
6: no reply
7: no reply
8: prs-bb1-v6.ip.twelve99.net 85.723ms asymm 12
9: ffm-bb2-v6.ip.twelve99.net 85.767ms asymm 11
10: no reply
11: akamai-ic341387-ffm-b11.ip.twelve99-cust.net 83.140ms asymm 12
12: ae2.r01.fra03.icn.netarch.akamai.com 135.666ms asymm 18
13: ae3.r01.fra02.icn.netarch.akamai.com 166.484ms asymm 18
14: ae1.r01.fra02.ien.netarch.akamai.com 53.101ms asymm 12
15: no reply
16: g2a02-26f0-6c00-0000-0000-0000-0210-ba58.deploy.static.akamaitechnologies.com 85.124ms reached
Resume: pmtu 1500 hops 16 back 12
166ms de ping au 13e hop en IPv6. On n'est pas rendus.
Voila voila, si ca peut donner des pistes aux gens qui ont des soucis de debit un peu random avec leur Freebox tant mieux. Si j'ai bien compris c'est un souci de peering IPv6 avec Free, du coup je me demandais s'ils etaient les seuls (sans parler d'IPv4 bien sur) ?
-
Bonjour,
le soucis semblent localisé à cette destination précise non ? (voire un incident temporaire)?
as tu le même soucis sur
http://ping.online.net/10000Mo.dat (IPv4)
http://ping6.online.net/10000Mo.dat (IPv6)
et
https://gra.proof.ovh.net/files/10Gb.dat (IPv4)
https://ipv6.gra.proof.ovh.net/files/10Gb.dat (IPv6)
-
Bonjour,
En effet l'incident est localise et temporaire, je viens de relancer mon test et je monte a 100Mo/s en IPv6. Les debits sont corrects vers les liens que tu as postes.
Toutefois, un incident "local" sur un des plus gros CDN c'est pas ouf.
J'essaierai de faire des tests de debit regulierement pour voir si c'est recurrent ou pas. En tout cas j'ai deja eu d'autres comportements chelous en IPv6, une fois c'etait Wikipedia qui avait un ping hyper variable (ca sautait de ~17ms a ~1000ms) alors que l'IPv4 repondait parfaitement.
Faudrait que je reflechisse a automatiser des tests de debit IPv4 + IPv6, reguliers et vers plusieurs hebergeurs pour avoir un bel echantillon, ce serait plus interessant que deux tests en one shot a des horaires differents.
PS: J'oubliais aussi, a l'heure ou je faisais mes tests de debit avec l'ISO SteamOS j'etais a 80ko/s pour le telechargement d'un package sur Flathub...
-
Le soucis c'est que l'on ne voit pas sur ton traceroute IPv6 où le problème arrive exactement.
Après les incidents sur des routeurs localisés chez Free ou chez les transitaires çà arrive (comme partout)..
Je pense qu'il faut voir si ça se reproduit (et donc si c'est une saturation) ou si c'était un incident.
-
Je sais pas si c'est lié ou non mais hier soir un pote à moi pareil depuis Ionos avait un ping et un débit merdique (le serveur se trouvait en Allemagne) mais passer par Telia puis GTT puis par DE-CIX et c'est à partir de DE-CIX que la saturation commencé d'après le traceroute :
traceroute to 2a01:e0a:21f:e7c0::1 (2a01:e0a:21f:e7c0::1), 30 hops max, 80 byte packets
1 fd8b::2 (fd8b::2) 0.149 ms
2 2001:8d8:0:202::3 (2001:8d8:0:202::3) 1.030 ms
3 ae-1-0.bb-a.bap.rhr.de.net.ionos.com (2001:8d8:0:a:8) 0.456 ms
4 ae-10-0.bb-a.fra3.fra.de.net.ionos.com (2001:8d8:0:2::f1) 4.616 ms
5 *
6 gtt-ic342859-ffm-b11.ip.twelve99-cust.net (2001:2000:3080:1ac1::2) 6.131 ms
7 ae3.cr2-fra6.ip6.gtt.net (2001:668:0:3:ffff:0:d5fe:c401) 19.675 ms
8 2001:668:0:3:ffff:1:0:19de (2001:668:0:3:ffff:1:0:19de) 3.844 ms
9 2001:668:0:3:ffff:1:0:19de (2001:668:0:3:ffff:1:0:19de) 5.386 ms
10 decix.proxad.net (2001:7f8::3022:0:1) 65.994 ms
11 *
12 *
13 *
14 2a01:e06:3:1700:fe00::96ea (2a01:e06:3:1700:fe00::96ea) 69.812 ms
Mais ce matin c'est revenu à la normal, du coup je sais pas si c'est vraiment lié
-
Je sais pas si c'est lié ou non mais hier soir un pote à moi pareil depuis Ionos avait un ping et un débit merdique (le serveur se trouvait en Allemagne) mais passer par Telia puis GTT puis par DE-CIX et c'est à partir de DE-CIX que la saturation commencé d'après le traceroute :
[...]
Mais ce matin c'est revenu à la normal, du coup je sais pas si c'est vraiment lié
Ne jamais oublier qu'il peut y avoir des "pépins" sur une liaison, et qu'une fois que l'on passe par "l'itinéraire bis", les choses ne vont plus à la même vitesse (un pépin sur l'autoroute, et vous avez du bol, on vous fait sortir à la première sortie, mais ensuite, vous vous tapez 200 bornes de nationale à double sens... 80km/h + traversées de patelin, ce n'est plus la même...!), en sachant que tout ceci est géré au final par des humains, et s'il est une choses qui est faillible, c'est bien l'humain! ;)
-
En plus là on parle d'un CDN et visiblement il t'envoyait pas du tout sur le même serveur en IPv4 et en IPv6.
-
Après les erreurs de routes, ça existe. Au premier confinement, pour me connecter au VPN France de mon boulot (à 20km de chez moi), via Free la liaison passait....par les US ! 160ms le ping ! Je me connectais au VPN en UK pour avoir un ping descent (30 ms). Cela ne concernait que les employés chez Free.
J'ai râlé et je pense que les IT chez nous ont échangé avec le FAI Verizon et finalement c'est descendu.... à 20 ms. Je soupçonne que Verizon fait quand même passer le trafic via UK.
Depuis on a changé de FAI et le VPN ne fait plus que 6ms. Mais quand même pour le routage il y a un facteur humain parfois qui peut faire des erreurs.
Suffit de râler assez fort et au bout du compte ça se fixe.
-
Il y'a 3 ans, pour me connecter au VPN du boulot ( ipv4 sur fibre Nérim ), la route passait par AMS-IX ( Amsterdam ? ). Je trouvais ça complètement con ...
Aujourd'hui ça passe par Hopus sur Paris.
-
J'ai eu le même problème pour me connecter au VPN du boulot derrière RENATER pendant le confinement, malgré le peering entre RENATER et Free à Paris ça faisait le tour de l'Europe via Amsterdam et Londres en passant par GEANT (le "RENATER européen").
-
3 ans après, je dois reconnaitre que ça a quand même l'air d'avoir bien changé.
Plus de saturation sur les intercos.
Des routes assez diversifiées
Des routes qui semble "logique" au vu de la distance, pas de détour bizarre etc.
Tout ça ne concerne que mon usage biensur et n'est pas une vérité vrai, à voir dans le temps ...
-
Entièrement d'accord avec noks, c'est bien mieux que lors de mon dernier passage en 2018 (c'est qui m'avait fait partir vers orange).
-
Entièrement d'accord avec noks, c'est bien mieux que lors de mon dernier passage en 2018 (c'est qui m'avait fait partir vers orange).
Idem, Fin 2019 j'ai fuie après 1 mois d'abonnement tellement c'était catastrophique et inutilisable.
-
depuis Free Pro il y a aussi des différences.
en IPv6 c'est tres variable (de 100 Mbps a 1Gbps mais le plus souvent autour de 120Mbps), en IPv4 stable (autour de 1 Gbps ou au dela).
donc un ratio x10.
et si on lance les 2 meme temps:
./nspeed_linux_amd64 get -4 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 get -6 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2
Jobs:
0 HTTP client {Method: GET, URL: "https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2", IPversion: 4, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Method: GET, URL: "https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2", IPversion: 6, Address: , Group: 1, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
6:42PM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 1.1 Gbps| 0 bps| 7.99| 1.1 GB| 0 B|get https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 (104.123.50.170:443 - 3.422 ms)
Job 1| 136.0 Mbps| 0 bps| 7.96| 135.3 MB| 0 B|get https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 ([2a02:26f0:105::216:1652]:443 - 3.396 ms)
Total| 1.2 Gbps| 0 bps| 7.99| 1.2 GB| 0 B|
en regardant avec traceroute on voit que JN (FreePro) peer directement avec ce noeud Akamai en IPv4 mais transit par Level3 en IPv6.
-
RAS depuis une connexion Orange GP.
$ curl -6 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2519M 100 2519M 0 0 95.1M 0 0:00:26 0:00:26 --:--:-- 95.9M
mtr steamdeck-images.steamos.cloud -zerwc10
Start: 2022-03-07T19:01:44+0100
HOST: `redacted` Loss% Snt Last Avg Best Wrst StDev
1. AS3215 2a01:xxxx:xxxx:xxxx::1 0.0% 10 0.4 0.4 0.4 0.6 0.1
2. AS3215 2a01cb08a004020c0193025300750245.ipv6.abo.wanadoo.fr 0.0% 10 1.8 1.5 0.9 2.0 0.4
3. AS??? 2a01:cfc4:0:a00::b 0.0% 10 1.8 2.1 1.5 2.5 0.4
4. AS??? 2a01:cfc4:0:b00::b 0.0% 10 2.2 2.0 1.2 2.5 0.4
[MPLS: Lbl 2830 Exp 0 S u TTL 1]
5. AS??? bundle-ether101.auvtr5.aubervilliers.opentransit.net 50.0% 10 7.1 7.3 6.9 7.7 0.3
6. AS5511 2001:688:0:2:1::2ed 20.0% 10 9.5 7.6 7.0 9.5 0.8
7. AS5511 2001:688:0:2:1::375 0.0% 10 7.3 7.6 7.2 8.0 0.3
8. AS5511 2001:688:0:3:9::1a8 0.0% 10 9.4 12.3 7.3 37.0 9.2
9. AS20940 vlan-102.r16.spine101.par02.fab.netarch.akamai.com 0.0% 10 7.1 7.0 6.6 7.4 0.3
10. AS20940 vlan-124.r02.leaf102.par02.fab.netarch.akamai.com 0.0% 10 7.9 7.4 6.9 7.9 0.3
11. AS20940 vlan-104.r04.tor102.par02.fab.netarch.akamai.com 0.0% 10 7.1 7.2 6.7 7.9 0.3
12. AS20940 g2a02-26f0-9100-001a-0000-0000-6011-ce1a.deploy.static.akamaitechnologies.com 0.0% 10 6.6 7.0 6.5 7.4 0.3
-
Depuis une VM dans la Delta à l'instant :
noks@Ubuntu:~$ curl -6 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2519M 100 2519M 0 0 185M 0 0:00:13 0:00:13 --:--:-- 184M
noks@Ubuntu:~$ mtr steamdeck-images.steamos.cloud -zerwc10
Start: 2022-03-07T19:35:09+0100
HOST: Ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS12322 2a01:e0a:cc:e60::1 0.0% 10 0.4 0.3 0.3 0.4 0.0
2. AS12322 2a01:e05:9:f836:7e01::ffff 0.0% 10 2.0 2.6 2.0 4.1 0.6
3. AS12322 2a01:e05:9:1700::ffff 0.0% 10 3.0 4.1 1.8 13.3 3.5
4. AS12322 2a01:e05:4::9 90.0% 10 6.8 6.8 6.8 6.8 0.0
5. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6. AS12322 2a01:e00:6003::1 60.0% 10 11.7 11.9 11.6 12.5 0.4
7. AS20940 ae5.data4-par2.netarch.akamai.com 0.0% 10 198.3 43.5 12.3 198.3 59.4
8. AS20940 g2a02-26f0-9400-0000-0000-0000-0215-2283.deploy.static.akamaitechnologies.com 0.0% 10 12.5 12.3 12.0 12.8 0.3
EDIT : ou est-ce que je peux récuperer Nspeed ?
-
ici : https://dl.nspeed.app/nspeed-client/latest/
-
Bon alors évidement comme un babouin j'ai voulu utiliser ton script amd64 sur ma VM sur une Delta avec un proco ARM ...
Bref avec la version windows donc, limité à une carte réseau 1G ça donne ça :
PS C:\Users\Noks\Downloads> .\nspeed_windows_amd64.exe get -4 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 get -6 https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2
Jobs:
0 HTTP client {Method: GET, URL: "https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2", IPversion: 4, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Method: GET, URL: "https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2", IPversion: 6, Address: , Group: 1, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
10:13PM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 457.3 Mbps| 0 bps| 8.00| 457.4 MB| 0 B|get https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 (2.16.170.40:443 - 22.441 ms)
Job 1| 365.2 Mbps| 0 bps| 7.99| 364.9 MB| 0 B|get https://steamdeck-images.steamos.cloud/recovery/steamdeck-recovery-1.img.bz2 ([2a02:26f0:6000::5c7b:f529]:443 - 19.431 ms)
Total| 822.2 Mbps| 0 bps| 8.00| 822.3 MB| 0 B|
-
Bon alors évidement comme un babouin j'ai voulu utiliser ton script amd64 sur ma VM sur une Delta avec un proco ARM ...
je ferais un build arm a la prochaine release.
-
je ferais un build arm a la prochaine release.
Avec plaisir je prends. J'ai bien une VM OpenSUSE sur mon desktop Windows mais qui sera de toute façon aussi limitée aux 1G de la carte réseau de l'hôte.
-
Depuis une VM dans la Delta à l'instant :
Le traceroute est redevenu plus normal.