夢幻泡影 - 源本舗

無事にギガビット・イーサネット(GbE)化できた自宅LAN。
納得のいく性能向上を果たせたものの…
1000Mビット中480Mビットと、その帯域にはまだまだ余裕がある状態。
今回はジャンボフレームを用いたスピードアップに取り組みます。

まず、ジャンボフレームとはどのようなものかをおさらい。
イーサネットのフレーム長は通常、ペイロード長1500バイト（ヘッダ込み1518バイト）。
大きなファイルは、1500バイトのパケットに小分けした上にそれぞれにヘッダがつけられて、ちまちま送信されます。
ジャンボフレームを利用することで一度に転送するデータサイズが大きくでき、送信回数も少なくなって、いちいちヘッダをつける回数も減るので、速度アップにつながる…といった仕組み。
ただしジャンボフレームを利用する機器は、経路にあるハブを含めて対応したものが必要。
また、規格化されている訳ではない為、設定には充分な注意が必要です。
もっとも通常の機器もネットワーク内に混在可能なので、ハブさえしっかりしたものを選べばそれほど難しく考える必要はありません。

1フレームで送信するデータの最大値は、MTU(Maximum Transmission Unit)で設定します。
今回、使用するハブ「LSW5-GT-8NS」は最大16000バイト（ヘッダ含む）まで対応。
サーバ機に使用しているLANアダプタ(NIC)「LGY-PCI-GT」は最大7154バイト（ヘッダ込み7172バイト）まで。
これを参考に、クライアントとなるWindows機が幾らに設定できるかを確認します。

デバイスマネージャーからネットワークアダプターを開き、LANアダプタの詳細設定でジャンボフレーム（英語で「Jumbo Flame」だったりも）を探して設定します。
とりあえず、ドロップダウンリストで2KBから4KBまで設定があったので、最大となる4KB(4096バイト)を選択。
選択後にOKを押してやると、すぐにネットワーク接続がリセットされ設定が反映されます。
確認のため、スタートメニューを右クリックしてコマンドプロンプトを管理者権限でひらき、netshコマンドでチェック。

>netsh interface ipv4 show interfaces
Idx Met MTU 状態 名前
--- --- ---------- --------- ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
7 25 1500 connected イーサネット
11 35 1500 connected VMware Network Adapter VMnet1
3 35 1500 connected VMware Network Adapter VMnet8


…だが、イーサネットのMTU値が変わっていない。
他の数値に変更したり、再起動したりしても駄目。
あーでもない、こーでもない…と悩みまくること1時間。
色々調べると、マザーボードのオンボードLANドライバが古いことが判明。
Windows 10の導入時、自動インストールされたものをそのまま使っていたのが悪かった様で、マザボの公式にはより新しいバージョンのドライバが公開されていた。
こちらをインストールしたことで、それまで英語だった詳細設定も日本語になり、ジャンボフレームの設定値も2KBから9KBまで選択できるように。

ジャンボフレームに7KBを選択

7KBを選択してnetshコマンドで確認すると、今度はちゃんとMTUが反映されていました。
7168(1024×7)-18(ヘッダ)と思われる『7150』が設定されています。

>netsh interface ipv4 show interfaces
Idx Met MTU 状態 名前
--- --- ---------- --------- ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
7 25 7150 connected イーサネット
11 35 1500 connected VMware Network Adapter VMnet1
3 35 1500 connected VMware Network Adapter VMnet8


次にサーバ機側を設定。
ネットワーク設定内のデバイスeth0の設定より「MTUを設定」にチェックを入れ、Windows機に合わせて『7150』を入力します。

MTUを7150に設定

設定後にネットワーク設定を終了させて設定を保存したのち、ネットワークサービスを再起動。

# service NetworkManager stop
# service network stop
# service network start
# service NetworkManager start


これで設定完了。
試しに、pingコマンドでちゃんと設定されているか確認します。
設定されたMTU値7150からヘッダ分28バイト(ICMPヘッダ8+IPヘッダ20)を引いた、7122を送信。

>ping -f -l 7122 -n 1 192.168.3.10（サーバ機のローカルIP）
192.168.3.10 に ping を送信しています 7122 バイトのデータ:
192.168.3.10 からの応答: バイト数 =7122 時間 <1ms TTL=64
192.168.3.10 の ping 統計:
パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 0ms、最大 = 0ms、平均 = 0ms


正常に送れたことを確認して、次は1バイト増やした7123を送信してみる。

>ping -f -l 7123 -n 1 192.168.3.10
192.168.3.10 に ping を送信しています 7123 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
192.168.3.10 の ping 統計:
パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、


こちらはエラーとなるので、MTUが7150できちんと設定できていることが確認できました。

早速、CrystalDiskMarkでネットワークドライブの転送速度を計測すると…
シーケンシャルリードでは、ジャンボフレーム適用前より1.6倍となる100MB(800Mbit)。
他の数値も、2〜3割増しくらい速度アップしていました。

ジャンボフレーム適用（MTU:7150）
シーケンシャルリードは適用前と比べて1.6倍の速度アップ。

4KBでほぼ変化なかったのは、小さいサイズでは差が出にくい為かな。
先と同じ2.5GBのファイルをコピーしてみたところ、30〜40秒程度でコピー完了。
当初の100BASE-TXから比較すると、およそ9倍の速さとなり、目的通りさらなる速度アップを果たせました。

このファイルサーバは複数のPCで共通して利用できるメディアサーバー的な使い方をしています。
圧倒的に速度が速くなったことで、動画類の管理がかなり楽になったのはうれしいところ。
また現在は単一のHDDで運用しており冗長性がない為、いずれはスキルアップもかねてRAIDの導入にも挑戦してみたいかな。

＞関連リンク
　源本舗 夢幻泡影 - 2017年01月19日
　＠IT - イーサネットを高速化するジャンボ・フレーム技術

回線トラブルがあったりした事もきっかけに、自宅内のLANをギガビット・イーサネット(GbE)化することに。
元々2000年頃インターネットを始めた当時は光回線の開通が見込めない環境（現在もですがｗ）で尚且つ機材が高価すぎた為、100BASE-TXで必要充分として長いことやってきましたが…
自宅サーバをNASとして使用していることもあり、機材の値段もかなり手頃になってきましたので、LAN内環境の改善に取り組んでみようという試みです。

現在手持ちのPCは、ほとんど1000BASE-T対応。
ただ…よりにもよって、現在サーバ機に使用している『GA-GC230D』のオンボードLANは100BASE-TX止まりという罠(爆)
という訳で、LANハブと共にLANアダプタも用意することに。
今回入手したのは下記の二つ。
LANケーブルは手持ちが全てカテゴリー5eなので、今回は見送りました。

　Amazon - BUFFALO LSW5-GT-8NS/BK（公式サイト）
　Amazon - BUFFALO LGY-PCI-GT（公式サイト）

最近はUSBのものが主流らしく、PCIでギガビット対応のLANアダプタって意外と出ていない様で…
今回チョイスした「LGY-PCI-GT」も2004年頃とかなり昔から発売されているもの。
レビューを見ると耐久性とかに少し不安はある様ですが、各種Linuxでの運用実績もあり設定などについて情報も多い点を評価。

ロープロファイルにも対応した、スタンダードなLANアダプタ
チップは蟹でおなじみ、Realtek RTL8169

まずはハブを設置。
これは今ある、10/100Mのもの(LSW-TX-8NS)と入れ換えるだけなので、手間はかからない。
ただし、モデム(ルータ)に直接つないでいたPCはハブへとつなぎ替え、逆にこれまでハブにつながっていたテレビなどの家電はルータへ直結。
これはモデムのLANポートは100Mまでの対応のため。
これまではWANへの接続を優先し、PCはモデムへ直接接続していたのだけれど…
今回は、まずGbEを構築して、それがWANにも出られるようにするというかたちになります。

続いて、サーバ機へLANアダプタ(NIC)の取り付け。
まずは電源を落とし、PCIカードを挿してからVine Linuxを起動。
起動時、特に操作をすることもなく、自動でドライバがインストールされました。
rootでログインし、ネットワーク設定よりハードウェアを確認すると「eth1」としてRTL8169が追加されています。
これでこのLANアダプタは使用することができるのだけれど…
OSは「eth0」を使用する設定となっているため、この状態のままオンボードLANをオフにするとネットワークが使えなくなる事に。

そこで次は、今回取り付けたLGY-PCI-GTを「eth0」に変更します。
まず再起動して、BIOSでオンボードLANを使用しない設定に切り替え。
そのままOSを起動させて、ネットワーク設定のハードウェアより「eth0」に設定されている8101Eを削除しておきます。

続いて、コマンドライン端末よりネットワークサービスを停止。

# service NetworkManager stop
# service network stop


/etc/udev/rules.d/70-persistent-net.rules を書き換え、eth1として認識されているデバイスをeth0に入れ替えます。

◆変更前

# Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:d0:3e:4b:1b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="cc:e1:d5:8d:4f:1d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"


NAMEの設定を『eth0』⇔『eth1』と変更。
ついでに気分の問題で、位置も入れ替えておきます。

◆変更後

# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="cc:e1:d5:8d:4f:1d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:d0:3e:4b:1b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"


保存した後はネットワークサービスを起動。（OSを再起動させても可）

# service network start
# service NetworkManager start


最後に、ネットワーク設定内のデバイスeth0の設定より、ハードウェアデバイスのMACアドレスを検出しなおして完了です。

とりあえず、CrystalDiskMarkでネットワークドライブの転送速度を計測。
事前に調べておいた100BASE-TXとの比較です。

GA-GC230DオンボードLAN（Realtek RTL8101E）
11MB(88Mbit)と、まぁ100BASE-TXとしては当たり障りのない数字が出ています。

LGY-PCI-GT（Realtek RTL8169）
シーケンシャルは60MB(480Mbit)と、実に6倍近く速度アップ。

ここまでハッキリ体感できるほどに速くなるとは思っていなかったので、正直驚きました。
60MB(480Mbit)というと、USB2.0の理論値。
実際、USB2.0接続の外付けハードディスクよりも1.5倍近く速い数字が出ています。

おまけ。Logitec LHR-DS02U2

2.5GBの動画ファイルも、一分かからずにコピーできたのはかなりうれしいところ♪
以前はこのサイズというと、かるく4〜5分はかかってたからなぁ…
次はさらなる速度アップを目指して、ジャンボフレームに挑戦します。

＞関連リンク
　Amazon - BUFFALO LSW5-GT-8NS/BK（公式サイト）
　Amazon - BUFFALO LGY-PCI-GT（公式サイト）

1月5日。
夜10時をまわった頃…突然インターネットがオフラインに。
チェックしたところ、モデムのリンクランプが消えているのに気が付いた。
ひとまず電源を入れ直してみるが…変化なし。
スマホからYahoo!BBのサポートページにログインして回線トラブルがないか確認してみたところ…
料金未払いとか表示が。
いや、毎月ちゃんと支払っているんですが!?
ウチは引き落としではなくコンビニ払込票にて支払いをしており、領収書も手元にある。
すでにサポート時間外のため、翌朝電話して確認することに。

明けて6日。
電話してみると、まず支払いについては問題無いことが判明。
料金未払いにより回線を停止する場合でも通常は中旬になってからだそうで、今回の件とは関係ない模様。
そうなると、回線かモデムに物理的な問題があることになるが…
サポートのかたが回線のチェックをしてみたところ、そちらに問題はないらしい。
続いて電話に従ってモデムの電源入れ直しをするも、やはり変化なし。
そのまま、モデムの交換という流れになった。
いわゆる先出し発送にて送ってもらい、交換後返送するという手順だが…
届くのは週明け9日。
それまでネットにつながらない事が確定してしまった。

そして9日。
時間指定していた12〜14時の間に荷物が到着。
受け取りと同時に、事前に梱包しておいたモデムを渡して返送も済ませてしまう。
届いたのは、これまで使っていたのと同じ『トリオモデム 3-G plus』。
早速、取り付けると…なかなかリンクランプが点かず不安になるものの、1分後くらいに点滅が始まり…無事に接続できた。
結局のところ、モデムの故障が原因でした。
まぁ、契約してから3年間、ずっと電源入れっぱなしだった訳だし、無理もないところかな。

手早く、自宅サーバ用にポート開放などルータとダイナミックDNSの設定を済ませる。
試しにスマホからアクセスしてみると…
この日記にはアクセスできたが、創作サイトの方は『504 Gateway timeout』とエラーに。
『X-plore File Manager』を使ってFTPサーバにアクセスを試みたところ、やはり接続はできないが、IPアドレスが以前のままになっている事に気が付いた。
変更したはずのダイナミックDNSがまだ反映されていないらしい。
時間をおいて再確認したところ、無事に表示されるようになりました。

Yahoo!BBの対応は、マニュアル通りといった感はあるものの、的確なものでした。
まぁ、モデムが届くまでの間、回線が使えなくなってしまったのは仕方のないところ。
あと自宅サーバ用のダイナミックDNS。
以前使っていた『JSpeed』は、オフラインURL転送が利用でき、サーバが落ちた時などに別途用意しておいたページへ飛ばすことができたのですが…
現在利用させていただいている『Dynamic DO!.jp』と『ieServer.Net』はいずれもURL転送には未対応。
今回のような回線トラブル時には打つ手がないのが痛いですね。
対応しているダイナミックDNSサービスに変更したいものですが…
イコール、URLの変更につながるので、なかなか難しいところです。

「Wizardry - New Age of Llylgamyn」。
・シナリオ#4 ワードナの逆襲
・シナリオ#5 災禍の中心。
二つのシナリオが収録されたウィザードリィシリーズのベスト版です。
1999年、ローカスによりプレイステーション版、後にエレクトロニック・アーツ・スクウェアよりWindows版が発売されました。
なお、#1〜#3は「Wizardry - Llylgamyn Saga」に収録。

ウィザードリィはファミコン時代から#1、#2、#3とプレイ。
特にスーパーファミコンでプレイした#5は、当時でも飛び抜けた映像や音楽のクォリティの高さもあり、どっぷりハマったものでした。
このニューエイジ オブ リルガミンも、#5目当てにWindows版を入手したのですが…
実はクリア直前（後はラスボスを倒すだけ）に地獄でアイテム集めをしていた時に、OSをWindows7へとアップグレードしたことにより続きをプレイできなくなってしまったという(爆)
「d3drm.dll」の追加など色々と試してはみたものの、当時の情報では正常なプレイに至ることができず、あきらめる結果と。

そして現在、Windows10(x64)の環境でプレイできないか…と試行錯誤してみました。
とりあえず、そのままでは「コンピューターにd3drm.dllがないため、プログラムを開始できません。」と出て起動できない。
で、「d3drm.dll」を「\Windows\SysWOW64」に設置。
※ ネット上でよく「\Windows\System32」と表記されている情報を見ますが…
　 d3drm.dllは32ビットのプログラムなので、64ビットOSの場合は「SysWOW64」内に置いてやらないと駄目です。

これで起動するようになり、ゲーム選択プログラム（wiz45title.exe）は問題無く動きました。
しかし、ゲーム本体（wiz5s_k.exe, wiz4s_k.exe, wiz6s_k.exe）が起動すると、タイトル画面がほとんど真っ暗（選択カーソルのみ）だったり、線画でないとゲーム画面が表示されなかったり…不具合満載。

Windows10(x64)上 フルスクリーンでのプレイ
線画モードならプレイ可能だが…
オートマッピング画面や戦闘シーンなど、表示に不具合多数

城での背景や戦闘時モンスターも表示されず、オートマッピングの表示もおかしい。
さらにはゲームを終了した時に、開いていたウィンドウのサイズが変わってしまううえに、サブモニタのほうへ移動してしまう。
Windows8で音が鳴らない…という情報も見かけたけれど、とりあえずこれは大丈夫でした。

で、「DirectX ウィンドウ化ツール」を試してみたところ、これが当たり！
「wiz5s_k.exe」（#5）を追加してやり、そのままwiz5s_k.exeを直接起動させただけで、タイトル画面や城の背景も正常に表示されました。
ゲーム画面も、ポリゴンでは駄目でしたが、線画モードでは青かった背景がちゃんと黒く表示され、オートマッピングも正常に表示されるように。
これでもゲームに支障はないレベルでしたが…
色々イジっていたところ、DirectXにハードウェアを使わない設定をすることで、ポリゴンも正常に表示されました。
おそらくはVista以降で導入されたAeroなど、Windowsの表示周りが大きく変わったことによるトラブルでしょうね。

Windows10(x64)上 ウィンドウ化でのプレイ
DirectXにハードウェアを使わない設定で、ポリゴンも正常に表示
ちなみに上の画像と同じ場所だが、線画では見える奥の壁や扉がポリゴンだと見えないｗ

ただ、DirectX ウィンドウ化ツールだが、管理者権限で起動していてもグローバルフックに失敗してしまう。
Vistaとか7とかでは問題なさそうな情報を見るので、Windows10による不具合だろうか？
この状態でも、ゲーム本体単体での起動・窓化は成功するので問題はないのだけれど、通常の「ゲーム起動→ゲーム選択→ゲーム本体の起動」という流れではプレイできないのが残念。
ちなみに時折出る「フック用DLLが存在しません」というエラーは、「DirectX ウィンドウ化ツール」を再起動するか、補助DLLに直接「D3dHook.dll」を指定してやればおｋ。

何はともあれ、これで久々にウィザードリィをプレイできる。
極悪難易度で知られる#4も未プレイのままだし、こちらに挑戦するのもいいかも…？

＞関連リンク
　DirectX ウィンドウ化ツール

新年あけましておめでとうございます。
今年もどうぞよろしくおねがいいたします。

昨年は、自分にとって良くも悪くも激動の年となりました。
それは「これが厄年ってものか…」と実感できるほどのもの。
自分自身の不注意に運の悪さも重なり、大きなトラブルも多数経験…
ホントにヘコみっぱなしの一年でした。

兎にも角にも昨年秋には環境が大きく変わり、ある程度自分の時間もとれる様に。
精神的な余裕も出てきましたし、趣味の範囲ででもまた創作活動を行っていきたいところですね。