eスポーツ、FPS、MOBA、ゲーミングデバイスの最新情報を紹介する個人ニュースサイト

サーバー側のネットワーク設定

sv_maxupdaterate

クライアントがサーバーにデータを要求する頻度の制限。
単位はms、デフォルトでは60となっている。
クライアントのcl_updaterateがこれより高い場合、
sv_maxupdaterateの値が適用される。

sv_minupdaterate

クライアントがサーバーにデータを要求する頻度の制限。
単位はms、デフォルトでは10となっている。
クライアントのcl_updaterateがこれより低い場合、
sv_minupdaterateの値が適用される。
回線に余裕があるなら、20以上にしてもいいだろう。

sv_maxrate

クライアントのrateの制限。
単位はByte/s、デフォルトでは0となっている。

クライアントのrateがこれより高い場合、
sv_maxrateの値が適用される。
サーバーの回線速度に合わせて調節する。
試しに1000程度に設定するとものすごいカクカクしたゲームになる。

0の場合、制限されない。またsv_lan 1の場合も制限されない。
回線速度(bps) > maxplayers *
sv_maxrate * 8

最低でもこの式が成り立たつぐらいに調節したい。
ラグを感じさせない快適なゲームをするなら、 最低6000ぐらいは欲しい。

sv_minrate

クライアントのrateの制限。
単位はByte/s、デフォルトでは0となっている。

クライアントのrateがこれより低い場合、
sv_minrateの値が適用される。

サーバーの回線が太くてもクライアントのrateの設定が低ければ、
そのrateの範囲内でしか通信ができない。
よってサーバー側でsv_minrateを設定して
クライアントのrateを設定してあげる必要がある。

例えば、クライアントがrate 1000に設定していても、
sv_minrate 6000のサーバーに入ると 自動的にrate
6000
で通信が行われる。
実際に速度が確保できない場合は試せないので不明。 0の場合、制限されない。
またsv_lan 1の場合はクライアントの
rate自体が無視される。

sys_ticrate

サーバーのfpsの最大値。デフォルトは100。
通信はクライアント、サーバーのfpsにも基づいているので、

これが低いとかなりクライアントのLatencyが高くなる。
試しにsys_ticrate 20にしてみれば、
かなりLatencyが高くなることがわかる。
100以上ならより正確で、Latencyも低くなる。
Win32版で試したところP4 2Gでだれもジョインしてない状態で500fps程度でた。
Win32、Linux版で共通する問題で、
サーバーの性能が高くても50fps程度しかでないという問題がある。
Metamod PluginのHL-Boosterや、 Linux版なら標準の
pingboostというオプションを使ってfpsを上げる必要がある。

これらは単に無駄な処理をいれて、CPUをアイドリングさせないようにしているだけだと思われる。
よってリアルタイムにCPUを使うプログラムを動かしていても fpsは下がらないようだ。

host_speeds

Linux用のHLDSではWin32用のHLDSのようにサーバーのfpsを見ることができない。
しかしhost_speeds 1とすることでfpsを見ることができる。

毎フレームごとに1行表示するのでものすごい勢いでログが流れていくので注意。
host_speeds 0で消すことができる。

pingboost

サーバーの性能が高くてもHLDSのfpsはOS側で抑えられていて、実際には50fps程度しかでていない。
Linux用のHLDSでは起動時の引数に

  • -pingboost 1
  • -pingboost 2
  • -pingboost 3

    のどれかをつけることでサーバー側のfpsが上げることができる。
    これを使うことでほぼ100fpsで安定し、10msほどLatencyを下げることができる。
    1、2、3はそれぞれ違う方法をとっている。hlds_linux Mailing ListにあったPingboostの説明を
    訳してみた。

    <

    blockquote>
    Mode “1”はwait(select()関数)を用いて、10msecほどLatencyが減らせる。
    Mode “2”は同じようにalarm()関数を用いて、10msecほどLatencyが減らせる。
    のモードはサーバーをハングさせる可能性がある。
    Mode “3”はPacketが届くたびすべてのフレームを処理することで、最小のLatencyにすることができる。
    Latencyは最小にすることができるが、極度にCPUを占有する。

    このモードは自己責任で使用するべきで、CPUを使い切ってしまう恐れがある。
    このモードを使ってcstrikeがCPUを占有しすぎても、文句を言わないで欲しい。
    将来的にこのモードは、管理者がCPUの占有率を設定できるようにするつもりだ。
    UDPSoftのpingboosterと呼ばれる外部モジュールがある。
    pingboosterはMode “3”に似た機能を実装している。
    これは古いHLのバージョン(1108)のために作られたもので、 もはや動作しないだろう。
    また将来的にも偶然に、動作しなくなるかもしれない。

    現在ではMode “2”は修正されている模様。
    Mode “3”もそれほどCPUを使うことはなかったので、
    もしかすると修正されているのかもしれない。

  • Yossy
    Writer
    Negitaku.org 運営者(2002年より)。CS:GO、Dota 2が大好きです。 ラーメン、ランニング(60km完走)、カメラが趣味です。 じゃがいも、誤字脱字を見つけるのが苦手です。

    https://twitter.com/YossyFPS/
    YouTube

    取材動画、ポッドキャスト等配信中。チャンネル登録をお願いします!