sub.png

FEZ TAF設定:Tcp Ack Frequency

TAFとは
「Tcp Ack Frequency」はWindowsの通信設定。略称では「TAF」と呼ばれている。
TcpAckFrequency は、未解決の TCP 受信確認 (ACK) 数がいくつになったら遅延 ACK タイマを無視するかを決定する
http://support.microsoft.com/kb/328890/ja

 XP以降のWindowsの設定だと思われるけどWindows7など新しいOSでも同じ名称の設定があるかは不明。追記:Windows7にも同様の設定があるそうです。この類の設定は機能しなかったりする例もあるので詳細はGoogle先生に聞いたほうが良い。

■FEZでの効果

追記:最近通信関係に修正がはいって変化があったようです。

 FEZ ノート: TAFの効果について
 http://fantasyearth.org/article/186602880.html

 いい方の効果としては通信のラグが多少改善する可能性がある。Windowsの「TAF」設定は既定で2。つまり場合によっては遅延 ACK タイマ (200 ミリ秒)の時間分設定で遅くなる。この遅延がなくなると多少ラグが減る可能性はある。悪いほうの効果としては、サーバの負荷は高くなるかも。この辺の関係でこれが推奨される設定なのかは不明。

 pingが300以上の人は通信速度がそれ程速くないのでそもそも負荷問題はないと思う。遅い人は試してみる価値のある設定だと思う。逆に回線が速い人は体感できるような効果はないかも。

その他賛否両論ありそうな辺り
 ・多分攻撃は当たりやすくなる(敵も自分も)
 ・低スペックPCの場合多分処理が増えて逆に遅くなる
 ・自分のラグは減っても相手のラグはそのまま
 ・ステップ持ち替えは難しくなる(伝聞)
 ・自分の攻撃の当たり判定が残りにくくなる?(伝聞)

■設定の方法
 レジストリの設定なのでフリーの環境設定ソフトから変更することが多いが、レジストリエディタで手動で設定することもできる。PCに詳しくない人は環境設定するフリーソフトは沢山あるのでソフトを使うと失敗が少ない。ただし、設定変更により問題が起きる可能性もあるので自己責任で使用してください。MSのページにある警告を一応ここに引用しておきます。
警告 : レジストリ エディタの使い方を誤ると、深刻な問題が発生することがあります。最悪の場合、オペレーティングシステムの再インストールが必要になることがあります。マイクロソフトは、レジストリエディタの誤用により発生した問題に関しては、一切責任を負わないものとします。レジストリ エディタは、自己の責任においてご使用ください。
http://support.microsoft.com/kb/328890/ja

FEZ ノート: 環境を整えるソフト
http://fantasyearth.org/article/119764341.html

■FEZ公式掲示板関連スレ
TcpAckFrequency
http://www.fezero.jp/com_talkview.aspx?seq=13045
TAFが効かない
http://www.fezero.jp/com_askview.aspx?seq=5424

■個人的な予測
 個人的な予測では多分pingの数値は変化すると思うが、実際のFEZの操作に凄く影響があるほど効果はないのではないかと思う。特に既にある程度以下のpingの人は。
 理由としては、ping等のような単体コマンドは"未解決のTCP受信確認 (ACK)"数が少なくACKタイマの影響を受けると思うが、FEZの通信のように常に敵味方の表示位置を通信している状態では通信が多くてタイマはすぐ無視されてしまうのではないかと。つまり、既定値の2だったとしてもラグが200ms増えるわけではなく、通常の通信環境ならping50位の増加にとどまるのではないか。だから、通信が遅い環境ではある程度効果が期待できるが、回線が一定速度以上だと多分元々ACKのタイマの影響を受ける前に無視して処理してそうなので誤差程度の差になる気がする。実質的には見た目上左下にあるping数値が下がるプラシーボ効果の影響では・・・。そもそもFEZは0.05秒の差を競うゲーム性はほとんどないと思う。

 追記:色々見ているとかなり別物の説明がTAFとしてされているページなどがあるようなの十分に注意してMSなどの元ソースのページを参照している所を見た方がいいです。色々なページで嘘情報が氾濫しているようなので注意。
このエントリーをはてなブックマークに追加
posted by fezノート
2009.11.25
| Comment(13) | TrackBack(0) | PC環境・設定
この記事へのコメント
インジは皿がメインで、この前からTAFを導入したんだけど、中級がバシバシ当たるようになったよ〜

皿は導入したほうがいいかもしれない…

でもレインが酷く痛くなる
Posted by インジ at 2009.11.25 07:34
7で導入可能でした。
持ち替えステップはかなりシビアになります。
Posted by mk at 2009.11.25 09:02
皿は導入したほうがいいかも。
導入前、後でスコアが一気に変わる。
オリは持ち替えが難しくなるため、導入するのは人それぞれ。純職なオリには関係ないかな。
Posted by arf at 2009.11.25 19:09
>インジさん
ステップなどの小さい硬直にジャベリンを当てる時なんかは比較的影響があるかもしれないですね。

>mkさん
情報提供ありがとうございます。追記しておきます。

>arfさん
持ち替えステップの入力時間が変化するという動画とか検証あったら情報を募集しております。
Posted by fezノート at 2009.11.25 21:47
ここを見ている人結構いると思うので、少し書かせてください。
このレジストリをいじるのは、インターネットを利用する際の通信の取り決めを無視する事になるので、おすすめできません。

ACKは送られたデータが正常に届いた事を相手に伝えるフラグで、TCP/IP通信は相手にデータを届けてそれが届いたら、次のデータを送る、できなかったらもっかい送るという機能が主な特徴であり、相手に届いたという確認にこのACKをつかっています。
それで、単純に相手からデータ受信したらすぐにACKを送れば最もてっとり早いのですが、普通の通信は双方向なので自分のデータ送信時にこのACKをついでに乗っけて送り、相手のデータが自分に届いた事を伝えると帯域の節約になるのでそのようにしています。これが tcpackfreq 2 のデフォルトの動作です。
だけど、tcpackfreqを0にすると、相手のデータを受信したタイミングで、(自分が送るデータがあったとしても)即ACKフラグのみのデータを返すようになります。余分に回線にデータが増えますし、送信処理が増えます。
フラグのみならデータ量はすくないし大して負荷にならないと考える人がいると思いますが、通信1回するのに様々な処理や余分なヘッダが必要になるので、コスト的には普通の通信1回分と変わんないと思っていいです。
なので、PCに余分な負荷がかかる事になるばかりか、相手サーバーも負荷がかかりますし、ルーターにも影響がでるでしょう。
Posted by ななし at 2010.09.14 20:12
>ななしさん

 具体的な取り決めは何処に書いてあるのか分からないので、知っていれば情報募集してます。
Posted by fezノート at 2010.09.15 13:13
取り決めについては、次の文書が参考になります。

・RFC1122日本語訳 --- 4.2.3.2 いつ ACK セグメントを送信するか
http://www2s.biglobe.ne.jp/~hig/tcpip/HostReq_Comm.html
※RFCはインターネットの標準化仕様です。仕様なので技術屋でないと辛いかも。

・Winsock Programmer's FAQ --- 3.20 遅延 ACK アルゴリズムとは何ですか?
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/intermediate.html#silly-window
※これは、WindowsのTCP/IPの実装について書いてあります。プログラマー以外が読んでも意味不明だと思います。

要約するとRFCではTCPは遅延ACKってのを実装すべきと定めていて、相手からデータを受け取ったら即座にACKを返さず、自分の送るデータにACKを乗っけるか、最大2MSL時間まで待ってACKを送りなさいといっています。
2MSLはpingの時間と置き換えてOKです。
そして、WindowsFAQよるとWindowsのTCP/IPではここの2MSL時間は固定で200ms待つように実装する事で実現しております。

TAFの設定をするとこの遅延ACKが無効になって、即座にACKを返してしまいます。

RFCはインターネット使うならこういう仕様にしなさいと定めてる文書で、違反しても罰はないけど多分いろいろ不味いです。
Posted by ななし at 2010.09.30 19:52
と、よく見直したら違反ではないですね。。
ただ、よく見れば推奨はされていない動作の筈です。

わたしとしては、FEZというバランスが命のゲームで、自分だけ有利になるために、無駄にサーバーに負荷を掛ける行為は他の人にも迷惑だろうし、それを人に広めるというのは非常に良くないと思っています。

過去に、1秒間に100回、ログインを繰り返すツールを広めた事でサーバーが落ちたゲームがあったもので。
ただ、既にサーバーのラグが酷い事に一時期なっていたので多少影響あったのかもしれません。人が減った分、サーバーに余裕ができれば大丈夫かもしれませんが。
Posted by ななし at 2010.09.30 20:07
 効率よくするためには一般的に推奨されていないという部分には同意です。FEZの場合TAFの変更が禁止なのか、運営がTAFに関して明言にしていないで何とも言えないと思います。

 少し認識が違う部分があるようなので書いておきますが、まずTAF設定したプレーヤーにとってメリットだけではなくデメリットもあります。全体としてみるとユーザー側にとってはラグが解消したり、当たり判定が表示に近づくので、比較的いい影響も多いと思います。
 心配なのは鯖の負荷が極端に増えるかどうかという当たりですが、どの程度影響があるのかわからないので何とも言えない部分です。その辺は運営次第なので、TAF以前に負荷に耐えてラグをなくす方向に頑張って欲しいですね
Posted by fezノート at 2010.10.01 13:04
 ちょっとだけ関係があると思うので追記しておきます。この話は半歩の仕様によく似ていて、ラグや情報の更新頻度にズレが少ない方がいいという意見に類似した所があるかと思います。恐らく半歩を修正したらTAFより遥かに負荷が増えるんじゃないかなと。
 個人的には情報にずれがなくなるのはいいと思いますが、バランスの問題があるので現状のスキル仕様で半歩の仕様をいきなり変更するのには反対です。かなりゲーム性が変化するのでしっかり調整しながらやらないと、酷い状態になってしまう可能性が高いと思っています。
Posted by fezノート at 2010.10.01 13:22
ゲームサーバーというのは、一定時間に処理可能な通信量が決まっていて、大体ピーク時合わせて処理可能な範囲で動いている筈です。(運営で一番コストがかかる所なので)
この処理能力を超えてしまうと、サーバーが応答を返さなくなり、全体が重くなったりします。
TCPACKFREQを設定すると挙動が変わるということは、サーバーの時間あたりの通信量が増えていると予測されます。
なので、主戦場などで複数の人がTCPACKFRQを設定していた場合、このピークを超えやすくなっていた可能性があります。
Posted by ななし at 2010.10.01 14:07
何年か前に、ルーター壊れた原因って、これだったりして・・・。
今は設定してないけど。
Posted by なす at 2012.07.01 19:00

今は設定してないですが、私は壊れた事はないですね。ルーターの種類にもよるかもしれませんが
Posted by fezノート at 2012.07.01 20:40
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック