決して方向性は･･･

･･･悪くない、対策を講じようとする姿勢は評価すべきだろう。


･･･が しかし、

★ コレを実施するには、前提が伴ってないよな?

■ まず最優先は、

★ nPRO排除を含めた、PSO2側が原因の630が発生しないだけのプログラムに仕立てるコト。

■ 次いで、以下過去ログのように、

■ 相も変わらず･･･ 
■ 新規プレイヤー･･･
　･･･適正なフィルタを実装した後でなければならない話だろ? どう考えても。


■ しかもコレ、

★ 診ようによっては、何の仕様変更にも なってないんだが?


◆ 前者は ともかく後者がな、

元々 630 や nPROによる意図的なWindowsへの不正なメモリアクセスによるクライアントクラッシュでは、
再度ログインした時点で、どのブロックに飛ばされるか判ったモノではナイのだ。
不意であっても、開発側の問題であっても、罰を受けているに等しい状況が 永らく続いている。

◆ 今回のコレは、

意図的に離脱した者を、ソレと同じ憂き目に遭わせたいだけの話だ。
その点だけ診れば、別段それ自体悪いとは云わないのだが、もはや "なんだかなぁ" な域である。

◆ 確かに

LANケーブル抜きなど姑息な真似をする向きが現れるのは、想像に難くはない。

しかし 混雑時間なら、元居たブロックには 得てして戻れはしないのだ。
その時点で既に、仕様変更の 2項目には該当し、代償は払っている とも云える。

ナニせ現状では、離脱操作さえすれば、居るブロックのロビーに戻れているのだからねぇ。
それに比べたら結構なペナルティであり、それなりに避けたいデメリットだと思うのだがね?


◆ であるなら、

明示的に操作で離脱した者 "以外"まで対象にすると云うのは、如何なモノか?

そもそもコレで、運営自信が負う結果は、考えている以上に大きなマイナスになるであろうと云う点、
正しく理解しているのかな? ･･･縦しんば その覚悟があると云うのであったとしても、残念ながら
あの様な雑い愚策では、そのリスクに見合った結果は 十中八九得られないと警鐘しておくかな、無駄だろうケド。


◆ しかも、

ナンてコト宣ってるが、残念品質の運営の事、緊急以外のクエストにも同じ処理カマすボケも期待出来る。

★ ナイス自爆テロになる未来しか見えない。

64bitビルドの･･･

･･･アプリケーションやデバイスドライバは不安定という風評。


★ それを真っ向否定して当ログを進める事とする。

◆ そもそも 何故そのようなブラフが広まったか?

■ それは過去、

各ハードウェアメーカーの 64bitビルドデバイスドライバ(以後 ドライバ)開発水準の低さがあったコトに起因している。
確かに 64bitプロセッサと 64bitOS登場当初は、どのメーカーも手探りであり、致し方の無かったのも事実だ。

■ 増してや

昨今の様に、手軽に安定的なアプリケーション／ドライバを 64bitビルド可能な開発環境も、
提供されていなかったのだ、Microsoft側の落ち度とも云えるコレも、素因として 小さくはナイ。


◆ しかし、風評に至るほど 顧客に "不安定" と感じさせた要因となると、1つだ。

それはディスプレイドライバ･･･

名指しするなら nVIDIA がトクに規模が大きな諸悪の根源と云ってイイ。

★ 何故そう云い切れるか?

◆ まず対していた AMD は、2013年8月の版より、統合ドライバが基本安定稼働となった。

Intel プラットフォームを採用したマシンは知らないが、
少なくとも おきつね機材では、極めて安定稼働し続けている実績がある。

◆ だが nVIDIAに至っては、

ディスプレイドライバ単体であったにも関わらず、極最近まで不安定要素が残ったままだった。

★ コレは、VisualStudio2010 以降の Microsoft 提供開発環境に対する習熟度が生んだ差だ。

★ また、AMD は Microsoft の提示する、Windows の仕様に準じた。

機能拡張も Microsoft に対して対等に提案するスタイルで協業してきている。

★ ･･･が、nVIDIA は、相変わらず我が道を行く好き勝手な拡張を繰り返している。

自らの製品のピーク性能だけを追う開発スタイルは、
顧客に不安定要素しか提供しないと云う事実を無視し続けているのだ。

★ コレは Intel も同様だ。




■ ところがココで、

◆ 巷に転がってる販売母数を思い返してほしい･･･

云わずもか、悲しいかな nVIDIAのほうが、安物機種だろうが高額機種だろうが 数は出てる。

◆ さて前の話に戻ろう。

不安定要素を抱えたままのベンダ製品のほうが数が出たと云う事実。
そしてそれは、64bitビルドのドライバが最低限の安定性を獲得するまでに、AMDよりも時間が掛かった･･･

★ そう、これこそが 64bitビルド不安定説を定着させるに足る要因だったと考えて、支障は無いだろう。


★ しかし、

◆ 前ログでも過去ログでも散々述べているように、

1時間以上連続長時間稼働させるアプリケーションにとって、時間を扱う処理での32bitの壁は、
考えている以上に大きい事を、そろそろ自覚して欲しいモノだ、アプリケーション開発関係者諸兄。

★ 64bitビルドは、

ステータスでも飾りでも無い、もはや実用として必須である と考えを改めろ。
このままでは、開発水準までガラパゴとなり、国際標準より遥か下で もがく事となる と 再々度警鐘しておく。

短く纏めるのは･･･

･･･限界あるんだよな、この手の内容は。

■ こちらの･･･

とあるTweetで取り上げられている事象は、徒花緊急の【双子】で、旧環境にて 稀にだが、顕著であった。


■ そもそも、

★ nVIDIA (のディスプレイドライバ)合わせで構築された

･･･PSO2 は、データ転送に対するタイムアップの定義が、シビア通り越して極めてピーキー。

■ コレを

非最適化対象である AMD RADEON HD7770 を2枚用いた CrossFireX 構成で用いていた頃は、
設定5ですら、徒花緊急の【双子】で、たまに発生していた事象である。 

そのグラボ環境のまま設定6にすると 全ボス そうなってしまっていた。


◆ もう少し厳密に云うと、 

★ GPUベンダが

nVIDIA AMD Intel 何れであれ、PCIeバスに於けるデータ転送帯域の世代別最大値に起因する。

◆ ツマり、

PCIe Gen.3.x(32.0GB/sec) のバス帯域で可能なデータ転送速度(秒間量)であれば発生しない問題が、

DirectX9c時代に登場した Gen.1.x(8.0GB/sec)は云うに及ばず、
続くDirectX10や11を基盤とした時期の Gen.2.x(16.0GB/sec)のキャパシティを以てしても、

定義されている時間では、マシンのメインメモリから グラボ上のVRAMへのデータ転送が間に合わず、
結果としてタイムアウトする。


★ ココの説については、仕様からの判断では無く、実働で確認している。

現在 おきつね端末1st機は、990FXマザーボード(PCIe Gen.2.0)に対し、
HD7770CFx から RX480のシングルボード環境へ移行している。

この状態で PSO2 CCEp.4ベンチを実行すると、各ディスプレイ解像度共に、
巷のPCIe Gen.3.0マザーでのRX480のベンチマーク結果を遥かに下回る。

この事実から、PCIe の転送速度が、大きく影響するモノであると、結論している。




★ それがドウ繋がるか?

■ PSO2 は

未だ DirectX9cと云う 骨董ライブラリに依存した 32bitビルドのアプリケーションである。

★ その癖

ハードウェアだけは、最新鋭PCIeである Gen.3.xを 最低ラインとして構成されている。

nVIDIAは以前より、
PCIeのデータ転送ピーク値のみ診て デバイスドライバを設計している傾向が強い企業だ。

更に云えば、
仮に同社製GPU搭載マシンであったとしても、少し古いだけで 最適化対象外となる と考えていい。
ツマり、"nVIDIA Optimized" とは、そう云う意味であり、その様な結果しか生まないと云う事だ。

要するに、PCIe Gen.3.x以前の機材環境であれば どのマシンでも、データ転送のタイムアウトが発生しうる現実。

■ そうした原因に因り、

PSO2クライアントアプリケーションがクラッシュ ないし Windows の BSoDを誘発する。

★ それが仮に

Windows側のメモリ管理処理により回避出来た場合でも、

描画演算に必要となるデータの全体がVRAMに届いていない
コトで、表示は破綻したままプレイを継続する必要に迫られる と云うワケだ。

★ 尚、マシンと実行アプリケーションが

DirectX12 に準拠していれば、物理的にも理論上でも この問題は発生しない事になる。

DirectX12 でのメモリ空間は、メインメモリも VRAMも フラッシュストレージ上さえも、
シームレスに扱える仕様となっており、AMDのPolaris世代以降は、それを物理回路で
支援するよう構成されている。
nVIDIAは DirectX12 対応でも、AMDより半導体回路設計レベルで後塵を拝している･･･
また 余計な小細工など してこないコトを 期待したいが(´ﾍ｀；)



★ また、

◆ 32bitビルドアプリケーションでは、

プログラム中で扱われる変数で格納可能なデータサイズも32bit長となる。

時間処理を多用する PSO2のようなアプリケーションの場合、
1つ1つで扱われる時間が短くても、その領域の確保と破棄が大量発生する事になる。

当然だが、母数が大きくなれば、エラーの発生数も増すと考えて差し支えない。


■ 元々

コンシューマ向けとして投入されてきたWindowsは、メモリー領域管理が WindowsServerに比べて非常に雑だ。

VISTA～7までなら、エディションによっては
WindowsServer2003EnterpriseEdition程度のメモリ管理性能は有していた。

が、

Windows10 になり、一般調達可能なエディション最上位ですら、
WindowsServer2008R2/2012などと比較すると、コンシューマレベルに落ちているとも云える。

◆ そんな物の上で稼働する WOW64･･･

64bitWindows上で 32bitアプリケーションを実行させる為の 補助輪的な枠組
･･･経由では、避けたい処理の1つである。

★ この解消には、実行されるアプリケーション(本ログでは PSO2)の 64bitビルド版配布が妥当であり、待たれる処であると結論出来る。

★ 本ログ内容は、

◆ おきつねさまが、アンケートなどで終始 苦言を呈してきた内容に、寸分違わず準じている。

上述の通り、古い環境は着実に無視する運営スタイルとなってきているにも関わらず、
アーキテクチャの差し替えはしないままだ、この時点で相反する状態を運営自ら作ってしまっている。

★ その様な状態での

相次ぐ 意図的とも受け取れる 誤ったBANの数々･･･ PSO2運営も御多分に漏れず、この様な状況 なのかね?