La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: jeremyp3 le 21 février 2016 à 09:43:55
-
bonjour,
je me décide a écrire pour un problème de NAT sous Debian. en effet, depuis que je suis passer chez orange en FTTH get, je me rends plus compte de la faiblesse de ma configuration. je précise que mon linux est directement connecté a l'ONT.
un test de téléchargement de 5000Mo.dat depuis le serveur directement:
wget -4 -O /dev/null http://1.testdebit.info/fichiers/5000Mo.dat
--2016-02-21 09:11:27-- http://1.testdebit.info/fichiers/5000Mo.dat
Résolution de 1.testdebit.info (1.testdebit.info)… 194.158.102.114
Connexion à 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 5000000000 (4,7G)
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================>] 4,66G 94,8MB/s ds 59s
2016-02-21 09:12:27 (80,3 MB/s) — « /dev/null » sauvegardé [5000000000/5000000000]
le même fichier depuis une machine derrière le nat:
--2016-02-21 09:09:41-- http://1.testdebit.info/fichiers/5000Mo.dat
Résolution de 1.testdebit.info (1.testdebit.info)… 194.158.102.114
Connexion à 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 5000000000 (4,7G)
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================>] 4,66G 52,4MB/s ds 82s
2016-02-21 09:11:03 (58,4 MB/s) — « /dev/null » sauvegardé [5000000000/5000000000]
le serveur et la machine derrière le nat sont connectés par un cable rj45 de l'une à l'autre
un traceroute vers 1.testdebit.info:
traceroute to 1.testdebit.info (194.158.102.114), 30 hops max, 60 byte packets
1 192.168.9.1 (192.168.9.1) 0.179 ms 0.138 ms 0.107 ms
2 80.10.232.109 (80.10.232.109) 1.062 ms 1.527 ms 1.773 ms
3 ae113-0.ncbay102.Bayonne.francetelecom.net (193.253.94.222) 2.197 ms 2.292 ms 2.385 ms
4 ae42-0.nrpoi202.Poitiers.francetelecom.net (81.253.130.246) 12.425 ms 12.530 ms 12.522 ms
5 ae44-0.nridf102.Aubervilliers.francetelecom.net (193.251.126.202) 19.876 ms 19.876 ms 19.855 ms
6 ae41-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.106) 20.267 ms 19.563 ms 19.656 ms
7 la105.rpt01-ix2.net.bbox.fr (62.34.0.209) 20.676 ms 19.811 ms 20.475 ms
8 be12.cbr01-ntr.net.bbox.fr (212.194.171.87) 21.048 ms 21.036 ms 21.010 ms
9 * * *
10 194.158.102.114 (194.158.102.114) 20.643 ms 20.671 ms 20.752 ms
un téléchargement d'un fichier en locale de la machine derrière le nat vers le lightpd du serveur:
--2016-02-21 09:18:04-- http://192.168.9.1/image.aaa
Connexion à 192.168.9.1:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 678526976 (647M) [application/octet-stream]
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================>] 647,09M 112MB/s ds 5,8s
2016-02-21 09:18:10 (112 MB/s) — « /dev/null » sauvegardé [678526976/678526976
un cpuinfo du serveur:
root@routeurlinux:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Celeron(R) CPU G1610T @ 2.30GHz
stepping : 9
microcode : 0x19
cpu MHz : 2294.813
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4589.62
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Celeron(R) CPU G1610T @ 2.30GHz
stepping : 9
microcode : 0x19
cpu MHz : 2294.813
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4589.62
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
le noyau du serveur est en 3.16 avec une jessie 64 bit
la machine cliente derrière le nat est avec un noyau 4.3 sur une jessie 64 bit.
il faut noter que je n'es pas fait de test en ipv6.
merci de m'avoir lu jusqu'ici !
jerem
-
Ta connexion Orange a un MTU de 1500 ? Il me semble que non.
Tu pourrais tester sur ton PC client en forçant une MTU de 1460 pour voir cela améliore le débit (il est probable que la bonne valeur de MTU sois 1492 mais il est préférable de tester plus bas, au cas où il y aurait du L2TP)
Pour passer la MTU à 1460, il suffit de rajouter une ligne mtu 1460 dans ton fichier /etc/network/interfaces au niveau de l'interface Ethernet.
Si cela améliore le débit, il suffira ensuite de demander au NAT de Debian de baisser la MTU. La fragmentation, c'est pas terrible pour les débits.
-
salut vivien,
je suis en dhcp avec orange donc MTU de 1500 oui. du moins, je crois.
jerem
-
SI la MTU n'est pas la cause, il n'y aurait pas un lien en half duplex ? (cela limite le débit et entraîne des collisions)
Je ne pense pas que le CPU soit le facteur limitant, mais regarde quand même la charge cœur par cœur lors d'un gros transfert au débit max.
-
Bonjour,
Visiblement c'est pas un problème des liens eux même. As tu regardé la charge de ta machine (CPU / RAM) lors du transfert ? Avec un htop ou un top.
Pour être sûr, ton routeur à bien deux connexions ? Une vers l'ONT et une autre vers ta machine ?
À+
-
bonjour,
oui oui 2 connexions différentes, 2x1gbps
pas de charge particulière du CPU avec top
merci,
jerem
-
probablement une saturation du cpu.
c'est la config avec QoS 6 par défaut + iptables pour remettre a 0 ?
ca ne m'étonnerai pas que ca sature le cpu quand en plus on fait du NAT.
regarde la charge cpu du serveur pendant un test du client (avec htop par exemple).
-
c'est la config avec QoS 6 par défaut + iptables pour remettre a 0 ?
oui.
ca ne m'étonnerai pas que ca sature le cpu quand en plus on fait du NAT.
regarde la charge cpu du serveur pendant un test du client (avec htop par exemple).
j'ai fait une capture quand le transfert est a mi chemin. désolé mais avec orca (lecteur d'écrant) c'est ingérable. donc obligé de vous le montrer
-
le load average est a plus de 1 sur un bi-core et les %cpu sont bas. Il y a donc quelque chose.
Regarde avec juste 'sudo top' (ou 'top' sous root) pendant un test.
Les infos dans le 3eme ligne surtout 'sy', 'id', 'wa', 'hi', 'si':
'sy': system - %age de temps dans le noyau (kernel)
'id': idle - %age de temps inactif
'wa': wait - %age de temps a attendre des I/O par exemple
'hi': hardware interrupts: interruptions matérielles
'si': software interrupts: interruptions logicielles
-
fait aussi un double test sur le client: tu lances 2 fois le wget en meme temps , ca peut mettre en évidence un probleme de threading sur le serveur (1000Mo suffit).
-
Uptime de 305 jours !
jeremyp3 n'hésites pas a nous poster l'écran du sudo top, l'outil est vraiment pas bien fait pour les non-voyants.
La 3ème ligne commence par "%Cpu(s):" et il y a ensuite des chiffres suivit des deux lettres qui indique la signification du chiffre précédent.
Cela permettra de comprendre ce qui charge ton ordinateur (ce n'est pas le CPU vu ce que donne ton htop, mais cela pourrait être des attentes pour des interruptions)
-
"Intel(R) Celeron(R) CPU G1610T @ 2.30GHz"
Voilà, tout est dis : c'est le matos qui limite, car j'imagine sans mal que le chipset et donc le réseau c'est du même ordre.
Dans le BIOS, tu peux monter le "PCI Delay Transaction" et tu fous ton LAN en MTU 9k pour limiter le nbre de paquets. Ca te permettra de de gratter qq Mbps.
-
C'est un routeur qu'il fait, pas besoin d'un processeur puisant et le Celeron G1610T (2M Cache, 2.30 GHz) est quand même bien puissant. C'est un processeur 64bits récent, équipé de deux cœurs, qui ont les Technologie de virtualisation Intel® (VT-x) et VT-x avec tables de pagination (Extended Page Tables). Ok il ne serait pas bon en serveur (bien qu'il gère 32Go de ram) mais pour un routeur, aucun souci.
-
C'est un routeur qu'il fait, pas besoin d'un processeur puisant et le Celeron G1610T (2M Cache, 2.30 GHz) est quand même bien puissant. C'est un processeur 64bits récent, équipé de deux cœurs, qui ont les Technologie de virtualisation Intel® (VT-x) et VT-x avec tables de pagination (Extended Page Tables). Ok il ne serait pas bon en serveur (bien qu'il gère 32Go de ram) mais pour un routeur, aucun souci.
Le processeur n'est pas le problème : il glande sur les graphs.
Le problème c'est le chipset qui relie tout ça ensemble. Rajoute une carte SATA et tu verras que les perfs réseaux vont s'effriter davantage, même si le CPU se la coule douce.
-
re,
petite capture de top pendant un dl du 5000Mo.dat coté client.
il n'y aurai rien à faire du coté de ethtool pour améliorer les perfs ?
jerem
-
tres curieux la ... t'es certain de ta capture ?! :o
fait le test avec 2 transferts en meme temps aussi.
le poste client est pas sous Windows 7 par hasard ?
-
jeremyp3, le load average sur 1 minute est à 0,04 (donc le système ne fait rien contrairement à la précédente copie d'écran)
Les chiffres de la 3ème ligne montrent aussi que le système ne fait rien à part se tourner les pouces 98,7% inutilisé).
-
l'outil est vraiment pas bien fait pour les non-voyants.
top est un calvaire pour les voyants également !
Par rapport au problème, jeremyp3, je te susurre de trier les entrées de htop en fonction de la colonne "S" (c'est la plus intéressante), et également de montrer les "thread" noyau
Tu vas te rendre compte que l'un ou l'autre consomme ton CPU (IO wait, ou irq)
"Intel(R) Celeron(R) CPU G1610T @ 2.30GHz"
Bof, les Kbox routent 130Mbps, avec ce genre de proc:
system type : Broadcom BCM5357 chip rev 2 pkg 10
processor : 0
cpu model : MIPS 74K V4.9
BogoMIPS : 239.20
cpu MHz : 480
wait instruction : no
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : yes
ASEs implemented : mips16 dsp
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available
Je nat également du Gb avec un seul core de Xeon 5650
-
Le G1610T @ 2.30GHz a un "Single Thread Rating" de 1189 sur PassMark.
Le Xeon 5650 a un "Single Thread Rating" de 1234.
http://www.cpubenchmark.net/compare.php?cmp%5B%5D=2075&cmp%5B%5D=1304
-
bonjour,
je viens de faire un test avec la box relié au serveur sur eth2 (aucune règles iptables active) après avoir activé le masquerading, j'ai exactement les mêm débit sur mon réseau locale
avez vous d'autres idées ?
sinon ben je me contenterai de ça, mais c'est dommage tout de même !!
jerem
-
bonjour,
bon je me répond à moi même, mais j'avance.
j'ai branché un vieux pc sous linux aussi, qui a une carte giga, et j'ai bien le max de la connections sur le réseau local...
donc, le soucis semble être sur la carte réseau de mon portable ...
un lspci et un ethtool -k eth0:
root@portable-Jessie:/home/jeremy# lspci |grep -i giga
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
root@portable-Jessie:/home/jeremy# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
quelque chose vous semble mauvais la dedant ?
jerem
-
Le PCI Express 1.0 et 2.0 permet 2 Gb/s par ligne donc le bus PCI Express ne devait pas limiter le débit (j'imagine que c'est une version plus rapide de PCI Express, donc qui offre plus de débit par ligne, mais je me met dans le pire cas).
Par contre, tu as un seul port Ethernet sur ton PC Portabe donc il ne pourra pas faire routeur à 1 Gb/s : il ne faut pas oublier les acquittements.
Tu pourais vérifier le duplex avec mii-tool :
sudo apt install ethtool
sudo mii-tool
Full-Duplex, c'est bon :
eth0: negotiated 1000baseT-FD flow-control, link ok
Half-Duplex, c'est ce qui pourrait expliquer les pb de débit :
eth0: negotiated 1000baseT-HD flow-control, link ok
-
salut vivien,
je pense qu'il y a confusions. je n'est pas changer le serveur mais j'ai mis un vieu pc client donc je ne cherche pas à faire routeur avec mon pc portable, j'ai seulement rajouté un équipement, que j'ai connecté a mon réseau local qui lui va au max de ma connexion, donc le serveur n'est pas l'élèment limitant.
le ethtool eth0 sur le pc portable malade:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
-
on t'avais proposé des tests et des questions pour savoir si le probleme ne venait pas du PC. ca a donné quoi ?
tres curieux la ... t'es certain de ta capture ?! :o
fait le test avec 2 transferts en meme temps aussi.
le poste client est pas sous Windows 7 par hasard ?
un wget unique pour mesurer le débit max n'est pertinent que si on est certain de 100% qu'il n'y a pas de probleme de réduction de débit a cause de la latence (bug d'OS, réglage des buffers max, etc).
Il faut toujours valider ce point avant de conclure de la pertinence d'une mesure faite avec un seul wget.
D'ou l’intérêt de faire un speedtest classique (web) si on peut ou plusieurs wget en meme temps (2 puis plus jusqu'au max) ou un iperf3 avec l'option -P.
donc si un wget ne donne pas le résultat attendu, faire 2 wget en meme temps permet de savoir de suite ce qui se passe.
-
tres curieux la ... t'es certain de ta capture ?! :o
oui, les deux captures ont étaient réalisé durant un wget en cours.
fait le test avec 2 transferts en meme temps aussi.
je dois additionner les débits des deux wget ? je vais plutot privilégier l'option -P de iperf dans ce cas.
le poste client est pas sous Windows 7 par hasard ?
non, comme dit dans mon premier message: sur debian pour le serveur et le client.
-
bonjour,
voila les 2 iperf3 le premier sur le pc malade, l'autre sur le pc sur qui ça fonctionne bien les deux connecté sur le même switch.
le pc malade:
# iperf3 -4 -c 1.testdebit.info -R -P 4
Connecting to host 1.testdebit.info, port 5201
Reverse mode, remote host 1.testdebit.info is sending
[ 4] local 192.168.80.10 port 37004 connected to 194.158.102.114 port 5201
[ 6] local 192.168.80.10 port 37006 connected to 194.158.102.114 port 5201
[ 8] local 192.168.80.10 port 37008 connected to 194.158.102.114 port 5201
[ 10] local 192.168.80.10 port 37010 connected to 194.158.102.114 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 25.7 MBytes 216 Mbits/sec
[ 6] 0.00-1.00 sec 22.5 MBytes 189 Mbits/sec
[ 8] 0.00-1.00 sec 13.6 MBytes 114 Mbits/sec
[ 10] 0.00-1.00 sec 13.3 MBytes 112 Mbits/sec
[SUM] 0.00-1.00 sec 75.1 MBytes 630 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 1.00-2.00 sec 22.9 MBytes 192 Mbits/sec
[ 6] 1.00-2.00 sec 19.7 MBytes 165 Mbits/sec
[ 8] 1.00-2.00 sec 12.3 MBytes 103 Mbits/sec
[ 10] 1.00-2.00 sec 11.7 MBytes 98.2 Mbits/sec
[SUM] 1.00-2.00 sec 66.7 MBytes 559 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 2.00-3.00 sec 24.3 MBytes 204 Mbits/sec
[ 6] 2.00-3.00 sec 21.2 MBytes 177 Mbits/sec
[ 8] 2.00-3.00 sec 13.5 MBytes 113 Mbits/sec
[ 10] 2.00-3.00 sec 13.2 MBytes 110 Mbits/sec
[SUM] 2.00-3.00 sec 72.2 MBytes 604 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 3.00-4.00 sec 24.8 MBytes 209 Mbits/sec
[ 6] 3.00-4.00 sec 21.9 MBytes 184 Mbits/sec
[ 8] 3.00-4.00 sec 15.1 MBytes 127 Mbits/sec
[ 10] 3.00-4.00 sec 14.7 MBytes 123 Mbits/sec
[SUM] 3.00-4.00 sec 76.4 MBytes 643 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 4.00-5.00 sec 27.1 MBytes 227 Mbits/sec
[ 6] 4.00-5.00 sec 24.2 MBytes 203 Mbits/sec
[ 8] 4.00-5.00 sec 16.6 MBytes 140 Mbits/sec
[ 10] 4.00-5.00 sec 16.3 MBytes 136 Mbits/sec
[SUM] 4.00-5.00 sec 84.2 MBytes 706 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 5.00-6.00 sec 27.9 MBytes 234 Mbits/sec
[ 6] 5.00-6.00 sec 25.3 MBytes 212 Mbits/sec
[ 8] 5.00-6.00 sec 18.4 MBytes 154 Mbits/sec
[ 10] 5.00-6.00 sec 18.0 MBytes 151 Mbits/sec
[SUM] 5.00-6.00 sec 89.6 MBytes 752 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 6.00-7.00 sec 26.9 MBytes 226 Mbits/sec
[ 6] 6.00-7.00 sec 24.4 MBytes 205 Mbits/sec
[ 8] 6.00-7.00 sec 17.7 MBytes 149 Mbits/sec
[ 10] 6.00-7.00 sec 17.0 MBytes 142 Mbits/sec
[SUM] 6.00-7.00 sec 86.0 MBytes 722 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 7.00-8.00 sec 24.0 MBytes 201 Mbits/sec
[ 6] 7.00-8.00 sec 21.9 MBytes 184 Mbits/sec
[ 8] 7.00-8.00 sec 16.3 MBytes 137 Mbits/sec
[ 10] 7.00-8.00 sec 16.1 MBytes 135 Mbits/sec
[SUM] 7.00-8.00 sec 78.3 MBytes 657 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 8.00-9.00 sec 23.5 MBytes 197 Mbits/sec
[ 6] 8.00-9.00 sec 24.2 MBytes 203 Mbits/sec
[ 8] 8.00-9.00 sec 18.3 MBytes 154 Mbits/sec
[ 10] 8.00-9.00 sec 17.8 MBytes 149 Mbits/sec
[SUM] 8.00-9.00 sec 83.8 MBytes 703 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 9.00-10.00 sec 20.8 MBytes 174 Mbits/sec
[ 6] 9.00-10.00 sec 25.5 MBytes 214 Mbits/sec
[ 8] 9.00-10.00 sec 19.3 MBytes 162 Mbits/sec
[ 10] 9.00-10.00 sec 18.5 MBytes 155 Mbits/sec
[SUM] 9.00-10.00 sec 84.1 MBytes 705 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 252 MBytes 211 Mbits/sec 171 sender
[ 4] 0.00-10.00 sec 248 MBytes 208 Mbits/sec receiver
[ 6] 0.00-10.00 sec 234 MBytes 196 Mbits/sec 254 sender
[ 6] 0.00-10.00 sec 231 MBytes 194 Mbits/sec receiver
[ 8] 0.00-10.00 sec 163 MBytes 137 Mbits/sec 170 sender
[ 8] 0.00-10.00 sec 162 MBytes 136 Mbits/sec receiver
[ 10] 0.00-10.00 sec 158 MBytes 133 Mbits/sec 259 sender
[ 10] 0.00-10.00 sec 157 MBytes 132 Mbits/sec receiver
[SUM] 0.00-10.00 sec 807 MBytes 677 Mbits/sec 854 sender
[SUM] 0.00-10.00 sec 798 MBytes 670 Mbits/sec receiver
iperf Done.
sur le pc qui va bien:
# iperf3 -4 -c 1.testdebit.info -R -P 4
Connecting to host 1.testdebit.info, port 5201
Reverse mode, remote host 1.testdebit.info is sending
[ 4] local 192.168.80.13 port 44712 connected to 194.158.102.114 port 5201
[ 6] local 192.168.80.13 port 44714 connected to 194.158.102.114 port 5201
[ 8] local 192.168.80.13 port 44716 connected to 194.158.102.114 port 5201
[ 10] local 192.168.80.13 port 44718 connected to 194.158.102.114 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 31.7 MBytes 266 Mbits/sec
[ 6] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec
[ 8] 0.00-1.00 sec 23.7 MBytes 199 Mbits/sec
[ 10] 0.00-1.00 sec 13.9 MBytes 117 Mbits/sec
[SUM] 0.00-1.00 sec 83.5 MBytes 700 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 1.00-2.00 sec 36.0 MBytes 302 Mbits/sec
[ 6] 1.00-2.00 sec 17.0 MBytes 143 Mbits/sec
[ 8] 1.00-2.00 sec 29.8 MBytes 250 Mbits/sec
[ 10] 1.00-2.00 sec 17.5 MBytes 147 Mbits/sec
[SUM] 1.00-2.00 sec 100 MBytes 842 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 2.00-3.00 sec 38.6 MBytes 324 Mbits/sec
[ 6] 2.00-3.00 sec 18.2 MBytes 153 Mbits/sec
[ 8] 2.00-3.00 sec 32.3 MBytes 271 Mbits/sec
[ 10] 2.00-3.00 sec 19.0 MBytes 159 Mbits/sec
[SUM] 2.00-3.00 sec 108 MBytes 908 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 3.00-4.00 sec 38.6 MBytes 324 Mbits/sec
[ 6] 3.00-4.00 sec 19.8 MBytes 166 Mbits/sec
[ 8] 3.00-4.00 sec 33.1 MBytes 277 Mbits/sec
[ 10] 3.00-4.00 sec 19.8 MBytes 166 Mbits/sec
[SUM] 3.00-4.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 4.00-5.00 sec 37.9 MBytes 318 Mbits/sec
[ 6] 4.00-5.00 sec 20.4 MBytes 172 Mbits/sec
[ 8] 4.00-5.00 sec 34.3 MBytes 288 Mbits/sec
[ 10] 4.00-5.00 sec 19.0 MBytes 159 Mbits/sec
[SUM] 4.00-5.00 sec 112 MBytes 936 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 5.00-6.00 sec 40.5 MBytes 340 Mbits/sec
[ 6] 5.00-6.00 sec 22.7 MBytes 190 Mbits/sec
[ 8] 5.00-6.00 sec 31.3 MBytes 262 Mbits/sec
[ 10] 5.00-6.00 sec 14.5 MBytes 121 Mbits/sec
[SUM] 5.00-6.00 sec 109 MBytes 914 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 6.00-7.00 sec 42.9 MBytes 360 Mbits/sec
[ 6] 6.00-7.00 sec 24.4 MBytes 204 Mbits/sec
[ 8] 6.00-7.00 sec 26.8 MBytes 225 Mbits/sec
[ 10] 6.00-7.00 sec 13.4 MBytes 112 Mbits/sec
[SUM] 6.00-7.00 sec 108 MBytes 902 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 7.00-8.00 sec 43.5 MBytes 365 Mbits/sec
[ 6] 7.00-8.00 sec 25.8 MBytes 216 Mbits/sec
[ 8] 7.00-8.00 sec 27.8 MBytes 233 Mbits/sec
[ 10] 7.00-8.00 sec 14.3 MBytes 120 Mbits/sec
[SUM] 7.00-8.00 sec 111 MBytes 935 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 8.00-9.00 sec 45.1 MBytes 378 Mbits/sec
[ 6] 8.00-9.00 sec 27.4 MBytes 230 Mbits/sec
[ 8] 8.00-9.00 sec 22.0 MBytes 185 Mbits/sec
[ 10] 8.00-9.00 sec 16.1 MBytes 135 Mbits/sec
[SUM] 8.00-9.00 sec 111 MBytes 927 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 9.00-10.00 sec 46.4 MBytes 389 Mbits/sec
[ 6] 9.00-10.00 sec 28.7 MBytes 241 Mbits/sec
[ 8] 9.00-10.00 sec 22.4 MBytes 188 Mbits/sec
[ 10] 9.00-10.00 sec 14.2 MBytes 120 Mbits/sec
[SUM] 9.00-10.00 sec 112 MBytes 938 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 404 MBytes 339 Mbits/sec 222 sender
[ 4] 0.00-10.00 sec 401 MBytes 337 Mbits/sec receiver
[ 6] 0.00-10.00 sec 222 MBytes 186 Mbits/sec 340 sender
[ 6] 0.00-10.00 sec 219 MBytes 184 Mbits/sec receiver
[ 8] 0.00-10.00 sec 287 MBytes 241 Mbits/sec 235 sender
[ 8] 0.00-10.00 sec 284 MBytes 238 Mbits/sec receiver
[ 10] 0.00-10.00 sec 164 MBytes 138 Mbits/sec 174 sender
[ 10] 0.00-10.00 sec 162 MBytes 136 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.05 GBytes 904 Mbits/sec 971 sender
[SUM] 0.00-10.00 sec 1.04 GBytes 895 Mbits/sec receiver
iperf Done.
j'espère que c'est ce que vous attendiez
jerem
-
entre les 2 PC, un en client ipref3 et l'autre en serveur iperf3, t'as bien le max? dans les 2 sens ? (ca devrait vu que ton 1er post faisait état du max avec le lightpd du serveur).
dans ce cas ca peut etre un probleme de config d'OS.
fait un :
sysctl net.ipv4 | grep mem
sysctl net.core | grep mem
et compare les valeurs entre les 2 machines.
-
bonjour,
en effet, ya deux valeurs qui diffère:
sur le pc malade:
net.ipv4.tcp_mem = 93360 124482 186720
net.ipv4.udp_mem = 186723 248965 373446
sur le pc qui va bien:
net.ipv4.tcp_mem = 46068 61424 92136
net.ipv4.udp_mem = 92136 122848 184272
après avoir tester l'iperf en serveur sur le pc qui va bien et en client sur celui qui va mal, je tourne a 600 mbps, alors que le wget vers le lighttpd reste toujours au max.
jerem
-
je suis perplexe la :D
t'as combien pour:
net.ipv4.tcp_rmem
et
net.ipv4.tcp_wmem
ps: et la latence vers 1.testdebit.info (mtr 1.testdebit.info par exemple ou juste un ping)
-
Ce sont les bonnes valeurs de rmem et wmem.
-
bonjour,
si ya un moyen de réinitialiser toute lapile TCP/IP, je veux bien essayer
j'avoue que je comprends pas pourquoi ces différences entre mes deux machines, alors que j'ai jamais touché ça à ma connaissance
jerem
-
bonjour,
je reviens par ici pour donner les résultat de mes iperf3 entre mes deux machines
192.168.80.10 la machine malade
192.168.80.13 la vieille machine qui vabien.
jeremy@portable-Jessie:~$ iperf3 -4 -c 192.168.80.13 -R -P 2
Connecting to host 192.168.80.13, port 5201
Reverse mode, remote host 192.168.80.13 is sending
[ 4] local 192.168.80.10 port 42336 connected to 192.168.80.13 port 5201
[ 6] local 192.168.80.10 port 42338 connected to 192.168.80.13 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 47.6 MBytes 399 Mbits/sec
[ 6] 0.00-1.00 sec 25.0 MBytes 210 Mbits/sec
[SUM] 0.00-1.00 sec 72.6 MBytes 609 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 1.00-2.00 sec 48.1 MBytes 404 Mbits/sec
[ 6] 1.00-2.00 sec 24.0 MBytes 202 Mbits/sec
[SUM] 1.00-2.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 2.00-3.00 sec 48.1 MBytes 404 Mbits/sec
[ 6] 2.00-3.00 sec 24.0 MBytes 202 Mbits/sec
[SUM] 2.00-3.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 3.00-4.00 sec 48.0 MBytes 402 Mbits/sec
[ 6] 3.00-4.00 sec 24.0 MBytes 201 Mbits/sec
[SUM] 3.00-4.00 sec 72.0 MBytes 604 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 4.00-5.00 sec 48.1 MBytes 404 Mbits/sec
[ 6] 4.00-5.00 sec 24.1 MBytes 202 Mbits/sec
[SUM] 4.00-5.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 5.00-6.00 sec 48.2 MBytes 405 Mbits/sec
[ 6] 5.00-6.00 sec 24.1 MBytes 202 Mbits/sec
[SUM] 5.00-6.00 sec 72.3 MBytes 607 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 6.00-7.00 sec 48.1 MBytes 404 Mbits/sec
[ 6] 6.00-7.00 sec 24.1 MBytes 202 Mbits/sec
[SUM] 6.00-7.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 7.00-8.00 sec 48.1 MBytes 403 Mbits/sec
[ 6] 7.00-8.00 sec 24.0 MBytes 201 Mbits/sec
[SUM] 7.00-8.00 sec 72.1 MBytes 604 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 8.00-9.00 sec 48.2 MBytes 404 Mbits/sec
[ 6] 8.00-9.00 sec 24.0 MBytes 202 Mbits/sec
[SUM] 8.00-9.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 9.00-10.00 sec 48.1 MBytes 404 Mbits/sec
[ 6] 9.00-10.00 sec 24.1 MBytes 202 Mbits/sec
[SUM] 9.00-10.00 sec 72.2 MBytes 606 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 482 MBytes 405 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 481 MBytes 403 Mbits/sec receiver
[ 6] 0.00-10.00 sec 242 MBytes 203 Mbits/sec 0 sender
[ 6] 0.00-10.00 sec 242 MBytes 203 Mbits/sec receiver
[SUM] 0.00-10.00 sec 724 MBytes 608 Mbits/sec 0 sender
[SUM] 0.00-10.00 sec 722 MBytes 606 Mbits/sec receiver
iperf Done.
sans le -R
jeremy@portable-Jessie:~$ iperf3 -4 -c 192.168.80.13 -P 2
Connecting to host 192.168.80.13, port 5201
[ 4] local 192.168.80.10 port 42348 connected to 192.168.80.13 port 5201
[ 6] local 192.168.80.10 port 42350 connected to 192.168.80.13 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 54.4 MBytes 456 Mbits/sec 0 69.3 KBytes
[ 6] 0.00-1.00 sec 58.0 MBytes 487 Mbits/sec 0 82.0 KBytes
[SUM] 0.00-1.00 sec 112 MBytes 943 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 1.00-2.00 sec 53.9 MBytes 452 Mbits/sec 0 90.5 KBytes
[ 6] 1.00-2.00 sec 58.1 MBytes 488 Mbits/sec 0 87.7 KBytes
[SUM] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 2.00-3.00 sec 57.8 MBytes 485 Mbits/sec 0 102 KBytes
[ 6] 2.00-3.00 sec 53.9 MBytes 453 Mbits/sec 0 91.9 KBytes
[SUM] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 3.00-4.00 sec 58.8 MBytes 493 Mbits/sec 0 102 KBytes
[ 6] 3.00-4.00 sec 53.4 MBytes 448 Mbits/sec 0 91.9 KBytes
[SUM] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 4.00-5.00 sec 59.3 MBytes 498 Mbits/sec 0 115 KBytes
[ 6] 4.00-5.00 sec 52.9 MBytes 443 Mbits/sec 0 99.0 KBytes
[SUM] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 5.00-6.00 sec 58.9 MBytes 494 Mbits/sec 0 144 KBytes
[ 6] 5.00-6.00 sec 53.5 MBytes 448 Mbits/sec 0 127 KBytes
[SUM] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 6.00-7.00 sec 59.1 MBytes 496 Mbits/sec 0 144 KBytes
[ 6] 6.00-7.00 sec 52.8 MBytes 443 Mbits/sec 0 127 KBytes
[SUM] 6.00-7.00 sec 112 MBytes 939 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 7.00-8.00 sec 59.3 MBytes 498 Mbits/sec 0 144 KBytes
[ 6] 7.00-8.00 sec 52.6 MBytes 441 Mbits/sec 0 127 KBytes
[SUM] 7.00-8.00 sec 112 MBytes 939 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 8.00-9.00 sec 59.3 MBytes 498 Mbits/sec 0 144 KBytes
[ 6] 8.00-9.00 sec 52.7 MBytes 442 Mbits/sec 0 127 KBytes
[SUM] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 4] 9.00-10.00 sec 59.5 MBytes 499 Mbits/sec 0 144 KBytes
[ 6] 9.00-10.00 sec 52.7 MBytes 442 Mbits/sec 0 127 KBytes
[SUM] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 580 MBytes 487 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 580 MBytes 487 Mbits/sec receiver
[ 6] 0.00-10.00 sec 541 MBytes 453 Mbits/sec 0 sender
[ 6] 0.00-10.00 sec 540 MBytes 453 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
[SUM] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec receiver
iperf Done.
donc le problème serait juste dans un sens, j'en perd mon latin ...
comment sont généré les valeurs donné par sysctl quand elle ne sont pas explicitement dans le fichier.conf ?
merci pour votre aide et votre patience...
jerem
-
Ce serait lié à la carte réseau ?
jeremyp3 nous a indiqué que c'était un Realtek RTL8111/8168/8411
# lspci |grep -i giga
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
-
re,
je rajoute une autre information qui peut être utile ou pas,
un iperf entre le pc malade et le serveur @home est de 940 mbps dans les deux sens.
désolé pour ce sujet et toute ses infos, mais j'aimerai bien y comprendre quelque chose ...
jerem
P.S: si un expert réseau veux faire plus de test au téléphone / skype / ..., c'est une solution envisageable
-
Pourtant les tests précédents (entre 192.168.80.10 et 192.168.80.13) montrent le contraire, non ?
- iperf 3 download depuis PC local => 606 Mb/s
- iperf 3 download depuis 1.testdebit.info => 606 Mb/s
- iperf 3 upload vers PC local => 940 Mb/s
Il y a un test où le débit download est ok ?
-
bonjour,
oui, sur 192.168.80.13, lui, le download vers testdebit.info est au maximum... du moins la moyenne est plus rapide que sur 192.168.80.10, le pc qui me pose problème ...
jerem
-
on n'a toujours pas:
ps: et la latence vers 1.testdebit.info (mtr 1.testdebit.info par exemple ou juste un ping)
les 2 PC ont-ils bien exactement le meme OS (uname -a & lsb_release -a) ?
Causes possible de baisse de debit :
- un mauvais ajustement de TCP a la latence sur le PC malade (les buffers sont ok mais y'a d'autre paramètres)
- saturation CPU du PC a cause d'un filtre en entrée (iptable ou autre firewall) qui s'active sauf si le traffic est local
- mauvais ajustement de TCP sur le PC a cause des pertes de paquets (rare).
Le test suivant c'est avec UDP mais pas evident à faire depuis Internet
iperf3 -u -b 1G -c ping.online.net
A faire en local aussi: le serveur en mode serveur (iperf3 -s) et le test UDP depuis les 2 PC.
Si ca donne rien, on peut tester avec de la latence localement:
Sur le serveur:
sudo tc qdisc add dev ethX root netem delay 100ms(ethX = carte lan du serveur, au lieu de 100ms mettre la latence vers 1.testdebit.info).
puis comparer les 2 PC avec un iperf3 -R ou un wget
pour remettre le serveur en normal:
sudo tc qdisc del dev ethX root netem delay 100ms
('sudo tc qdisc ' tout court permet de voir si on a quelque chose d'actif).
Si ce n'est pas la latence c'est peut être des pertes de paquets quelque parts. c'est plus rare mais ca arrive.
Pour tester avec des pertes:
sudo tc qdisc change dev ethX root netem loss 0.1%
et refaire les iperfs.
Tester aussi en coupant iptables sur le PC malade.
-
bonjour,
je pensais que le traceroute suffisait
donc un ping donne:
--- 1.testdebit.info ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 6999ms
rtt min/avg/max/mdev = 20.477/20.528/20.595/0.129 ms
les deux machines ont strictement le même OS, provient du même tar.gz.
une debian 8.3 avec le noyau 4.3 des backports.
le iperf en udp:
root@portable-Jessie:/home/jeremy#
root@portable-Jessie:/home/jeremy# iperf3 -u -b 1G -c ping.online.net
Connecting to host ping.online.net, port 5201
[ 4] local 192.168.80.10 port 54130 connected to 62.210.18.40 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 102 MBytes 856 Mbits/sec 13058
[ 4] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 14376
[ 4] 2.00-3.00 sec 114 MBytes 955 Mbits/sec 14573
[ 4] 3.00-4.00 sec 114 MBytes 955 Mbits/sec 14567
[ 4] 4.00-5.00 sec 113 MBytes 951 Mbits/sec 14507
[ 4] 5.00-6.00 sec 114 MBytes 956 Mbits/sec 14585
[ 4] 6.00-7.00 sec 113 MBytes 951 Mbits/sec 14507
[ 4] 7.00-8.00 sec 114 MBytes 956 Mbits/sec 14593
[ 4] 8.00-9.00 sec 113 MBytes 946 Mbits/sec 14428
[ 4] 9.00-10.00 sec 113 MBytes 951 Mbits/sec 14512
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0.344 ms 139243/139634 (1e+02%)
[ 4] Sent 139634 datagrams
iperf Done.
en udp de serveur a pc malade j'ai bien 940 mbps dans les deux sens.
après avoir mis de la latence, le wget est tout de suite moins sexy:
donc j'ai mis 20 ms comme le ping si-dessus,
et le wget donne ça sur les deux pc vers le serveur:
--2016-02-27 04:47:05-- http://192.168.80.1/5000Mo.dat
Connexion à 192.168.80.1:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 5000000000 (4,7G) [application/octet-stream]
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================>] 4,66G 46,7MB/s ds 1m 43s
2016-02-27 04:48:49 (46,2 MB/s) — « /dev/null » sauvegardé [5000000000/5000000000]
quand la latence est local, les deux pc sont touché.
si malgré ses informations les autres test sont encore utile, merci de me le dire.
jerem
-
Le test UDP n'est pas dans le bon je me suis trompé. il faut ajouter -R.
iperf3 -R -u -b 1G -c ping.online.net
Il faut que ping.online.net envoie un flux UDP a 1Gbps (et pas envoyé un flux vers online).
Le résultat peut être faussé par les anti-DDoS d'Online ou d'ailleurs dans le chemin.
quand la latence est local, les deux pc sont touché.
ca peut être le serveur qui a du mal a èmettre avec de la latence. Le point concluant c'est que les 2 PC donnent pareil.
on s'oriente sur un souci iptables/firewall en TCP. faut tester en coupant iptables. et bien vérifier le cpu du PC malade avec 'top' (j’espère que c'est le cas avec chaque test sinon on perd notre temps pour rien la...).
-
on s'oriente sur un souci iptables/firewall en TCP. faut tester en coupant iptables.
si seulement c'était si simple ...
pas d'iptables ni de pare feu de configuré sur le pc "malade" seulement des masquerading pour virtualbox. ça peut jouer, tu penses ?
jerem
-
j'avais pas fini ma phrase :p
-
Le test UDP n'est pas dans le bon je me suis trompé. il faut ajouter -R.
voilà le résultat:
root@portable-Jessie:/home/jeremy# iperf3 -R -u -b 1G -c ping.online.net
Connecting to host ping.online.net, port 5201
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.80.10 port 41607 connected to 62.210.18.40 port 5201
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 7.23 MBytes 60.7 Mbits/sec 0.208 ms 14368/15294 (94%)
[ 4] 1.00-2.00 sec 6.89 MBytes 57.8 Mbits/sec 0.237 ms 14634/15516 (94%)
[ 4] 2.00-3.00 sec 6.85 MBytes 57.5 Mbits/sec 0.286 ms 14202/15079 (94%)
[ 4] 3.00-4.00 sec 6.80 MBytes 57.0 Mbits/sec 0.140 ms 14637/15507 (94%)
[ 4] 4.00-5.00 sec 6.61 MBytes 55.4 Mbits/sec 0.139 ms 14030/14876 (94%)
[ 4] 5.00-6.00 sec 7.33 MBytes 61.5 Mbits/sec 0.175 ms 14503/15441 (94%)
[ 4] 6.00-7.00 sec 7.03 MBytes 59.0 Mbits/sec 0.182 ms 13729/14629 (94%)
[ 4] 7.00-8.00 sec 6.84 MBytes 57.3 Mbits/sec 0.213 ms 15213/16088 (95%)
[ 4] 8.00-9.00 sec 6.71 MBytes 56.3 Mbits/sec 0.173 ms 14215/15074 (94%)
[ 4] 9.00-10.00 sec 6.59 MBytes 55.3 Mbits/sec 0.169 ms 14632/15476 (95%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.17 GBytes 1.00 Gbits/sec 0.169 ms 144163/152980 (94%)
[ 4] Sent 152980 datagrams
iperf Done.
bien vérifier le cpu du PC malade avec 'top' (j’espère que c'est le cas avec chaque test sinon on perd notre temps pour rien la...).
non, je vérifie pas le CPU avec chaque test, comme j'ai dit plus haut, top n'est pas du tout pratique a utiliser pour moi. mais vu que ça marche en local, le soucis n'est pas la, si ?
mais voici un top (par défault) en pj durant un wget sur le pc malade
-
comme je m'y attendait le test UDP se sert a rien y'a un bridage a 50Mbs quelque part entre Online et Orange.
franchement la je ne vois pas.
dump tout les paramétrages tcp:
sysctl net.ipv4 | grep tcpet compare les avec l'autre PC.
-
bonjour,
voici les valeur qui diffèrent
première ligne vieux pc seconde lignes pc malade
net.ipv4.tcp_max_orphans = 16384
net.ipv4.tcp_max_orphans = 32768
net.ipv4.tcp_max_syn_backlog = 128
net.ipv4.tcp_max_syn_backlog = 256
net.ipv4.tcp_max_tw_buckets = 16384
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_mem = 46068 61424 92136
net.ipv4.tcp_mem = 93360 124482 186720
si c'est pas important, je vais arrêter de chercher et je testerai avec un live
jerem
-
iperf3 en UDP introduit une sorte de protocole TCP au-dessus. Les perf s'écroulent avec la latence qui augmente.
Je conseille iperf2 pour un test performant en UDP. Iperf2 va envoyer des paquets sans se soucier si cela provoque un DDOS.
Personnellement, j'utilise iperf3 en TCP et iperf2 en UDP.
-
Quel est le CPU du PC malade ?
Il y a 78% d'idle (en moyenne sur l’ensemble des cœurs), donc le PC n'est pas surchargé, cependant :
- wget consomme 36%
- 6 processus sd_ibmtts (5 autour de 9% chacun, 1 à 2.6%) : est-ce que qu'il essaye de lire la sortie de top/wget ?
wget affiche la vitesse et sa barre de progression sur stderr (l'écriture est donc synchrone).
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?
-
Quel est le CPU du PC malade ?
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1367.511
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1375.597
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1341.636
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1318.277
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
- 6 processus sd_ibmtts (5 autour de 9% chacun, 1 à 2.6%) : est-ce que qu'il essaye de lire la sortie de top/wget ?
non, le processus qui lit c'est "orca". ibmtts, c'est uniquement la synthèse vocale.
wget affiche la vitesse et sa barre de progression sur stderr (l'écriture est donc synchrone).
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?
c'est à tester.
jerem
-
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?
pourquoi ca ralentirait un téléchargement venant du Net et pas un téléchargement local ?
Tout le probleme depuis le début de ce sujet c'est qu'en local ca transfert a fond.
donc soit y'a un "traitement différent" quelque part dans le PC si l'IP distante n'est pas locale: on peut tester ca en utilisant l'IP public du routeur/serveur (si le hairpin/loopback et le firewall du routeur/serveur sont bien configurer)
soit y'a un a paramétrage particulier de TCP pour ce PC: on n'a rien vu de particulier pour le moment.
soit le fait que le flux traverse le routeur/serveur introduit un ralentissement quand la destination finale est le PC malade (et que lui): une règle iptables particuliere sur le routeur/serveur ou un truc du genre ?
soit X ?
-
pourquoi ca ralentirait un téléchargement venant du Net et pas un téléchargement local ?
Il y a peut-être une combinaisons de plusieurs facteurs (latence, différence de configuration entre le serveur local et le serveur distant, ...).
Le wget local avec 20ms de latence ajoutée était ralenti, mais sur les deux PC, donc c'est peut-être encore différent.