約 3,176,504 件
https://w.atwiki.jp/goodgames/pages/707.html
KPM統計 その1 こちらも本当に「その1」とは考えにくいのですが、 過去の情報が見当たらなかったので。 集計対象サーバ 日本国内で稼動しているRankedサーバ ゲームモード Conquest/Rush/TDM/CQ/TankSuperiority 対象期間 対象期間 2013/02/10～2013/02/23(直近14日間) 付帯条件 該当期間内に2件以上の戦績があること (最近プレイされていない方と海外からの一見さんを除外するため) 尚、集計対象のKPMは上記14日間だけで記録されたものではなく、 直近14日以内に戦績が存在する方の最初からの通算KPMになります。 対象プレイヤー総数 106,168人 約半数の方はKPM0.6未満 約2/3の方はKPM0.7未満 約9割の方はKPM1.1未満 KPM 該当者数 占有率 累計占有率(下から) 0.0以上0.1未満 1,951 1.838% 1.838% 0.1以上0.2未満 4,638 4.369% 6.206% 0.2以上0.3未満 7,666 7.221% 13.427% 0.3以上0.4未満 10,366 9.764% 23.190% 0.4以上0.5未満 12,038 11.339% 34.529% 0.5以上0.6未満 12,816 12.071% 46.600% 0.6以上0.7未満 12,069 11.368% 57.968% 0.7以上0.8未満 10,673 10.053% 68.021% 0.8以上0.9未満 8,737 8.229% 76.250% 0.9以上1.0未満 6,799 6.404% 82.654% 1.0以上1.1未満 5,155 4.855% 87.510% 1.1以上1.2未満 3,732 3.515% 91.025% 1.2以上1.3未満 2,731 2.572% 93.597% 1.3以上1.4未満 1,887 1.777% 95.374% 1.4以上1.5未満 1,429 1.346% 96.720% 1.5以上1.6未満 941 0.886% 97.607% 1.6以上1.7未満 701 0.660% 98.267% 1.7以上1.8未満 511 0.481% 98.748% 1.8以上1.9未満 346 0.326% 99.074% 1.9以上2.0未満 232 0.219% 99.293% 2.0以上2.1未満 195 0.184% 99.476% 2.1以上2.2未満 152 0.143% 99.619% 2.2以上2.3未満 105 0.099% 99.718% 2.3以上2.4未満 64 0.060% 99.779% 2.4以上2.5未満 48 0.045% 99.824% 2.5以上2.6未満 38 0.036% 99.860% 2.6以上2.7未満 23 0.022% 99.881% 2.7以上2.8未満 24 0.023% 99.904% 2.8以上2.9未満 14 0.013% 99.917% 2.9以上3.0未満 18 0.017% 99.934% 3.0以上未満 70 0.066% 100.000% 超手抜きグラフ(横軸はKPM、縦軸は該当者数) ( - )
https://w.atwiki.jp/petfood/pages/26.html
アイムス・ジャパン株式会社 HP 〒163-1428 東京都新宿区西新宿3-20-2 東京オペラシティータワー28階 TEL.03-6736-5700 現在リコール対象の商品一覧 米アイムス社のリコール対象商品一覧 The amended code dates are 6312 through 7073 followed by the plant code 4197 (米アイムス社のサイトより引用) 工場番号4197 年月日番号 6312 から 7073 まで 製造番号の見方 （正規日本製品には安全宣言） 商品一覧 アイムス ユーカヌバ ニュース 戸田市内に全16邸の街並みが誕生『マインドスクェア戸田 アイムス』全邸土地面積100m2以上の2階建て、+αスペースのある「家」 - PR TIMES 倉敷ファッションフロンティア2021 「繊博(SEN-IEXPO)」、10月25日～11月5日に開催 - アットプレス（プレスリリース） 「BE-KIND(R)（ビーカインド(R)）」から2つの新フレーバーが登場 - PR TIMES シーバ(R)を買って応募すると720名に素敵な賞品が当たる「#シーバタイムキャンペーン」実施！ - アットプレス（プレスリリース） 「カルカン® 海を守り、猫ちゃんも元気に！」キャンペーン | マースジャパンリミテッド - デジタルPRプラットフォーム WEB CM/動画「プロマネージ（ＴＭ） ハイブリッドケア」篇公開 | マースジャパンリミテッド - デジタルPRプラットフォーム 「アイムス（ＴＭ）かプロマネージ（ＴＭ）を買って3人に1人必ず当たる*1！リサ・ラーソン（R）キャンペーン」 | マース ジャパン リミテッド - デジタルPRプラットフォーム 「アイムス（ＴＭ）」のドッグフード、キャットフードに新製品が登場！ | マース ジャパン リミテッド - デジタルPRプラットフォーム 「アイムス（ＴＭ）」のドッグフード、キャットフードが全面リニューアル！ | マース ジャパン リミテッド - デジタルPRプラットフォーム サイトログ 2007.4.10 米国・カナダでの (2007-04-16 11 51 45) 2007.4.9 アイムス・ユーカヌバ製品は… (2007-04-16 11 50 36) サイト名 URL 2chログ 2ch アイムス・ユーカヌバ
https://w.atwiki.jp/goodgames/pages/592.html
3号機の構成案募集中 当初より構成の定まらない3号機のお話。 通常はテスト用ですが特別なテストを行う必要の無い時期にどのような使い方をするか? 先日、一気に多数の老舗サーバが稼働終了(*1)となったことと関係があるようですが、 B2KなどDLCマップの導入を期待される意見をぽつぽつ耳にします。 また、2012/11/16には4号機(Armored Kill専用機)が稼働終了となりますが、 B2K所有者(多くはPremium所有者)であればArmored Killマップもプレイ可能と考えられるため、 これらを統合してしまうのも一案かと考えております。 どうせなら全部入りでConquestDominationもありかも。 次のDLC対応をどうするかが問題になりますが、 また期間限定で一台借りても良いかもしれません。 残りのDLCが2作となり、最終リリースまで残すところ4～5ヶ月となりました。 製品寿命はその先数ヶ月と考えるべきでしょう。 それまで安定的に使えるサーバとして当面はこの構成と言えるような構成を検討中です。 こちらより皆様の御意見をお待ちしております。 (*1) 伺ってはおりませんが、BF3リリースが1年が経過し、 1年契約だったサーバが契約期間満了となったのも原因のひとつだと思います。 ウチはいつでもやめられるよう、常に1ヶ月契約ですのでこのような事情はありえませんが。 (2013/01/20追記) マップ投票機能投入の準備開始に伴い、御意見受付を終了させて頂きます。 ( - )
https://w.atwiki.jp/goodgames/pages/204.html
BF3 R10 パッチリリース ようやく4ヶ月ほど続いた地獄のような忙しさも落ち着いてきました。 二週間ぶりの休日なので久しぶりにBFBC2でも... と思いきや、残念なことにサーバが激減してます。 一時期は70台近く稼動していたアジア圏のサーバ群が既に11台まで減っていました。 有料ですからやむを得ませんね。 一方、BF3の最新事情は良くわかっていませんが、 タイミングよく(?)本日(2011/11/26)新しいサーバ側のパッチ(R10)がリリースされたようです。 今回の修正内容は軽微なバグ修正にとどまるようですが、 久しぶりにRCON Protocol(ゲームサーバと鯖管端末の間で送受信される命令と通知情報の通信規約)について 最新の状況を調べてみました。 結論的には以前に調べた内容とほとんど変わっていませんがあらためてまとめてみましょう。 BFBC2とBF3のRCON Protocolを比較すると... ほぼ同じです。各種外部ツールは容易に移植できるでしょう。 ちなみにチームシャッフル系は多くの実装でそのまま稼動しそうです。 またチーム移動禁止機能は他に実装されたサーバを見たことはありませんが、 恐らくBFBC2と同じアプローチで実現できそうです。 BF3用RCON Protocolの良い点 多くの命令が「即時反映」になった。 BFBC2ではサーバの設定を変更しても次のラウンド開始まで 設定内容がゲームに反映されないものが多少ありました。 しかしBF3では多く(ほとんど?)が命令発行と同時に有効になります。 例えば「ビークル無し」などという設定がラウンド中に変更可能だったりします。 そもそもビークル有りマップを「ビークル無し」でまわしているサーバを見た記憶がありませんが... BF3用RCON Protocolの悪い点 「バグってます」とか「まだ実装されていません」など、 現状では使えないことを意味する記述がマニュアルに多々見受けられます。 BF3用RCON Protocolで無くなった機能 色々とあるかもしれませんが気づいたところだけ... ■RankLimiter BFBC2でもRankLimiterは最後までまともに実装されず、やむを得ずかなり大掛かりなものを自分で作りました。 Rank情報はゲームサーバから鯖管端末に一切送られてこないので、EAマスターサーバに照会しなければならず、 しかもマスターサーバはレスポンスが悪かったりエラーになったりで対応が色々と面倒でした。 というか... 私に出来ることをEA(DICE)さんはなぜ出来ないんでしょうか? (笑) そう言えば、BF3のRCON ProtocolにはRankLimiterに関する記述がありません。 BFBC2同様、NOOB様専用サーバを作るのが厄介ですね。 ■プレイヤーごとのPingが取得できない これは無くても良いのですがHighPingKickは作れません。 以前より何度か解説していますが、Frostbiteではクライアントとゲームサーバの通信は 非同期方式になっているためHighPingさんが他のプレイヤーに悪影響を与えることはありません。 従って、HighPingさんは自分が撃ち合いで損をするだけなので、基本的には無害ですからKickする必要は無いのです。 また自分のPingを知りたければサーバブラウザで確認すれば良いので問題ありませんね。 ■Kill発生時の3次元座標が取得できない 普通の鯖管さんには不要な情報でしょうが私的には非常に残念。 これがわかると射撃距離が計算できるため、チータ自動検出など色々と応用できます。 実際にBFBC2ではこの情報を元に色々な機能を追加していました。 その他 分隊の制御はBFBC2同様、必要十分な機能を持っているようですので、 ラウンド開始時に強制的に分隊に所属させるとか、分隊無所属禁止機能など色々と作れそうです。 でも相変わらずGS機は売り切れですね... と言うか日本ではこれ以上増やしたくないのかも。 儲からないでしょうしね。 ( - )
https://w.atwiki.jp/goodgames/pages/706.html
KDR統計 その1 本当に「その1」とは考えにくいのですが、 過去の情報が見当たらなかったので。 集計対象サーバ 日本国内で稼動しているRankedサーバ ゲームモード Conquest/Rush/TDM/CQ/TankSuperiority 対象期間 対象期間 2013/02/10～2013/02/23(直近14日間) 付帯条件 該当期間内に2件以上の戦績があること (最近プレイされていない方と海外からの一見さんを除外するため) 尚、集計対象のKDRは上記14日間だけで記録されたものではなく、 直近14日以内に戦績が存在する方の最初からの通算KDR(つまりBattleLogの左下に表記されているKDR)になります。 対象プレイヤー総数 106,168人 約半数の方はKDR0.8未満 約2/3の方はKDR1.0未満 約9割の方はKDR1.5未満 ちなみにKillよりDeathの方が多くなるのは、 被蘇生より自滅やBadLuckが多いことが原因です。 KDR 該当者数 占有率 累計占有率(下から) 0.0以上0.1未満 4,965 4.677% 4.677% 0.1以上0.2未満 1,269 1.195% 5.872% 0.2以上0.3未満 2,885 2.717% 8.589% 0.3以上0.4未満 5,240 4.936% 13.525% 0.4以上0.5未満 7,230 6.810% 20.335% 0.5以上0.6未満 9,451 8.902% 29.237% 0.6以上0.7未満 10,219 9.625% 38.862% 0.7以上0.8未満 10,361 9.759% 48.621% 0.8以上0.9未満 9,688 9.125% 57.746% 0.9以上1.0未満 8,659 8.156% 65.902% 1.0以上1.1未満 7,564 7.125% 73.027% 1.1以上1.2未満 6,130 5.774% 78.801% 1.2以上1.3未満 5,036 4.743% 83.544% 1.3以上1.4未満 3,835 3.612% 87.156% 1.4以上1.5未満 2,934 2.764% 89.920% 1.5以上1.6未満 2,219 2.090% 92.010% 1.6以上1.7未満 1,623 1.529% 93.539% 1.7以上1.8未満 1,331 1.254% 94.792% 1.8以上1.9未満 955 0.900% 95.692% 1.9以上2.0未満 784 0.738% 96.430% 2.0以上2.1未満 686 0.646% 97.076% 2.1以上2.2未満 566 0.533% 97.609% 2.2以上2.3未満 414 0.390% 97.999% 2.3以上2.4未満 309 0.291% 98.290% 2.4以上2.5未満 291 0.274% 98.565% 2.5以上2.6未満 233 0.219% 98.784% 2.6以上2.7未満 176 0.166% 98.950% 2.7以上2.8未満 134 0.126% 99.076% 2.8以上2.9未満 137 0.129% 99.205% 2.9以上3.0未満 110 0.104% 99.309% 3.0以上3.1未満 94 0.089% 99.397% 3.1以上3.2未満 88 0.083% 99.480% 3.2以上3.3未満 61 0.057% 99.538% 3.3以上3.4未満 55 0.052% 99.589% 3.4以上3.5未満 47 0.044% 99.634% 3.5以上3.6未満 37 0.035% 99.668% 3.6以上3.7未満 44 0.041% 99.710% 3.7以上3.8未満 25 0.024% 99.733% 3.8以上3.9未満 29 0.027% 99.761% 3.9以上4.0未満 28 0.026% 99.787% 4.0以上 226 0.213% 100.000% 超手抜きグラフ(横軸はKDR、縦軸は該当者数) ( - )
https://w.atwiki.jp/goodgames/pages/857.html
WifiとPingのお話 iPhone5の発表あたりでしょうか、いつのまにやらWifiなる単語が一気に一般化致しました。 LTEにテザリングを利用してタブレットを接続するケースや、 スマートフォンを自宅のAPにする形態などなど。 地球上どこへ言ってもIEEE802.11準拠の電波が飛び交っています。 ちなみに昔は無線Lanと呼んでいましたが... HighPing無害説 0の記述後、数件お問い合わせを頂きました。 前回の書き方があまりよろしくなかったのか、無線Lanに関する内容が多かったため、改めて無線LAN(Wifi)接続について書いてみたいと思います。 (頂きましたメールよりお問い合わせの趣旨を利用させて頂きました) Q.「無線LANは遅い」と聞くが、例えばPing10の有線LANとPing10の無線LANは同じ性能と考えてよいのか? A. 同じです 但し、Ping10で安定するかしないかの差があるはずです。 これだけじゃつまらないので下記の通り、もう少し詳細を記載致します。 さて参りましょう。 ■もう一度原則論 (有線/無線を問わず) ・理論値、実測ともに通信速度は問題にならない 少なくともBF3では1Mbpsの回線でも帯域を使い切ることはありません ・応答性能が重要 「よーいドン」の一歩目が重要。 超短距離(例えば1m)を何度も走るイメージ。トップスピードは無意味。 ・安定性重視 出来るだけ変動を少なく。極論すればPingは最大値で評価すべき。 「やや高めでも安定している方が安心」の図 ・最適値は0ms あくまでも理論値。0msはあり得ませんが短い方が良いのは事実。 前回の記事で、1Sec / 60FPS = 16.666ms を連発したためか、 16.666ms未満なら全員平等と思われた方が多かったようですので、この点については近日中に再度解説致します。 ■実測しました いつも通りの超手抜きグラフ ゲームに使っている環境ではありませんが、参考までに自宅で30分間連続測定してみました。 802.11nを使用しAPまでの距離は約5mで途中に障害物の無い環境で測定しています。 自分で見てびっくり。 大凡3分周期で異常にPingが悪化しています... AP設定を確認して納得。 セキュリティ設定により一定周期で暗号化用の内部キー(セキュリティトークン)を変更しているため、回線が瞬断しています。 概ね3分周期で数秒間、Pingが350弱まで悪化していました。 試していませんが、これは確実に体感出来ます。 心当たりのある方は確認されることをお勧め致します 皆さんも測定してみましょう コマンドプロンプトを起動し下記のコマンドを実行してみて下さい。 但し、IPアドレスについては接続中のAPに割り当てられたIPアドレスに適宜変更して下さい。 今回の測定目的はあくまでも無線LAN部分のPingを測定することですのでPCからAPまでの時間を測定します。 そのためpingの送信先IPアドレスは接続先APになります。 "1800"とは1秒周期で1800回測定することを指示するパラメータですが、もっと長くしても良いかもしれません。 例えばゴールデンタイムがまるまる収まるよう、21時に測定を開始し、10800を指定すると3時間になりますので24時まで測定されます。 出来るだけ実際にプレイする時間帯に測定する事をお勧め致します。 C \ ping 192.168.20.254 -n 1800 ping.txt 測定が完了するとコマンドプロンプトに戻って来ますので、ping.txtをメモ帳などのテキストエディタで開いてみましょう。 192.168.20.254 に ping を送信しています 32 バイトのデータ 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =5ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =2ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =8ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =13ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =15ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =11ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =10ms TTL=255 要求がタイムアウトしました。 192.168.20.254 からの応答 バイト数 =32 時間 =22ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =15ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =5ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =4ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 (中略) 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 からの応答 バイト数 =32 時間 =1ms TTL=255 192.168.20.254 の ping 統計 パケット数 送信 = 1800、受信 = 1799、損失 = 1 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒) 最小 = 1ms、最大 = 133ms、平均 = 5ms これはあくまでも参考用に作った試験結果ですが 要求がタイムアウトしました。が一回でも出るなら環境構成の変更を検討する価値がありそうです。 試験期間内に1秒間以上、通信が途絶えた時間帯があることを意味します。 WebBrowserでそこらのHPを見ている時なら1秒通信出来なくても困ることは無いでしょう。 しかし、リアルタイムで戦闘を行うゲームで1秒は致命的です。 善し悪しの基準ですが、PCからAPまでですのでほとんどの環境にて最速は1msになるはずです。 従って最大値がポイントになりますが、15ms以内が一つの目安でしょうか。 また長時間に渡り測定結果が安定していることが望ましいと言えます。 無線LANのPingが安定しない原因 ・近隣で利用されている無線Lanの電波との干渉 冒頭で述べました通り、猫も杓子もWifiのこの時代、どこへ逃げても電波は追ってきます。 しかも高性能APのおかげで強固な壁も貫通して電波が飛び交っています。 もちろん家庭内の壁だけでなく、外壁をも貫通しますので 近所の家で稼働しているAPや端末からの電波も皆さんの家の中まで飛んできます。 広く普及しているIEEE802.11b/g(2.4GHz帯)の場合、 同一チャネルやチャネルの番号差が5ch分無いと 電波干渉が発生し応答性能の劣化や回線断が発生する恐れがあります。 「近所と違う番号ならOK」と考えている方が多そうですが、近いチャネルなだけでも電波干渉は発生します。 この辺りの話は様々なサイトで語られているので一度覗いてみることをお勧め致します。 ちなみに下記「電子レンジ」の話と重複しますが5GHz帯の電波を利用する、 IEEE802.11aを使うとこの問題は大きく改善してしまいます。 ・電波強度境界付近での利用 大昔から使われているIEEE802.11bから実装されていた技術の一つに 「もっとも効率の良い速度に自動で変更する機能」があります。 (この機能の名前を失念致しましたが) 無線LANはユーザからは見えない(いちいち見せない)レイヤーで常に通信エラーが発生しています。 広帯域(高速度)で通信するほどエラー発生率が高くなり、 エラーが発生すれば再度送信する必要があるため、 エラー発生率の高い高速度より、エラー発生率の低い低速度の方が効率がよいことが多いためです。 そのため無線LANでは多くのディフォルト設定にて、 エラー発生率により自動で通信速度を切り替える機能が有効になっています。 自宅以外のある環境で取得したScreenShot 1分50秒後には通信速度が自動的に切り替わっています。 ちなみに私にはアインシュタインなどとおしゃれな名前を付けるセンスはありません。 この通信速度が切り替わる瞬間も上記「セキュリティトークンの切替」と同様に 一瞬の回線断が発生するため、そのタイミングのPingは悪化してしまいます。 またいくつかのパケットが消滅(パケットロス)してしまうことも十分に考えられます。 従って、ゲーム用と割り切って考えるなら最初から低速度に固定してしまうのがお勧めです。 大きなファイルのダウンロードを行う場合などには若干の差は出るかもしれませんが、 自動で設定された速度より1ランク遅くする程度ならほとんど実効速度に差が出ないことも多いようです。 ちなみに本件の根本的な対策は「APの側でPCを使用する」ことになります。 と言ってもAPの目の前に置いても下記「電子レンジ問題」などは解決しないこともありますが... ・電子レンジ 無線LAN最大の敵、電子レンジ。 いいえ、冗談ではなく超強力な電磁ノイズの発生源です。 電子レンジが発する電磁波は水の共振周波数に一致しています。(ウソ) これについては、学校で習った方も多いと思いますが先生も良くウソを教えます。 電子レンジは水分(水蒸気)が超高周波で振動することによって発熱する原理を利用していることは事実ですが、 こんなこの程度の周波数では共振しません。本当に共振を起こすためには桁違いの超高周波が必要です。 脱線しました。 共振を起こすほどの周波数を作り出すことは極めて困難なため、 共振周波数には達しなくとも高効率で水分子を振動させれる周波数を偉い人が探しました。 その結果が2.45Ghz。 上で軽く触れましたが、IEEE802.11b/gの周波数帯域に直撃します。 理論的には7ch～12chまでは直撃します。 「直撃と言っても電子レンジは近くに置いて無いし」などと言わないで下さい。 無線LANの電波出力はわずか0.1mwですが電子レンジの出力は1,000w超が当たり前。 つまり10,000倍にも達します。 対策は... 少なくともゲームをプレイ中は電子レンジを使わない →これは無理がある。隣家の電子レンジからも電波は飛んできます。 直撃を回避出来るチャネルを利用する →完全に回避するのは困難とも言われているようですが効果はあるはず ・5GHz帯(IEEE802.11a)に切り替える →はい。これが特効薬です。 元々無線LANは802.11bから普及が始まりましたが、この周波数が2.4GHzでした。 そのため802.11gでも2.4GHzが利用されたことにより、 5GHz帯を利用する802.11aは異端児と受け止められることも多いようですが、 各チャネルが利用する周波数帯域のオーパラップが無いことなどから、 非常に干渉に強く、また現時点では利用者も少ないため狙い目と言われています。 但し、高周波になるほど直進性が高まり、壁などを越えることが困難になるため、 APまでの距離が遠い場合や多くの壁やドアを超える必要がある場合には向かないかもしれません。 (参考サイト。いくらでもあるでしょうが...) 電子レンジ利用中に無線LANの接続ができなくなったり遅くなったりする問題の解決方法 電子レンジのノイズで無線LANが遅くなる!? (電子レンジの上にノートPCを置いて実験) 尚、2.4GHz帯を利用している無線機器は他にも多数存在しており、 近年急激に普及しているBluetoothも2.4GHz帯を利用しているため、 電波干渉の原因となります。 やっと結論 とにかく前述のping aaa.bbb.ccc.dddを長時間実行し、 常に15ms程度に収まっていれば問題なしと判断しましょう。 たまにこの範囲から逸脱してしまう(Pingが悪化する)ようなケースでは、 周期性の有無や特定の時間帯に集中しているか否かなどを調査すれば、 解決策が見えてくるはずです。 Laggyな時間帯ではないのにLagを感じる場合、無線LANを利用しているなら疑ってみる価値はあると思います。 ( - )
https://w.atwiki.jp/goodgames/pages/294.html
番犬 GS機を使用されている鯖管さんはGSのサイトにWatchDog(番犬)なる機能があるのを御存知だと思います。 これは本来ハードウェアに搭載される機能ですが、 何らかのトラブルにより機器がハングアップしたような場合に、 自動で障害を検知し再起動するための機能です。 あくまでも装置本体に再起動信号を送信するだけですので、 故障してしまった場合などにはなんら効果がありませんが、 些細なことが原因でフリーズ状態に陥った場合などには有効な機能です。 ちなみに最近のモデルについてはわかりませんが、 昔はIntelのCPUにもこのWatchDog(正確にはWatchDogTimer)が搭載されており、 CPUの演算回路など主要部が正常に稼動していないと判断されると、 自動的にリセット信号を送信し再起動を試みる機能が搭載とされていました。 PCがフリーズした後、勝手に再起動が始まることがありますが、 もしかすると前述の機能がハード的に実装されているのかもしれません。 どうでもいい話が長くなりました。 さて本題。 以前にもこちらに記載いたしましたが、 その後もGS機で全プレイヤーが切断される現象は続いています。 正確に申し上げるとプレイヤーが切断されたと言うよりは、 ゲームサーバとEAマスターサーバ間の接続が切断されているようです。 ゲームサーバ自体は何らトラブル無く稼動しているのですが、 マスターサーバに接続出来なければあらゆる情報が連携出来なくなります。 この不具合でゲームサーバが稼動しなくなった場合、 前述のWatchDog機能を有効にしていれば自律復帰出来るサーバも多かったでしょうが、 実際にはゲームサーバが生きているためWatchDogが作動することはありません。 本日だけでウチのサーバは6回ほどこの不具合の影響を受けていますが、 幸いにもプレイヤーさんから連絡を頂いたおかげで職場から再起動することにより復旧しました。 しかし、国内サーバ稼働状況のログを見ると、 日中に155台前後の稼動が記録されていますが、01 39現在、139台となっています。 この復旧出来なかったノードのエンドポイント情報(IPアドレスなど)を調べ、 ゲームポート及び管理ポートに対しTCPセッション接続のリクエストを送出すると、 何事も無かったかのように接続出来てしまいます。 (もちろん、この後で認証がありますのでこの先には進めませんが) つまり、間違いなくゲームサーバは稼動しているにも関わらず、 マスターサーバとの接続が回復しないため見えない状態のままになっているサーバが、 数時間が経過した現在でも15台程度存在することになります。 しかもこの現象はほぼ毎日発生しています。 大変残念ながら本格的にGSが本来の姿に戻りつつあります。 最近はモノ作りに関する問い合わせが増えているため 参考までに番犬の作り方を簡単に記述いたします。 この現象に対応した「最低限」の番犬を作るのは比較的容易です。 趣味の範疇であっても、ちょっとしたシステム開発経験をお持ちの方であれば半日作業だと思います。 但し、この種の機能は誤判定のリスクがあるため、 何重にも不具合事象発生のチェックを行う必要があるでしょう。 1.プレイヤー数が急激に減少しゼロになった(元からゼロだった場合には、本項は無視) 2.EAマスターサーバに該当ゲームサーバが登録されていない(BattleLogの検索でヒットしない) 本項については一定時間の間隔をおいて、複数回のチェックを行う必要があるでしょう。 3.ゲームポート(and/or)管理ポートへの接続は可能 これらの条件を満たしている場合に、 GSの管理画面へhttpsで接続し再起動指示のパラメータ(たぶんPOST)を送信するだけで完了です。 その後、再起動完了と正常な状態へ復帰したことを確認するため、 上記2.と3.についてチェックすれば完了です。 ( - )
https://w.atwiki.jp/goodgames/pages/1042.html
管理者さん向けおいしい話 4 いつも通りですが、すっかり忘れてました。(苦笑) 前回と前々回に予告致しました、管理用仮想サーバ提供の件。 何しろ自分がゲームサーバを持っていないものですが、思いっきり忘れてました。 すみません。 何の話か良くわからない方のためにもう一度。 サーバ設定の変更を行うときや自動運転用のプラグインなどを実行するために、 Proconを使用されている管理者の方が多いと思います。 これはProconに限った話ではありませんが、 ゲームサーバを自動制御するためには24時間稼働のPCが必要になります。 余っているPCがあればそれを使えば性能的には充分でしょう。 でも電気代がもったいない。 ゲームに使っているPCを兼用することも可能ですが、 PCまるごとフリーズしてしまった場合、 再起動が完了するまでサーバは制御不能な状態に陥ります。 そのため2台目のPCを用意したいところです。 そこで以前にAWSの1年間無料使用権を御紹介致しました。 この制度を使うと、1年間無料で遠隔地(東京都内)にあるWindowsServerを一台無料で借りられます。 そのサーバにてProconを稼働させれば2台目のPCも余計な電気代も無料です。 ちなみに借りたサーバはWindowsに標準添付される「リモートデスクトップ接続」機能で操作出来ます。 (もしかするとWindowsのエディションによっては標準添付されていないかもしれません) この方法を御紹介した後、TeamControler用の戦績データ配信サーバに対し、 AWSからのアクセスが急増したため、やはりPCを連続稼働させるのは それなりに厄介な話らしいと感じたところです。 なかなか面白い使い方として、スマートフォン用のリモートデスクトップ接続アプリを使うと、 外出先からそのマシンが制御出来るので「チーターが大暴れしています」と急に連絡が来ても安心。 (常に即応出来るとは限りませんが) ※あまり本格的に使うと無料枠を超過する負荷が生ずるケースもあると伺いましたので御注意を。 さて、便利なAWSですが無料なのは1年限定です。 その後は一番安価なインスタンス(仮想サーバ)でも毎月2,000円程度の費用が発生致します。 と言うわけでウチの余っている暖房器具を活用して頂こうと考えたのが今回の企画。 前述のAWSの1年間無料インスタンスより少しだけ高性能な仮想サーバを無償で提供致します。 但し、基本的にはAWSの環境と殆ど変わりませんので、まずはAWSを試してみることをお勧め致します。 細かい話は後日検討しますが... ■前提条件 1.日本人が接続可能なBattlefieldシリーズのサーバを稼働させている方 2.日本語または英語でコミュニケーション可能な方 これだけ。 第1次募集は2013/11/24(日) 00 00締め切り 応募人数が4名未満の場合は恐縮ながら提供を中止させて頂きます。 また対応困難な程の人数になった場合には、 一部の方に御提供出来ない事が考えられますので予め御了承願います。 御希望の方はこちらより御連絡下さい。 ( - )
https://w.atwiki.jp/goodgames/pages/1238.html
KDDIでTitanfallな方々へ 複数の方々よりメールによる御連絡を頂きましたが、まとめてこちらに返信させて頂きます。 さらに御不明な点がございましたら、別途メールにて御連絡を頂いても結構です。 またか KDDIルーティング障害の続編になりますが、今回はTitanfallで問題が発生しているそうです。 複数の方から御連絡を頂いており、全ての方がKDDI系キャリアの回線を御利用との事ですので間違いないでしょう。 上記リンク先のケースでは一度ヨーロッパ経由になった後、暫くして北米経由に変更されましたが、 今回のケースでは北米または近隣諸国を経由している模様です。 国内サーバのIPアドレスについて Titanfallの国内サーバは全てWindowsAzureにて稼働している様ですが、 国内データセンタで使用されているIPアドレス範囲に関する情報は 下記リンク先より入手可能です。 (外部リンク)Windows Azure Datacenter IP Ranges XMLでごっそり入手出来ますが、そんなものは欲しくないと仰る方もいらっしゃるでしょうから結論を下に。 ■東日本データセンタ 138.91.0.1～138.91.15.254 (第1候補) 23.98.57.* (第2候補) ■西日本データセンタ 138.91.16.1～138.91.31.254 (第1候補) 23.98.56.* (第2候補) ※恐らく全て第1候補のIPアドレス範囲で稼働しています 接続先確認方法 色々とツールは出回っているようですが、 実際にゲームをプレイしている最中に接続されているIPアドレスを調査し、 目的のIPアドレスを確認して下さい。 ■IPアドレスについて 例えば、東日本データセンタを選択している場合であれば、 138.91.12.34などが接続先として検出されるはずです。 ■プロトコルについて プロトコルは恐らくUDPになります。 (Titanfallは見たこともありませんが、この種のゲームではTCPではなくUDPが用いられます) ■接続元プロセス名について 接続元プロセス名は取得出来ないと思います。 これはクライアントモジュールの実装方式に依存するため、 見たことも無いものについて明確な予想は出来ませんが つまり、プロセス名が取得出来ない状態で 上記IPアドレス範囲に対しUDPで接続している可能性が高いと考えられます。 ルーティング状態確認方法 Windows標準コマンドのtracertで取得したIPアドレスまでのルートを取得します。 (例) C \Temp tracert 138.91.12.34 どこかのHopで応答時間が跳ね上がるのでそこから海外と考えて良いでしょう。 トレース結果をプロバイダへ送付すると善処してくれるはずです。 ちなみに WindowsAzureのセキュリティポリシーによるものだと思いますが、 各ゲームサーバはICMPパケットを受け付けないらしくpingに応答しません。 そこで下記のアドレスへping送信してみましょう。 C \Temp ping 207.46.64.177 207.46.64.177 に ping を送信しています 32 バイトのデータ 207.46.64.177 からの応答 バイト数 =32 時間 =3ms TTL=57 207.46.64.177 からの応答 バイト数 =32 時間 =3ms TTL=57 207.46.64.177 からの応答 バイト数 =32 時間 =3ms TTL=57 207.46.64.177 からの応答 バイト数 =32 時間 =3ms TTL=57 207.46.64.177 の ping 統計 パケット数 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒) 最小 = 3ms、最大 = 3ms、平均 = 3ms このアドレスはMicrosoft(WindowsAzure)国内ファシリティで用いられており、 通常であれば良好な応答結果が得られるはずです。 もし、残念な結果であれば、何らかの回線障害と断定して良いでしょう。 手抜き ping 207.46.64.177の結果が残念な状況であれば、 tracert 207.46.64.177も同様になりますので、 その結果をプロバイダへ送付するのが最も簡単だと思います。 御不明な点がございましたらお問い合わせ下さい。 ( - )
https://w.atwiki.jp/goodgames/pages/710.html
SPM統計 その4 今回最後の統計情報。 集計対象サーバ 日本国内で稼動しているRankedサーバ ゲームモード Conquest/Rush/TDM/CQ/TankSuperiority 対象期間 対象期間 2013/02/10～2013/02/23(直近14日間) 付帯条件 該当期間内に2件以上の戦績があること (最近プレイされていない方と海外からの一見さんを除外するため) 尚、集計対象のSPMは上記14日間だけで記録されたものではなく、 直近14日以内に戦績が存在する方の最初からの通算SPMになります。 また、スコアリセットの影響を受けない集計方法を用いています。 対象プレイヤー総数 106,288人 約半数の方はSPM300未満 約2/3の方はSPM360未満 約9割の方はSPM540未満 Quit率 該当者数 占有率 累計占有率(下から) 0以上20未満 66 0.062% 0.062% 20以上40未満 178 0.167% 0.230% 40以上60未満 619 0.582% 0.812% 60以上80未満 1,144 1.076% 1.888% 80以上100未満 1,913 1.800% 3.688% 100以上120未満 2,598 2.444% 6.132% 120以上140未満 3,266 3.073% 9.205% 140以上160未満 3,846 3.618% 12.824% 160以上180未満 4,481 4.216% 17.040% 180以上200未満 4,880 4.591% 21.631% 200以上220未満 5,026 4.729% 26.360% 220以上240未満 5,275 4.963% 31.322% 240以上260未満 5,381 5.063% 36.385% 260以上280未満 5,485 5.161% 41.546% 280以上300未満 5,478 5.154% 46.700% 300以上320未満 5,587 5.256% 51.956% 320以上340未満 5,209 4.901% 56.857% 340以上360未満 5,127 4.824% 61.681% 360以上380未満 4,630 4.356% 66.037% 380以上400未満 4,359 4.101% 70.138% 400以上420未満 3,984 3.748% 73.886% 420以上440未満 3,498 3.291% 77.177% 440以上460未満 3,101 2.918% 80.095% 460以上480未満 2,935 2.761% 82.856% 480以上500未満 2,391 2.250% 85.106% 500以上520未満 2,136 2.010% 87.115% 520以上540未満 1,923 1.809% 88.924% 540以上560未満 1,667 1.568% 90.493% 560以上580未満 1,460 1.374% 91.866% 580以上600未満 1,205 1.134% 93.000% 600以上620未満 1,081 1.017% 94.017% 620以上640未満 885 0.833% 94.850% 640以上660未満 802 0.755% 95.604% 660以上680未満 649 0.611% 96.215% 680以上700未満 527 0.496% 96.711% 700以上720未満 483 0.454% 97.165% 720以上740未満 424 0.399% 97.564% 740以上760未満 347 0.326% 97.891% 760以上780未満 295 0.278% 98.168% 780以上800未満 278 0.262% 98.430% 800以上820未満 217 0.204% 98.634% 820以上840未満 193 0.182% 98.815% 840以上860未満 169 0.159% 98.974% 860以上880未満 118 0.111% 99.086% 880以上900未満 112 0.105% 99.191% 900以上920未満 136 0.128% 99.319% 920以上940未満 80 0.075% 99.394% 940以上960未満 81 0.076% 99.470% 960以上980未満 67 0.063% 99.533% 980以上1000未満 69 0.065% 99.598% 1000以上1020未満 56 0.053% 99.651% 1020以上1040未満 44 0.041% 99.692% 1040以上1060未満 27 0.025% 99.718% 1060以上1080未満 29 0.027% 99.745% 1080以上1100未満 26 0.024% 99.769% 1100以上1120未満 23 0.022% 99.791% 1120以上1140未満 23 0.022% 99.813% 1140以上1160未満 20 0.019% 99.832% 1160以上1180未満 18 0.017% 99.849% 1180以上1200未満 11 0.010% 99.859% 1200以上 150 0.141% 100.000% 超手抜きグラフ(横軸はSPM、縦軸は該当者数) ( - )