アカウント名:
パスワード:
技術的には革新
(特にNTTの)研究所の方々にはコストの概念とビジネスセンスがないものですから。
そうは思わんがね。 どちらかというと、NTTの人達には「根本的に」コストセンスもビジネスセンスもない。研究所に限る必要はなく。 そういう世界では、逆に分散幅が最大である研究員が、「コスト的に引き合わない」と計算して出した結果が最もあてになる。 実際問題として。QoSというのは「ネットワーク」上におけるリアルタイムリソース配分問題の1種だ。これをCPUやメモリ対して適用すると『リアルタイムOS』の制御問題になる。数学的には完全に等価な問題であり、完璧な解は「
最適解を出すためにはO(2^n)の計算漁を必要とする
単なる帯域確保でこんなに計算量が必要ありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
消費者からみて、 (スコア:3, すばらしい洞察)
技術的には革新なのかも知れませんが、それを使う消費者にとって
うれしいことが何なのかわからない技術、という意味ではキャプテン
システムと同根かもしれませんね。
Re: (スコア:2, 興味深い)
確か、『QoSなんぞやっている暇があったら、回線をジャブジャブ引いたほうがよほどよい。QoSはコスト的に見てもやるだけ無駄』という研究結果が「NTTの研究所から」出てたような記憶があるんですが。
NGNの何がどう革新なんだかさっぱりわかりません。
fjの教祖様
Re: (スコア:0)
#だからこそ、研究所にしかいられないという面もあるが
Re: (スコア:1)
そうは思わんがね。
どちらかというと、NTTの人達には「根本的に」コストセンスもビジネスセンスもない。研究所に限る必要はなく。
そういう世界では、逆に分散幅が最大である研究員が、「コスト的に引き合わない」と計算して出した結果が最もあてになる。
実際問題として。QoSというのは「ネットワーク」上におけるリアルタイムリソース配分問題の1種だ。これをCPUやメモリ対して適用すると『リアルタイムOS』の制御問題になる。数学的には完全に等価な問題であり、完璧な解は「
fjの教祖様
Re: (スコア:1)
O(n^2)の間違いでは。そう考えても、こんな計算量を必要とするのはルーティングぐらいです。単なる帯域確保でこんなに計算量が必要ありません。せいぜい、O(n)です。
巨大なネットワークでこそQoSが重要だと思います。経路上の1ノードでも帯域を確保出来なくなるとQoSは破綻するので、破綻のリスクは経路上のノード数乗のオーダO(X^n) で増加します。つまり、巨大なネットワークでこそ、QoS保証の仕組みが必要です。
リアルタイムOSを例に挙げておられましたが、コストがシビアな組み込み機器でこそリアルタイムOSが使われてます(安いCPU+リアルタイムOS)。
Re:消費者からみて、 (スコア:1)
失格。
『帯域確保』に必要なコストが O(n)ですむのは「リソースが十分にある」場合だけだ。
すでにある優先順位に従ってリソースが使われているときに、さらに優先度の高い要求が来た場合、
1) リソースを最高優先度のものに割り当て
2) はじき出されたものを迂回路に回す
3) それでも間に合わないものをサービス停止し、そのコスト請求を止める
というこの3段階を行う必要がある。
2以降のコストが洒落にならない。
回線利用率が50%を超えるまでは実は笑って済ませられるほど簡単な近似解で十分なのだが、50%を超えた状態を維持し続けたまま…と言った途端にオーダーが跳ね上がる。
HAを考えると、単純なバックボーンモデルはナンセンスだ(そして、NTTに対する非常時回線確保からも判るようにHA要件は義務だ)。必然的に迂回路の再計算が必要になるが、『迂回路側』でも同じような帯域確保が発生した場合に、解が振動したりしないアルゴリズムを採用する必要がある。
するといきなりO(n)ではすまなくなる。
これはある種の「神の目」を解く問題なので、計算量が単純であるためには、リソースが十分ある、という仮定がどうしても必要になる。しかしリソースが十分にあるなら、最初からQoSなんか心配する必要は無いのだ。
fjの教祖様