前回はSynologyのNASであるDiskStation 220jに2.5Gb USB Ethernetアダプタを接続して利用できるようにしてみました。
今回は2.5Gb化したあとの様子を紹介したいと思います。
MTUの設定
2.5Gb Ethernetでは「ジャンボ・フレーム」を利用することでより良いパフォーマンスを得る事ができます。
ジャンボフレームは、DS220jのDSMで「コントロールパネル」→「ネットワーク」→「ネットワークインタフェース」と選択し、表示されている2番目の「LAN」をフォーカスした状態で「編集」を選択します。
そして表示された画面で「MTU値を手動で設定する」をチェックして、MTU値として「9000」を選択します。
MTUを変更して「OK」を選択すると、「MTUを修正すると、ネットワークサービスが再起動されます。よろしいですか？」と聞かれるので「はい」を選択します。
今回の記事ではMTUはデフォルトの「1500」と最大の「9000」の2つを試してみることにします。
iperf3による2.5GbE化の効果の確認
iperf3はネットワークのパフォーマンスを測定するツールです。
Windows PCとDS220jの両方にiperf3をインストールし、Windows PCとDS220jの間の通信速度を測定することで、2.5GbE化した効果を見ることができます。
準備: Windows PC
Windows PCの場合は公式サイトからリンクされている下記サイトからzipファイルをダウンロードして展開すればOKです。
私の場合は以前「iperf3.17_64.zip」をダウンロードしていたので、それをそのまま使うことにしました。
準備: DS220j
これはちょっと大変です。調べたところSynoCommunityというところで配布されている「SynoCli Monitor Tools」を使えば良さそうです。
SynoCli Monitor Toolsをインストールするためには、まず、DSMのパッケージセンターの「設定」を選択し、パッケージソースに「https://packages.synocommunity.com/」を追加します。
これでパッケージセンターの左側に「Community」が表示されるので「SynoCli Monitor Tools」を選択してインストールします。
インストール中にサードパーティのパッケージとの警告が出た場合は「同意をする」を選択します。これでインストールが完了するはずです。
測定方法
DS220jでまずiperf3をサーバーモードで起動しておきます。このためには、DS220jにSSHで接続し
iperf3 -s -f m
とすれば、OKです。
そして、Widnowsのコマンドプロンプトでiperf3を展開したフォルダに移動して、
iperf3 -c DS220jのIPアドレス -f m -t 30
を実行します。
これでWindows PCからDS220jの転送速度(DS220jから見ると受信速度)が測定できます。30秒間の結果が最後に表示されます。
反対向きのDS220jからWindows PCへの転送速度(DS220jから見た送信速度)を測定するときには、Windowsで入力するコマンドに「-R」をつけます。
iperf3 -c DS220jのIPアドレス -t 30 -f m -R
測定結果
結果は次のようになりました。送信・受信はDS220j絡みたときの送信・受信で、単位は「Mbps」です。
| 環境 | 送信 | 受信 |
|---|---|---|
| デフォルト | 950 | 949 |
| 2.5GbE化 (MTU: 1500) | エラーで終了 | 2285 |
| 2.5GbE化 (MTU: 9000) | エラーで終了 | 2290 |
受信(Windows PCからDS220jへの送信)については期待通りに高速化していることが確認できました。
一方、DS220jからWindows PCへの送信のテストについては安定した通信が行われず、最終的に「unable to send control message」というエラーになってしまいます。
30秒の実行だと長いので、10秒の設定で実行したときの結果(Windows PC側の表示)を紹介しておきます。
iperf3 -c 192.168.10.131 -f m -t 10 -R
Connecting to host 192.168.10.131, port 5201
Reverse mode, remote host 192.168.10.131 is sending
[ 5] local 192.168.10.125 port 56214 connected to 192.168.10.131 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 1.25 MBytes 10.4 Mbits/sec
[ 5] 1.01-2.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 2.01-3.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 3.01-4.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 4.00-5.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 5.01-6.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 6.01-7.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 7.01-8.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 8.01-9.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 9.00-10.01 sec 20.3 KBytes 0.17 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 0.00 Bytes 0.00 Mbits/sec sender
[ 5] 0.00-10.01 sec 1.27 MBytes 1.06 Mbits/sec receiver
iperf3: error - unable to send control message - port may not be available, the other side may have stopped running, etc.: Connection reset by peer
更にこの状態になると、DS220jのネットワークインタフェースが死んでしまい、以降の通信が全くできなくなってしまいます。
復旧させるには、DS220jを強制的に再起動させるか、DS220jにもとからあったネットワークインタフェースを使ってSSH接続して、次のコマンドでUSB Ethernetのインターフェースを再起動させる必要があります。
$ sudo ifconfig eth1 down
$ sudo ifconfig eth1 up
これは不安になる結果です。
CrystalDiskMarkによる比較
CrystalDiskMarkはディスクドライブのパフォーマンスを計測するフリーソフトです。
NAS上のネットワークドライブに対してパフォーマンスを測定することで、NASの使用感に近い結果が得られるのではないかと思います。
準備
Windows用のフリーソフトですのでダウンロードしてインストールすればOKです。
あとはNASの共有フォルダをWindows上でネットワークドライブとして割り当てておきます。
測定結果
まず2.5Gb化をしていないデフォルトの状態で、DS220jのネットワークドライブに対してCrystakDiskMarkを実行してみます。
シーケンシャルリード・ライトで約116MB/Sですので、930Mbps近くのスループットが出ています。
Windowsのタスクマネージャーを見ても確認できます。
1Gb Ethernetの実力は引き出せているというところでしょう。
次に2.5Gb化した状態(MTU: 1500)でCrystalDiskMarkを実行してみます。
しかし実行開始後にDS220jと通信ができなくなってしまい、CrystalDiskMarkは完了しませんでした。
タスクマネージャーを見ても、一瞬だけ1Gbps強の通信速度が出てから、その後は通信がほとんどできなくなっていることがわかります。
この状態になってしまうと、DS220jと全く通信できなくなってしまうので、iperf3のときと同じ状況です。
ただ、CrystalDiskMarkでのテスト内容をランダム・リードライトに限定すれば、DS220jのネットワークインタフェースは停止することなくなんとかテストを完遂できます。
しかし1GbEのときよりも遅く、完全に期待外れの結果となりました。
MTUを9000にしても同じ状況で、ランダム・リードライトのテストしか実行できません。
相変わらず1GbEのときよりも遅いという状況です。
CrystalDiskMarkができないということだと、パフォーマンスと言うよりも、ネットワークドライブとしての安定性に問題があると言えると思います。
ここまでのまとめ
ここまで試した結果では
- 受信あるいはアップロード(NAS←PC)は安定して動作し、通信速度も2Gbpsを超える
- 送信あるいはダウンロード(NAS→PC)は小規模なデータ通信ならば可能だが、大きなデータを転送すると、それ以降の通信が不可能になる
と言えます。
これでは残念ながら2.5GbE化した状態では使えません。
いろいろ調査してみる
せっかく2.5Gb USB Ethernetアダプタを購入したのですから、なんとかDS220jでも使いたいところです。
少し悪あがきしてみたいと思います。
オフロード設定をオフにする
ネットワークの処理の一部をハードウェアに行わせることを「オフロード」と呼びます。
ネットワーク関係ではソフトウェア処理の負荷を下げてスループットを向上させるためにこのオフロードが多用されますが、一方で、ドライバの成熟度が低い場合は安定性を損なう場合もあります。
デフォルトでは次のような設定になっています。
$ sudo ethtool -k eth1
Features for eth1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: 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 [fixed]
rx-all: off [fixed]
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]
ひとまず「on」になっているものはすべて無効にしてみます。
$ sudo ethtool -K eth1 rx off
$ sudo ethtool -K eth1 tx off
$ sudo ethtool -K eth1 sg off
$ sudo ethtool -K eth1 tso off
$ sudo ethtool -K eth1 gso off
$ sudo ethtool -K eth1 gro off
$ sudo ethtool -K eth1 rxvlan off
$ sudo ethtool -K eth1 txvlan off
この状態でiperf3を試してみますが・・・・
> iperf3 -c 192.168.10.131 -f m -t 10 -R
Connecting to host 192.168.10.131, port 5201
Reverse mode, remote host 192.168.10.131 is sending
[ 5] local 192.168.10.125 port 50451 connected to 192.168.10.131 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 169 MBytes 1397 Mbits/sec
[ 5] 1.01-2.00 sec 159 MBytes 1348 Mbits/sec
[ 5] 2.00-3.01 sec 80.0 MBytes 664 Mbits/sec
[ 5] 3.01-4.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 4.01-5.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 5.01-6.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 6.00-7.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 7.01-8.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 8.00-9.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 9.01-10.01 sec 0.00 Bytes 0.00 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 0.00 Bytes 0.00 Mbits/sec sender
[ 5] 0.00-10.01 sec 408 MBytes 342 Mbits/sec receiver
やっぱり停止してしまいました。
オフロードの無効化は効果なしです。
プレリリース版のドライバを使ってみる
前回の記事では「2.17.1-1」というバージョンのドライバを使いました。
しかし、プレリリースとして「2.17.1-2」がリリースされているのでこれを使って、状況が変わるか試してみましょう。
ダウンロードするファイルはDS220jでDMS 7.2を使っている場合は「r8152-rtd1296-2.17.1-2_7.2.spk」になります。
インストール方法は前回の記事を参照してください。
インストールしてDS220jを再起動したら、パッケージセンターでバージョンを確認して「2.17.1-2」になっていればOKです。
この状態でiperf3を試してみますと・・・
> iperf3 -c 192.168.10.131 -f m -t 10 -R
Connecting to host 192.168.10.131, port 5201
Reverse mode, remote host 192.168.10.131 is sending
[ 5] local 192.168.10.125 port 51784 connected to 192.168.10.131 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 128 KBytes 1.04 Mbits/sec
[ 5] 1.01-2.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 2.01-3.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 3.00-4.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 4.01-5.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 5.01-6.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 6.01-7.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 7.01-8.00 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 8.00-9.01 sec 0.00 Bytes 0.00 Mbits/sec
[ 5] 9.01-10.01 sec 122 KBytes 1.00 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 0.00 Bytes 0.00 Mbits/sec sender
[ 5] 0.00-10.01 sec 250 KBytes 0.20 Mbits/sec receiver
やっぱり送信は途中で止まってしまいます。
プレリリース版を使ってもこの問題は解決しないようです。
インターネット上の情報
実は私が遭遇した現象と全く同じ状況がレポートされています。
2022年ごろから指摘されていて、いろいろな方が調査していますが、残念ながら解決されていません。
Synology用のドライバパッケージを開発している開発者の意見としては、CPU(rtd1296)のUSBコントローラ周りが疑わしい、とも書かれています。
もしそうだとするとDS220jの2.5GbE化は厳しかもしれません。
可能性があるとするとDSMがバージョンアップして利用しているLinux Kernelがバージョンアップされ、状況が変わることを期待することぐらいでしょうか。
頑張って記事を書いてきた結果としては残念な結果ですが、仕方がありません。2.5GbE化は諦めたいと思います。
まとめ
今回は2.5G USB Ethernetを使って2.5GbE化したDS220jの実力を確認してみました。
DS220jからみて受信方向では期待通りの転送速度向上が見られたのですが、反対側の送信方向では通信がすぐに止まってしまうという不安定なものとなりました。
調べてみるとこの問題はCPUにrtd1296を採用したDiskStationで見られる問題でこの記事作成時点では解決方法がないようで、非常に残念な結果となりました。
コメント