iperf で LAN の速度測定

最近スマホや WindowsPC 間のファイル転送速度を色々測っていたりする。が、ファイル転送だと、ストレージの読み書き速度とか、smb プロトコルのオーバーヘッド？とかあって、転送速度が遅いのは、何が原因なのか良くわからない。ということで、色々なデバイス間で、通信速度を測ってみようと考えた。

NetPerf というのが結構有名で、いろんなプラットフォームで動くというのを見つけて試そうとしたのだが、Windows 用のバイナリが見つからず。自分でコンパイルしてみようとしたのだが、Cygwin と Windows SDK があればできるはずが、説明が古いのもあって、結局やり方が分からず。昔は、コンパイル済みのバイナリも配布されていたようなのだが…

ということで、もう少し探すと、iperf というのを見つけた。こちらも同様に色々なプラットフォームに対応していて、バイナリも配布されている。CentOS5 の自宅サーバーでも動かす事を前提とすると、2.0.5 が yum で拾える最新版のようだ。ということで、Windows 用にもかなり古いものだが、2.0.5b をダウンロードして準備完了。

ATOM N270 な自宅サーバーと Dynabook V714 のクレードルの GigaEther 同士をハブを介して通信する状況でやってみたら、300Mbps 弱。あんまり速くないな。他のデスクトップ PC と V714 の間でやってみると 630Mbps くらい。もう少し速いかと思ったのだが。後、結構変動も大きい。50Mbps くらい変わる。

使ったバージョンが古いせいか、あんまり精度は高くないかも。ただ、自宅サーバーのネットワーク速度はそこそこ新しい PC 間の半分以下、というのがわかった？

今日の GalaxyS8 と PC のファイル転送テスト 3

しつこく、GalaxyS8 と PC 間のファイルのやり取りで、できるだけ安定して速い方法を探求している。今回は、USB-typeC の OnTheGo ケーブルを使って、USB-イーサアダプタでネットワーク接続する実験。ただ、残念なことに、OnTheGo ケーブルは USB3.0 対応のものだが、USB-イーサアダプタは USB2.0 止まり。いつか USB3.0 対応のものを試してみる必要がある。というか、USB type-C に直接挿せるものもありそうだが。

それはさておき、Android アプリとして、ファイルマネージャー＋、X-Plore、ES ファイルエクスプローラーを使って、PC の共有フォルダから、GalaxyS8 の内部ストレージへのファイルコピーで、速度を測ってみた。結構アプリによる速度の違いがあった。また、ファイルマネージャー＋は、バックグラウンドに回した方が速度が上がるという、謎の挙動もあった。

ということで、結果としては、おおまかだが、ファイルマネージャー＋は、バックグラウンド時 150Mbps、フォアグラウンド時 130Mbps、X-Plore は一番成績が悪くて、95 Mbps 程度で、100 に届いたのを見ていない。ES ファイルエクスプローラーは、110Mbps くらい。と言った所。

Wifi で接続するよりは安定しているようにも思えるが、それでもそれなりに転送速度はふらつく。また、USB2.0 でも、もう少し速くでも良い気がしたり。TCP のハンドシェークが遅いのかな？ UDP でばしばし転送するプロトコルを使わないと駄目なのだろうか。

USB3.0 のハブ付きなイーサネットアダプタが結構 Amazon でも見つかって、そんなに高くない。さすがに USB typeC のもの含めて、GalaxyS8 で動くか不明。一度チャレンジしてみる？

今回使った USB2.0のは、PLANEX の製品。

PLANEX 1000BASE-T Gigabit対応 USB LANアダプタ (MacBook Air/carrozzeria対応) GU-1000T

今日の GalaxyS8 と PC のファイル転送テスト 3

しつこく、GalaxyS8 と PC 間のファイルのやり取りで、できるだけ安定して速い方法を探求している。今回は、USB-typeC の OnTheGo ケーブルを使って、USB-イーサアダプタでネットワーク接続する実験。ただ、残念なことに、OnTheGo ケーブルは USB3.0 対応のものだが、USB-イーサアダプタは USB2.0 止まり。いつか USB3.0 対応のものを試してみる必要がある。というか、USB type-C に直接挿せるものもありそうだが。

それはさておき、Android アプリとして、ファイルマネージャー＋、X-Plore、ES ファイルエクスプローラーを使って、PC の共有フォルダから、GalaxyS8 の内部ストレージへのファイルコピーで、速度を測ってみた。結構アプリによる速度の違いがあった。また、ファイルマネージャー＋は、バックグラウンドに回した方が速度が上がるという、謎の挙動もあった。

ということで、結果としては、おおまかだが、ファイルマネージャー＋は、バックグラウンド時 150Mbps、フォアグラウンド時 130Mbps、X-Plore は一番成績が悪くて、95 Mbps 程度で、100 に届いたのを見ていない。ES ファイルエクスプローラーは、110Mbps くらい。と言った所。

Wifi で接続するよりは安定しているようにも思えるが、それでもそれなりに転送速度はふらつく。また、USB2.0 でも、もう少し速くでも良い気がしたり。TCP のハンドシェークが遅いのかな？ UDP でばしばし転送するプロトコルを使わないと駄目なのだろうか。

USB3.0 のハブ付きなイーサネットアダプタが結構 Amazon でも見つかって、そんなに高くない。さすがに USB typeC のもの含めて、GalaxyS8 で動くか不明。一度チャレンジしてみる？

今回使った USB2.0のは、PLANEX の製品。

PLANEX 1000BASE-T Gigabit対応 USB LANアダプタ (MacBook Air/carrozzeria対応) GU-1000T

東芝 1 チップ 1TB のフラッシュメモリ

Impress さんの記事。平面への集積は限界が近づいて、厚み方向への集積がどんどん進んでいるらしい。すでに、厚み方向に積層する3次元フラッシュメモリを更に 48 枚重ねて、TSV 技術で、チップ間の信号線を作るという、アイデア自体は簡単にできそうな気もするが、実際には、かなり難しい技術なんだろう。微小な構造を、安定して大量生産まで持ってくるには、かなりいろいろな技術がつぎ込まれているに違いない。

ただ重ねるだけなら、ワイヤボンディング等でも可能なのだろうか？ 各層から引っ張り出したワイヤーが、層間を繋いでいるとなると、えらいことになりそうなので、現実的には無理のようにも思える。エッジ部分しか配線できないし。TSV なら、面で層間をつなげるメリットもあるのかも。

それはさておき 1 チップで 1TB とは恐れ入る。指の爪程度の大きさのチップで 1 TB。4 チップあれば、今自室に転がっている最大容量の HDD と同じ容量になるとは。スマホにも TB レベルのストレージが搭載されるのも遠くない未来？

ただ、チップを積層しているということは、価格もそれなりに高そう。16 層にしているということは、積層しなければ 16 チップ。その分の値段がすると。更に TSV によるコスト、歩留まりの低下を考えると、ほんと特殊用途とか大規模サーバーとかにしか使えない価格になりそう。でも 1 ラックで 1PB とか余裕になったら、コストメリットがある場合もありそうではある。

でも、そろそろフラッシュメモリの物理限界が見えてきそうだなぁ。後、東芝メモリもどうなるのか気になるところ。技術はあるんだよなぁ。

東芝 1 チップ 1TB のフラッシュメモリ

Impress さんの記事。平面への集積は限界が近づいて、厚み方向への集積がどんどん進んでいるらしい。すでに、厚み方向に積層する3次元フラッシュメモリを更に 48 枚重ねて、TSV 技術で、チップ間の信号線を作るという、アイデア自体は簡単にできそうな気もするが、実際には、かなり難しい技術なんだろう。微小な構造を、安定して大量生産まで持ってくるには、かなりいろいろな技術がつぎ込まれているに違いない。

ただ重ねるだけなら、ワイヤボンディング等でも可能なのだろうか？ 各層から引っ張り出したワイヤーが、層間を繋いでいるとなると、えらいことになりそうなので、現実的には無理のようにも思える。エッジ部分しか配線できないし。TSV なら、面で層間をつなげるメリットもあるのかも。

それはさておき 1 チップで 1TB とは恐れ入る。指の爪程度の大きさのチップで 1 TB。4 チップあれば、今自室に転がっている最大容量の HDD と同じ容量になるとは。スマホにも TB レベルのストレージが搭載されるのも遠くない未来？

ただ、チップを積層しているということは、価格もそれなりに高そう。16 層にしているということは、積層しなければ 16 チップ。その分の値段がすると。更に TSV によるコスト、歩留まりの低下を考えると、ほんと特殊用途とか大規模サーバーとかにしか使えない価格になりそう。でも 1 ラックで 1PB とか余裕になったら、コストメリットがある場合もありそうではある。

でも、そろそろフラッシュメモリの物理限界が見えてきそうだなぁ。後、東芝メモリもどうなるのか気になるところ。技術はあるんだよなぁ。

CentOS5.11 で L2TP な VPN 設定

以前から、外部から拙宅 LAN に接続するために、VPN 接続を使ってきた。フレッツ光の HGW に L2TP な VPN 機能があるのと、自宅サーバーで pptpd を設定して、どちらでも接続できるようにしていた。先日、光回線をV6プラスに変更したため、HGW の VPN が使えなくなった。一応 PPTP の方は使えるのだが、こいつがなんか安定性が悪い。VPN 越しにリモートデスクトップ接続すると、すぐに切れてしまう。ファイルの転送も遅い。遅いのはともかく、接続が切れる（表面上はつながったままだが、パケットが届かない）のは、切断・接続作業をしないといけなかったり結構困る。

そこで、安定性が改善するとは限らないが、L2TP VPN に自宅サーバーを対応させることにした。docomo 回線だと PPTP が通らなかったりするし、PPTP 自体、安全性に問題があるようなので、ここは思い切るときだと。

安全性うんぬんを言うなら、CentOS5 な時点でまずいわけであるが、とりあえず、それはおいておいて L2TP な VPN の設定。GitHubGist で公開されている CLCL さんのドキュメント「CentOS 6でとにかくL2TP/IPsecサーバ」を参考に設定した。この記事は、CentOS6 ようだったが、ほぼそのまま CentOS5 でも使えた。

yum EPEL のリポジトリの設定や、その他 rpm は、CentOS5 用のをググって拾ってくる必要あり。まぁ、CentOS のバージョンが違うので当たり前ではあるが。記事中のサーバーの IP アドレスには、自宅サーバーのプライベート IP アドレスでいいようだ（記事中もそうだが、10.0.0.0/8 なのは普段使わないので…）。

後、Windows の場合、レジストリの変更が必要とか。No Such Blog or Diary さんの記事を参考にした。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent に名前が AssumeUDPEncapsulationContextOnSendRule で値が 2 な DWORD 値を設定しておく。一度 Windows を再起動した方がいいようだ。tcpdump で見ていると、これを変更していないと、結構最初の方のパケットのやり取りで止まってしまう感じだった。

ということで、無事、Windows10 や Android から L2TP/PSK で接続できるようになった。安定度も、PPTP に比べるとかなり向上。何時間単位で、負荷を掛けても大丈夫。ただ、速度的には、10Mbps～15Mbps くらい。もうちょっと速いといいのにな。1.6GHz な ATOM N270 なサーバーだとこんなものなんだろうか。

 
しかし、ほんと、こういうノウハウを共有してくれる人がいるのがありがたい。

CentOS5.11 で L2TP な VPN 設定

以前から、外部から拙宅 LAN に接続するために、VPN 接続を使ってきた。フレッツ光の HGW に L2TP な VPN 機能があるのと、自宅サーバーで pptpd を設定して、どちらでも接続できるようにしていた。先日、光回線をV6プラスに変更したため、HGW の VPN が使えなくなった。一応 PPTP の方は使えるのだが、こいつがなんか安定性が悪い。VPN 越しにリモートデスクトップ接続すると、すぐに切れてしまう。ファイルの転送も遅い。遅いのはともかく、接続が切れる（表面上はつながったままだが、パケットが届かない）のは、切断・接続作業をしないといけなかったり結構困る。

そこで、安定性が改善するとは限らないが、L2TP VPN に自宅サーバーを対応させることにした。docomo 回線だと PPTP が通らなかったりするし、PPTP 自体、安全性に問題があるようなので、ここは思い切るときだと。

安全性うんぬんを言うなら、CentOS5 な時点でまずいわけであるが、とりあえず、それはおいておいて L2TP な VPN の設定。GitHubGist で公開されている CLCL さんのドキュメント「CentOS 6でとにかくL2TP/IPsecサーバ」を参考に設定した。この記事は、CentOS6 ようだったが、ほぼそのまま CentOS5 でも使えた。

yum EPEL のリポジトリの設定や、その他 rpm は、CentOS5 用のをググって拾ってくる必要あり。まぁ、CentOS のバージョンが違うので当たり前ではあるが。記事中のサーバーの IP アドレスには、自宅サーバーのプライベート IP アドレスでいいようだ（記事中もそうだが、10.0.0.0/8 なのは普段使わないので…）。

後、Windows の場合、レジストリの変更が必要とか。No Such Blog or Diary さんの記事を参考にした。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent に名前が AssumeUDPEncapsulationContextOnSendRule で値が 2 な DWORD 値を設定しておく。一度 Windows を再起動した方がいいようだ。tcpdump で見ていると、これを変更していないと、結構最初の方のパケットのやり取りで止まってしまう感じだった。

ということで、無事、Windows10 や Android から L2TP/PSK で接続できるようになった。安定度も、PPTP に比べるとかなり向上。何時間単位で、負荷を掛けても大丈夫。ただ、速度的には、10Mbps〜15Mbps くらい。もうちょっと速いといいのにな。1.6GHz な ATOM N270 なサーバーだとこんなものなんだろうか。

しかし、ほんと、こういうノウハウを共有してくれる人がいるのがありがたい。