ホームサーバー(Ubuntu 12.04サーバーを実行)からLAN(Windows 7をすべて実行)上の他のPCへのファイル転送は非常に遅いですが、逆方向(サーバーへのアップロード)のファイル転送は高速です。
SambaとSFTPの両方の転送でこれを観察したため、iperfで検証することにし、同じ結果を得ました。サーバー上の出力は次のようになりました。
iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 1309
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 416 MBytes 349 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 46.1 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 59704 connected with 192.168.1.82 port 5001
[ 4] 0.0-12.2 sec 1.50 MBytes 1.03 Mbits/sec
クライアント(My Win 7 PC)は、同じ実行でこの出力を生成しました。
iperf.exe -c 192.168.1.95 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.95, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.82 port 1309 connected with 192.168.1.95 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 416 MBytes 349 Mbits/sec
[ 4] local 192.168.1.82 port 5001 connected with 192.168.1.95 port 59704
[ 4] 0.0-12.2 sec 1.50 MBytes 1.03 Mbits/sec
他のクライアントからも同様の結果が観察されます。コンピューターはすべて同じギガビット有線スイッチに接続されています。それらの間でポートとケーブルを交換しても同じ結果が得られます。
サーバーに設定されたramdiskとの間で転送を実行しても、転送速度は変わりません。ハードディスクが問題を引き起こしているとは思わない。
同様の問題についてGoogleで最善を尽くしましたが、関連するソリューションはまだ見つかりません。誰にもアイデアはありますか?
以下は、関連するデバッグコマンドのダンプです。これらは、私よりも知識のある人々に役立つものです。
サーバー上のイーサネットカードのethtool出力:
ethtool eth0
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
Mii-toolの出力:
Sudo mii-tool
eth0: negotiated 1000baseT-HD flow-control, link ok
Lspciによって返されるハードウェアのリスト:
Sudo lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
00:08.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 Graphics [S3 UniChrome Pro] (rev 01)
Lsmodによって返されるロード済みドライバーのリスト:
Sudo lsmod
Module Size Used by
usb_storage 39646 0
vesafb 13516 1
ppdev 12849 0
arc4 12473 2
snd_via82xx 24718 0
gameport 15060 1 snd_via82xx
snd_ac97_codec 110213 1 snd_via82xx
b43 342801 0
ac97_bus 12642 1 snd_ac97_codec
snd_pcm 80916 2 snd_via82xx,snd_ac97_codec
snd_timer 28931 1 snd_pcm
snd_page_alloc 14108 2 snd_via82xx,snd_pcm
snd_mpu401_uart 13865 1 snd_via82xx
snd_rawmidi 25424 1 snd_mpu401_uart
snd_seq_device 14172 1 snd_rawmidi
snd 62218 7 snd_via82xx,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
mac80211 436493 1 b43
soundcore 14635 1 snd
serio_raw 13027 0
i2c_viapro 12969 0
cfg80211 178877 2 b43,mac80211
bcma 25651 1 b43
parport_pc 32114 1
shpchp 32265 0
mac_hid 13077 0
via_cputemp 13031 0
hwmon_vid 12723 1 via_cputemp
lp 17455 0
parport 40930 3 ppdev,parport_pc,lp
pata_via 13428 0
ssb 50691 1 b43
r8169 56396 0
sata_via 13495 2
ギガビットカードのドライバー情報:
Sudo modinfo r8169
filename: /lib/modules/3.2.0-51-generic-pae/kernel/drivers/net/ethernet/realtek/r8169.ko
version: 6.017.00-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <[email protected]>
srcversion: 231149B837AF2B63F7C0271
alias: pci:v00001186d00004300sv00001186sd00004C00bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
depends:
vermagic: 3.2.0-51-generic-pae SMP mod_unload modversions 686
parm: speed:force phy operation. Deprecated by ethtool (8). (array of int)
parm: duplex:force phy operation. Deprecated by ethtool (8). (array of int)
parm: autoneg:force phy operation. Deprecated by ethtool (8). (array of int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
...そしてuname -aを良い尺度で:
uname -a
Linux hotblack 3.2.0-51-generic-pae #77-Ubuntu SMP Wed Jul 24 20:40:32 UTC 2013 i686 i686 i386 GNU/Linux
他のデバッグ出力があると便利だと思われる方は、お気軽にお問い合わせください。
別のドライバーをテストするためのより良い方法が必要なため、ブート時に古いカーネルにドロップバックして、r8169をv2.3LK-NAPIに戻しましたが、問題は同じままでした。
しかし、私は興味深い発見をしました。 ethtoolを使用してカードを強制的に100Mbに戻すと...
Sudo ethtool -s eth0 speed 100 autoneg on duplex full
Sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
...その後、iperfは接続が両方向で正常に機能していることを示します。
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 2437
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 105 MBytes 87.7 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 83.9 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.95 port 40844 connected with 192.168.1.82 port 5001
[ 4] 0.0-10.0 sec 113 MBytes 94.4 Mbits/sec
私はこれから何を結論づけるべきか正確にはわかりませんが、アップロード速度がハードウェアによって制限されていないことの少なくともさらなる証拠です...
デュプレックスミスマッチが原因でこれを以前に見ました。ギガビットイーサネットの仕様では、両側で自動ネゴシエーションを使用する必要があるため、サーバーとクライアントのNICが自動ネゴシエーションに設定され、スイッチポートでも同じであることを確認してください。明示的に1000/Fullに設定しても、実行されません。
私はあなたの出力の1つから見る:
ネゴシエートされた1000baseT-HDフロー制御、リンクOK
それは半二重のように見えます。両側がautoに設定されていない場合に発生するのは、2つの接続間の自動ネゴシエーションフェーズが1000mbpsの速度を正しく検出しますが、デュプレックスモードを検出できないため、デフォルトの半二重を使用することです。そのため、2つのデバイスが通信を試みており、1つは全二重で、もう1つは半二重です。最終的な結果は、片側からのトラフィックが大量のパケットエラーを引き起こし、パケットを強制的に再送信させ、その方向の転送速度を低下させます。
この方法で、サーバーとNASボックスの間の問題を修正しました。1枚のカードはautoに、もう1枚は明示的に1000/Fullに設定されています。
私のマシンでも同様の問題が発生しました。マシンへのダウンロードは2MB/sでしたが、マシンからのアップロードは55kB/sでした。上記のトリックをすべて試し、スイッチ、ケーブルなどを確認しましたが、何も機能しませんでした。最後に私の問題を解決したのは、ネットワークマネージャーからイーサネットカードを取り外し(/etc/NetworkManager/NetworkManager.confでmanaged = falseに設定)、/ etc/network/interfacesでデバイスを手動でセットアップすることでした。
auto eth0
iface eth0 inet dhcp
今、私は両方向に1MB/sを取得しています。