Auteur Sujet: Impossible de faire un Speedtest à 1 Gb/s (Lu 77132 fois)

kgersen · « **Réponse #204 le:** 02 juillet 2014 à 21:13:28 »

Citation de: Ralph le 02 juillet 2014 à 08:09:23

Code: [Sélectionner]
$ uname -a Linux lilith 3.15.2-1-ARCH #1 SMP PREEMPT Fri Jun 27 07:43:32 CEST 2014 i686 GNU/LinuxAvec des iperf à plus de 870Mbits/s en client.

C'est quel distrib ca ?

que donne:

Code: [Sélectionner]

cat /proc/sys/net/core/rmem_default 
cat /proc/sys/net/core/rmem_max

et

Code: [Sélectionner]

sysctl net.ipv4 (ca peut faire beaucoup de lignes).

Quelle latence (ping ou mtr) avec le serveur du test wget?

Ralph · « **Réponse #205 le:** 02 juillet 2014 à 21:51:40 »

Une ArchLinux

Pour les sysctl, ils devraient en théorie être bons.

Code: [Sélectionner]

net.core.rmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_default = 16777216
net.core.wmem_max = 16777216

Et pour le net.ipv4.tcp

Code: [Sélectionner]

$ sd sysctl -a | grep 'net.ipv4.tcp'
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_autocorking = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_challenge_ack_limit = 100
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_early_retrans = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_fack = 1
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_frto = 2
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_limit_output_bytes = 131072
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_max_orphans = 2048
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_mem = 11859        15812   23718
net.ipv4.tcp_min_tso_segs = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_notsent_lowat = -1
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_rmem = 4096        87380   16777216
net.ipv4.tcp_sack = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_syn_retries = 6
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_thin_dupack = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096        16384   16777216
net.ipv4.tcp_workaround_signed_windows = 0

Ping :

Code: [Sélectionner]

--- ipv4.intuxication.testdebit.info ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8014ms
rtt min/avg/max/mdev = 6.170/6.479/6.829/0.261 ms

kgersen · « **Réponse #206 le:** 02 juillet 2014 à 22:27:17 »

oui les sysctl ont l'air ok. C'est une VM ou direct sur le métal?

Sinon c'est qu'il y'a un équipement intermédiaire sur le réseau qui limite le débit par connexion tcp (ou qui bousille les rwin mais c'est rare ca).

ou ca plafonne sur 1 core et il faut plusieurs cores donc plusieurs connexion tcp. le CPU est assez puissant?

c'est curieux en tout cas.

Ralph · « **Réponse #207 le:** 02 juillet 2014 à 22:45:40 »

Il n'y a qu'un switch giga entre la machine et la box.

Oui, c'est assez louche surtout que un wget + wmstat 1 120 en même temps donnent :

Code: [Sélectionner]

$ wget -O /dev/null http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
--2014-07-02 22:39:17--  http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
Resolving ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)... 62.210.156.12
Connecting to ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)|62.210.156.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5000000000 (4,7G) [application/x-ns-proxy-autoconfig]
Saving to: ‘/dev/null’

43% [=================================================>                                                                   ] 2 162 316 061 25,6MB/s  eta 83s

Code: [Sélectionner]

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 356856  15344  94848    0    0     0     0  365  560  1  1 99  0  0
 0  0      0 356796  15344  94848    0    0     0     0  365  565  0  1 99  0  0
 0  0      0 356764  15344  94848    0    0     0     0  371  528  0  2 98  0  0
 0  0      0 356796  15344  94848    0    0     0     0  404  581  1  2 97  0  0
 0  0      0 356732  15344  94848    0    0     0     0  381  560  1  2 97  0  0
 0  0      0 356760  15344  94848    0    0     0     0  405  596  1  2 98  0  0
 1  0      0 356700  15344  94848    0    0     0     0  527  658  1  3 96  0  0
 0  0      0 356668  15344  94848    0    0     0     0  927  770  1  8 91  0  0
 0  0      0 356732  15344  94848    0    0     0     0  931  801  3  8 89  0  0
 0  0      0 356764  15344  94848    0    0     0     0 2073 1146  1 11 87  0  0
 0  0      0 356796  15344  94848    0    0     0     0 2072 1326  2 11 87  0  0
 0  0      0 356632  15344  94848    0    0     0     0 2239 1298  2 14 83  0  0
 0  0      0 356760  15344  94848    0    0     0     0 2334 1385  2 10 89  0  0
 0  0      0 356760  15344  94848    0    0     0     0  812  763  1  7 93  0  0
 0  0      0 356900  15344  94848    0    0     0     0  816  622  1  7 92  0  0
 0  0      0 356796  15344  94848    0    0     0     0  681  636  1  4 96  0  0

Tu comprends pourquoi je me pose des questions sur la pertinence de faire ça avec un seul wget.. D'un autre coté quand je vois les vôtres, je me dis qu'un truc merde quelque part chez moi !

kgersen · « **Réponse #208 le:** 02 juillet 2014 à 22:52:49 »

Je viens de tester un Arch (3.14) et un Ubuntu (13.04) en VM dans VirtualBox. Les 2 en 64 bits sur un hôte Windows.

Un wget sur testdebit.info :

~~Arch ca plafonne a : 37,4 MB/s~~ erreur de config de ma part(carte réseau en VM NAT au lieu de bridge).
Ca va aussi vite qu'Ubuntu.
Ubuntu ca va au max de l’hôte en dessous: 107 MB/s

~~Un souci avec Arch ? (ou une config par défaut a changer).~~

Ralph · « **Réponse #209 le:** 02 juillet 2014 à 23:37:53 »

Hummm, j'ai pas non plus les 105Mbits/s sur mes VM VirtualBox (toutes en bridge aussi) qui ont pour host un Win 8.1 qui monte à 920Mbit/s sur le speedtest DC... Etrange, bon par contre, on a un peu dévié du post original la !

tivoli · « **Réponse #210 le:** 03 juillet 2014 à 11:06:52 »

VM windows 7 sous Virtualbox :

L'hote sous windows 8.1 Update 1

Ralph · « **Réponse #211 le:** 03 juillet 2014 à 16:49:26 »

Mon Host VirtualBox est un Windows qui n'a pas de problème de perf (~ 920 / 195) c'est mes Linux que ça soit en physique ou VM (Arch et/ou Unbuntu toute fraiche d'hier installée sur une machine avec un i5-760 pour l'occasion) qui "rame" sur un wget seul (ça monte à 60/62Mo/s et après ça s’éclate à 20Mo pour faire un peu nawak après).

Enfin bon, on a plus de nouvelles de l'OP

sfrmann99 · « **Réponse #212 le:** 04 juillet 2014 à 00:52:03 »

Download Speed: 331862 kbps (41482.8 KB/sec transfer rate)
Upload Speed: 141130 kbps (17641.3 KB/sec transfer rate)
Latency: 7 ms
Jitter: 1 ms
4/7/2014 00:49:33

ça fait plusieur jour qua chaque fois jouvre le pc j'ai ces debits
jutilise moin smon pc ces jours ci donc je ne teste pas apres une forte utilisation du pc
on dirait que ça se stabilise à ces debits
je nai plus trouver des debits de 50mega
à suivre

titshings · « **Réponse #213 le:** 04 juillet 2014 à 00:53:11 »

Et sinon, t'as fait ce qu'on t'a dit ?

sfrmann99 · « **Réponse #214 le:** 04 juillet 2014 à 01:32:06 »

je ne peux plus appeler vu que je ne retrouve pas le debit pourri de 50mega $:-\$

ozrctg · « **Réponse #215 le:** 04 juillet 2014 à 03:15:43 »

Est ce que l'activation des JumboFrames ne soulagerait pas un peu le CPU ?