2017-06-25

WUuu... の呪いは、酔いどれ愚者を創造者へアップデートできるか?

SM 狂の十字架バージョンでは...
記念日に呪われ、非生産性な騒動に巻き込まれた。ようやく平和が訪れ、仲間内で合言葉となっていた WUuu... の声も聞かれなくなった。
ちなみに、WUuu... とは、Windows Update の略で、うぅぅ... と唸りながら発声する。

今度は、Creators Update...
ある仕事場の環境で新規に一台購入すると、既に Creators Update 版であり、こいつがなかなか安定している。なので、残りの Win マシン10台をアップデートに踏み切った。
おぉ~、安定してそうじゃないかぁ... 気持ち悪いほどに... こんな当たり前のことで感動させてくれるとは... なるほど、これが SM 狂戦略であったかぁ...
そして、酔いどれ愚者の生産性までも高め、創造者へアップデートしてくれるってかぁ?
しかしながら、これで「WUuu... の呪いは解けた!」と宣言する自信は、まだ持てないでいる。出来の悪い子ほど... と言うが、安定さえしちまえば、Win10 群もなかなか可愛い連中である。ただし、これで仕事をした気分になってはいけない。環境に翻弄されているということは、本来の仕事が疎かになっているということだ。

猛省!実に、エンジニアらしくない...
今回は、ファイル共有で嵌ってしまった。結論から言うと、帯域系に問題を抱えていた。具体的には、 受信時のウィンドウ幅である。なのに、ひたすらファイル共有を疑い、あれこれ設定を試した挙句徹夜してしまう。この手のトラブルはシステムの根本的な問題なので、最初に気づきそうなものだが...
Win10 の一連のアップデートは、ある教訓を与えている。目先の現象に囚われ、エラーメッセージを冷静に捉えることができず、設定を感覚的にいじっている。とにかく動けばいいってな感じで躍起になっているのだ。
経験を積めば、蓄積された知識の方が先立ち、改めて現象を観るという基本的な思考が疎かになる。思い込みってやつだ。歳をとるとせっかちになるのか。問題を抽象化することが悪いことではない。ただ、思い込みと紙一重だということも忘れてはなるまい。
そして、WUuu... の呪いは、この酔いどれ愚者に一つの教訓を与えてくれた。それは... まず観ることだ!

さて、酔いどれ愚者の思考の流れを追っておこう...

1. バージョン 1703, ビルド 15063.413...
ぱっと見た目には、すっきりした感がある。スタートメニューのタイルをグループ化して、まとめることができる。iPhone のように。鬱陶しいアプリ一覧も非表示にできる。
しかーし、例のごとく、関連付け、キーバインド、規定の IME などの設定がチャラ。しかも、マシンによって症状が違うときた。おっと!プリンタが使えない。再設定すればいいのだけど...
こうした些細なものがボディブローとして利いてきて、生産性を思いっきり低下させる。吹聴される大型アップデートってやつは、そもそもアップデートと呼べる代物なのか?
... こうして、まずは愚痴るのであった...

2. ファイル共有でトラブル?いや、犯人はチューニングレベルだった...
あれ?おいら愛用の Surface Pro3 だけが、ファイル共有できない。しょっちょう外部環境に曝しているので、よそ者とでも認識されたのか?とはいえ、同じ SM 狂の製品だよ。
症状は、時間がかかった末に、マシンが見つかりません!ときた。外からマシン名は見えていて、ping も通るし、アクセス権も問題なし。ファイアウォールも問題なし。この手のトラブルは、バージョンが混在した時に、マスターブラウジングの問題でよく見かける... などと思い込み、マシンの起動タイミングや共有設定をあれこれ試す。
そして、半ば諦めかかった、その時...
気分転換にネットサーフィンをやっていたら、通信負荷が異常なほど重い!iPhone 経由のテザリングでも、やはり重い!もしかして、本当にタイムアウト?素直にエラーメッセージを受け取れば、早々に気づいていただろうに。
... 要するに、ファイル共有の問題ではなかった...

3. TCP の自動チューニングレベルで通信負荷を改善!
通信負荷が問題だとすれば、ハードウェアに根本的な問題を抱えているかもしれない。そして、ドライバのバージョンを確認、再インストールも試みたがダメ!WiFiルータとの相性か?
あるいは、IPv6 と IPv4 の混在が問題なのか?とはいえ、今更 v4 に統一するのも時代錯誤だし、v6 に完全移行するにもバックボーンが v4 で、結局は中途半端。
いやいや、ずっとずっと単純に Windows 側の TCP/IP 系の設定がおかしい?そして、TCP のパラメータを確認すると...
受信ウィンドウ自動チューニングレベルが、通常は、"normal" に設定されるようだけど、Surface だけが "experimental" になっている。なんじゃこりゃ?Surface は実験台か?
help を読むと、最も賢い設定のようにも見えなくはない。どうやら、受信ウィンドウをどんなシナリオにも最適にしてくれるらしい...

C:\> netsh int tcp show global

TCP グローバル パラメーター
----------------------------------------------
Receive-Side Scaling 状態             : enabled
Chimney オフロード状態                : disabled
受信ウィンドウ自動チューニング レベル : experimental
アドオン輻輳制御プロバイダー          : default
ECN 機能                              : disabled
RFC 1323 タイムスタンプ               : disabled
初期 RTO                              : 2000
Receive Segment Coalescing 状態       : enabled
非 Sack の Rtt 回復性                 : disabled
SYN の最大再送信数                    : 2
Fast Open                             : enabled
ペーシング プロファイル               : off
----------------------------------------------


C:\> netsh interface tcp set global ?

  ...
autotuninglevel - 次のいずれかの値を指定します:
  disabled         : 受信ウィンドウを既定値に固定します
  highlyrestricted : 受信ウィンドウの既定値を少しだけ超えて拡大できるようにします。
  restricted:      : いくつかのシナリオで制限されますが、受信ウィンドウの既定値を超えて拡大できるようにします。
  normal           : 受信ウィンドウをほとんどすべてのシナリオに合わせて拡大できるようにします。
  experimental     : 受信ウィンドウを極端なシナリオにも合わせて拡大できるようにします。
  ...

実験では、"normal" が一番速そうに感じるが、ウィンドウ幅を広げる方向にしたいので、"restricted" をしばらく試すことに。「いくつかのシナリオで制限されます...」とあるので、ちと気がかりだけど...
てなわけで、これで解消された!はぁぁ~...

C:\> netsh interface tcp set global autotuninglevel=restricted

そして今、すこぶる安定している。気持ち悪いほどに...
自動化宗教に懐疑的な酔いどれ天の邪鬼は、手動でルータに合わせこんでもいいと思っているぐらいだけど、あまり現実的ではなさそうだ。特にモバイル環境では...

0 コメント:

コメントを投稿