La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => 
Débit fibre SFR => Discussion démarrée par: K-L le 15 juin 2022 à 23:13:22
-
Hello,
Je possède une instance PeerTube sur https://video.amiga-ng.org
Elle est hébergée sur une connexion SFR FTTH 1Gbs/500Mbs (chez moi donc).
Si un visiteur utilise une connexion FTTH SFR (peut-être ADSL aussi, je n'ai pas testé), les débits sont largement suffisants (avec des pointes à 6-7 Mo/s) pour que la vidéo ne bufferise pas constamment.
Mais toute autre connexion provenant d'un autre opérateur (même SFR en HFC) ne dépassera jamais les 1Mo/s, ce qui fait que certaines videos vont bufferiser.
Essais fait avec deux connexion SFR FTTH différentes, une connexion fibre Orange, une 4G Bouygues et ma seconde connexion SFR HFC.
Une idée ? Un bridage du côté SFR ?
-
Hello,
je suis à 1 MB pour ma part et je suis chez SFR en Fibre ???
-
Mais toute autre connexion provenant d'un autre opérateur (même SFR en HFC) ne dépassera jamais les 1Mo/s,
La preuve que non, fibre Sosh et 11Mb/s
-
Donc 1 Mo/s comme je le disais. ;)
(Toujours faire attention aux unités).
-
Hello,
je suis à 1 MB pour ma part et je suis chez SFR en Fibre ???
Ah, merci, bizarre que sur la connexion SFR FTTH chez mon pote, ça fuse, ce serait local ?
Merci pour le retour en tout cas :)
-
Ah, merci, bizarre que sur la connexion SFR FTTH chez mon pote, ça fuse, ce serait local ?
Merci pour le retour en tout cas :)
Je monte en tout cas pas au dessus :-X
Idem via 4g Sosh et 5g Bouygues
-
sur une ligne VDSL Orange à 90Mbps, dans le Gard (30) je plafonne a 1MB, mais ca ne "bufferise pas", par contre si je passe la video en 1080p, là oui.
sur une ligne FTTO Bouygues 100Mbps, idem, 1MB, et bufferise en 1080p.
-
Salut voisin,
Depuis Free, idem (bridage à 1 Mo et buffer en 1080p).
-
Bonjour,
Depuis Jaguar Network je note une limitation à 11 Mb/s (1,2 Mio/s) avec un navigateur web, même en demandant le téléchargement de plusieurs vidéos simultanément.
Depuis Bouygues Telecom le débit moyen de 1,04 Mio/s sur les 20 premières secondes :
curl --max-time 20 -o /dev/null https://video.amiga-ng.org/download/videos/e508795c-c33c-4221-9746-5c11cc5061bc-1080.mp4
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 1978M 1 20.2M 0 0 1035k 0 0:32:36 0:00:19 0:32:17 1160k
curl: (28) Operation timed out after 20000 milliseconds with 21208632 out of 2074823590 bytes received
Depuis Adeli, le débit moyen de 1,09 Mio/s sur les 20 premières secondes :
$ curl --max-time 20 -o /dev/null https://video.amiga-ng.org/download/videos/e508795c-c33c-4221-9746-5c11cc5061bc-1080.mp4
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 1978M 1 21.3M 0 0 1094k 0 0:30:50 0:00:19 0:30:31 1146k
Depuis Appliwave, le débit moyen de 1,13 Mio/s sur les 20 premières secondes :
$ curl --max-time 20 -o /dev/null https://video.amiga-ng.org/download/videos/e508795c-c33c-4221-9746-5c11cc5061bc-1080.mp4
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 1978M 1 22.1M 0 0 1131k 0 0:29:50 0:00:19 0:29:31 1260k
-
Donc 1 Mo/s comme je le disais. ;)
(Toujours faire attention aux unités).
Ben, 1 Mo/s c'est 8 Mb/s, pas 11
-
Abonné SFR FTTH au cannet (06), 10Mbits max au total, quel que soit le nombre de videos lancées.
C'est assez proche du problème que je remonte depuis plusieurs semaines (https://lafibre.info/sfr-debit/fibre-sfr-uploads-limites-a-1020mbits-par-thread/) et pour lequel le support SFR semble assez défaillant.
Il y a eu une résolution temporaire pendant quelques heures avant hier entre 16h30 et 00h30 comme vu sur le graph excel ci-dessous, mais ça a à nouveau pété suite à cet incident. (https://lafibre.info/sfr-espace-technique/incident-sur-le-dhcp-sfr-cette-nuit/)
-
Vu que le problème est reproduit avec iPerf3, je comprends que cela impacte n'importe quel port.
Serait-il possible de tester avec SpeedTest.net en forçant un test mono-connexion puis avec un test multi-connexion (sur le même serveur) qui pourrait avoir un débit multiplié par 16.
-
Ma nouvelle IP étant "géolocalisée" à Troyes, speedtest.net ne me propose plus que des serveurs vers paris, je ne peux pas sélectionner ceux plus proches sur le réseau SFR qui auraient de meilleures perfs en multi, voici les résultats sur Appliwave BBR :
Single :
(https://www.speedtest.net/result/13288706486.png)
Multi :
(https://www.speedtest.net/result/13288703052.png)
-
Merci, la démonstration marche bien, pas la peine de monter un serveur web.
K-L tu fais les mêmes tests ?
Tu peut filtrer les serveurs avec du texte. Entre "SFR" pour voir s'afficher tous les serveurs SFR.
MrReed : Le serveur SFR de Lyon pourrait être intéressant pour toi, mais il est toujours intéressant de faire des tests avec un serveur hors du réseau
-
Oui, celui de Venissieux est typiquement celui qui fonctionne le mieux (curieusement depuis mon changement d'IP, via nperf, c'est celui de Corbas qui est le plus rapide en upload), mais malheureusement, même en saisissant SFR dans le champ de recherche, speedtest.net ne me propose toujours que ceux autour de Paris, et le noeud SFR Paris est encore plus lent qu'Appliwave.
-
Tu peut filtrer sur n'importe quel serveur (je viens de vérifier en testant un serveur en Australie).
Par contre presque tous les serveurs SpeedTest de SFR ne sont plus disponible en https, a cause d'un problème de certificat https.
Tu peut le tester en utilisant l’application SpeedTest, qui réalise un test http : https://www.speedtest.net/apps/windows
(il existe une version Mac et une version Linux en ligne de commande)
-
Tu peut filtrer sur n'importe quel serveur (je viens de vérifier en testant un serveur en Australie).
Bien vu ! j'avais pas fait gaffe
Tu peut le tester en utilisant l’application SpeedTest, qui réalise un test http : https://www.speedtest.net/apps/windows
En effet, pas de recherche ou de mode mono sur celle là, mais je peux choisir des serveurs jusqu'à 200 miles de ma géolocalisation, dont SFR Lyon :
(https://www.speedtest.net/result/d/8403103c-2816-4fef-9aa1-4dcd3d601565.png)
-
Vu que le problème est reproduit avec iPerf3, je comprends que cela impacte n'importe quel port.
Serait-il possible de tester avec SpeedTest.net en forçant un test mono-connexion puis avec un test multi-connexion (sur le même serveur) qui pourrait avoir un débit multiplié par 16.
Peux-tu me préciser comment tester en mono-connexion ?
-
Peux-tu me préciser comment tester en mono-connexion ?
Je me permets de répondre :
Sur le site speedtest.net après avoir sélectionné ton serveur de test le plus proche, tu peux passer en mode mono/single avec le bouton juste en dessous :
-
Merci.
C'est pas flagrant :(
-
En effet, il y a de la saturation (ou de l'occupation réseau par le serveur web?), mais c'est beaucoup moins flagrant
-
Là, ça devient technique :)
Ce PeerTube est une VM sur un Mac Pro Octocoeurs de 2008.
J'ai aussi un VM OwnCloud (sur un port différent) et une VM Jitsi (aussi sur un port différent) sur ce même serveur et ils ne posent aucun souci de débit. ???
-
En effet, les autres VMs n'ont aucun souci.
Je vais me diriger vers ton idée, merci ;)
-
J'ai en effet modifié des paramètres mais j'ai essayé de mon côté et ça ne fonctionne pas, toujours limité à 1Mo/s (avec ma seconde connexion câble en 100Mbs).
Ce n'est pas une histoire de cache de ton navigateur ?
-
J'ai essayé de mon côté aussi, 10Mbits y'a quelques minutes, et là je viens de tirer du 100Mbits sur une des vidéos
Edit, et 20Mbits sur une autre.
-
Tout est revenu à 10Mbits.
Petites questions, les VM sont sur un(des) SSD ou un(des) Disque(s) Dur(s)? Y'a un cache mémoire dans la VM peertube?
En cas d'accès concurrents par tout ce petit monde, en l'absence de mise en cache (ou de raid 5/6) ça va faire plonger les I/O si c'est sur du stockage mécanique.
Mais franchement cette hypothèse tient peu la route, la bride à 10/12 Mbits est trop régulière et "propre"
-
Il est possible que la limitation à 10 Mb/s soit fait pour ne pas télécharger trop de données inutiles.
Habituellement une vidéo 1080p n'a pas de raison d'avoir un débit > 10 Mb/s, bien encodée (pas l'encodage d'un appareil photo) on arrive à avoir une pleine qualité pour 6 Mb/s en H.264 (on peu même descendre bien en-dessous).
-
Vivien : non, bien entendu, aucune session PeerTube ne fonctionne ainsi (surtout que celle de mon pote fonctionne sans limite). D'ailleurs les limites sont configurables dans les fichiers de configuration de PeerTube. Elles sont ok ici.
MeReed, Ouno : je vais continuer à essayer de comprendre si tout se passe côté configuration TCP, sait-on jamais.
-
Bon, j'ai modifié des tas de paramètres, utilisé des sysctl.conf tout faits, pas mieux.
Donc pas moyen de savoir si c'est ma VM ou SFR.
Le fichier sysctl.conf utilisé :
### KERNEL TUNING ###
# Increase size of file handles and inode cache
fs.file-max = 2097152
# Do less swapping
vm.swappiness = 10
vm.dirty_ratio = 60
vm.dirty_background_ratio = 2
# Sets the time before the kernel considers migrating a proccess to another core
kernel.sched_migration_cost_ns = 5000000
# Group tasks by TTY
#kernel.sched_autogroup_enabled = 0
### GENERAL NETWORK SECURITY OPTIONS ###
# Number of times SYNACKs for passive TCP connection.
net.ipv4.tcp_synack_retries = 2
# Allowed local port range
net.ipv4.ip_local_port_range = 2000 65535
# Protect Against TCP Time-Wait
net.ipv4.tcp_rfc1337 = 1
# Control Syncookies
net.ipv4.tcp_syncookies = 1
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15
# Decrease the time default value for connections to keep alive
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
### TUNING NETWORK PERFORMANCE ###
# Default Socket Receive Buffer
net.core.rmem_default = 31457280
# Maximum Socket Receive Buffer
net.core.rmem_max = 33554432
# Default Socket Send Buffer
net.core.wmem_default = 31457280
# Maximum Socket Send Buffer
net.core.wmem_max = 33554432
# Increase number of incoming connections
net.core.somaxconn = 65535
# Increase number of incoming connections backlog
net.core.netdev_max_backlog = 65536
# Increase the maximum amount of option memory buffers
net.core.optmem_max = 25165824
# Increase the maximum total buffer-space allocatable
# This is measured in units of pages (4096 bytes)
net.ipv4.tcp_mem = 786432 1048576 26777216
net.ipv4.udp_mem = 65536 131072 262144
# Increase the read-buffer space allocatable
net.ipv4.tcp_rmem = 8192 87380 33554432
net.ipv4.udp_rmem_min = 16384
# Increase the write-buffer-space allocatable
net.ipv4.tcp_wmem = 8192 65536 33554432
net.ipv4.udp_wmem_min = 16384
# Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
-
Je ne suis pas un adepte du tunning dans des valeurs extrêmes.
Même pour un serveur très utilisé ou un serveur de test de débit, ces valeurs sont surdimensionnées.
-
Merci, je m'en doutais un peu.
On peut donc oublié un problème de ce côté alors.
-
Pour information, les valeurs que j'utilise pour mes serveurs : https://lafibre.info/ubuntu/securisation-serveur/msg898838/#msg898838
-
Merci, j'ai modifié le fichier en conséquence.
Bon, ça ne change rien à cette limitation qui va rester ainsi encore très longtemps à mon avis :)
-
Bon, ben on va pouvoir passer en résolu.
Et je m'en veux.
Il faut toujours RTFM.
https://kb.parallels.com/4948
Virtio network adapter is the fastest card. However, it works only in Linux and BSD guest operating systems. It is a default adapter for Linux-based OSes.
Et bien sûr, j'en avais sélectionné un autre.
Merci à tous pous l'aide apportée et vos conseils avisés.
-
Content que ce soit résolu pour toi !
Les gotcha de ce genre dans la virtualisation y'en a en pagaille, j'administre entre autres quelques clusters ESX, c'est pas ça qui manque là non plus xD
@ Vivien, une idée pour ce qui me concerne ?