"高速"プロバイダに表示義務を 32
ストーリー by yourCat
ライフ・ライン化の前提 部門より
ライフ・ライン化の前提 部門より
ncube2曰く、"日経新聞の記事によると、総務省はインターネットサービス等に関して「高速ネットの速度やネット電話の音質、入会・解約にかかる日数などの公表を通信事業者に義務づける」方針なんだそうな。
「入会・解約にかかる日数」ってとこは「放置プレイ駄目よん」と言うことと思われ、まあ妥当だとは思うが、「高速ネットの速度」ねえ。閉じたネットワークならSLAもありだと思うけど、フツーのインターネットの速度って宅内配線とか局からの距離とか地域IP網やバックボーンの混雑とか接続先の負荷とかの個々の要素が複雑に絡むから、結構アバウトな数字になりそうな......。
あと「ネット電話の音質」てのがありますが、5月20日号の日経コミュニケーションによると、どうも総務省がIP電話に電話番号を割り当てる際に、サービス業者に通話品質を提示させるようです。
で、通話品質を示す値として「R値」ってのを採用するらしいが、この「R値」を算出する詳細な方法って未だ不明確な部分があるというか、未だ国内では標準化されてないらしい。(をいをい) 更にそもそも「R値」ってのはIP電話の品質評価方法じゃないという話もある。(こらこら)
さてはてこの施策、消費者に判りやすくて正確な情報を提供できるのだろうか?"
民間に義務つける前に (スコア:5, すばらしい洞察)
R値 (スコア:2, すばらしい洞察)
Re:R値 (スコア:1)
などを精密化するときの指標にする、
R = |理想値-実測値|/|理想値|
のR値と同じ考えかたのものですか?
だとしたら、0に近づくほど高品質ということになります。
Re:R値 (スコア:1, 興味深い)
んでもってFLDでも書いて、経路による限界をくらべる、と。
# さぁ、ついてこい!
># 車のエンジンはそんな状況から脱却したようですが。
そんなこたー、ありません。
実効燃費とかけ離れたモード燃費競争にあけくれています。
特定の回転数/速度でエアコン切ったり(w
ちょっと前にくらべると、カタログ燃費はすごーく良くなって
いますが、実際どーでしょ?カタログ値ほど良くなってる?
# たしかに、特定車種の特定個体によってはカタログ値以上叩き
# だしてくれたりもするんですけどね。
# 機械加工/組み立てはナマモノだし:-P
Re:R値 (スコア:0)
PAM!! PAM!! PAM!!
用語説明:R値 (スコア:0)
値が高いほど、より制限された成人向けコンテンツへのアクセスを行うことが可能で、一般的には回線品質に比例する傾向にある。
映画などで用いられている「R指定」を由来とした数値であるが、「R指定」と異なり、算出の方法に不明確な部分がある。
これは、法で規制されていない(当局が把握しきれていない)、 所謂“裏”と呼ばれる成人向けコンテンツがインターネット上に多数存在していることが主な原因
Re:用語説明:R値 (スコア:0)
相手がいてこそのインターネットでしょ? (スコア:2, すばらしい洞察)
インターネットというのは自分の環境がクローズドではないからなぁ。というよりも「相手」がいて初めて成り立つわけで、例えばメールの受信速度はプロバイダのサーバなので内部的なネットワーク速度を調整すれば良いと思うんだけど、プロバイダの提供するコンテンツにのみ興味のある人には有効な数字かもしれないけどそうじゃないよねぇ。
速度じゃなくって、接続ネットワークとその太さを教えてくれれば良いんだよ、とか思うけど実はそれってインプレスのインターネットマガジンに付いてるじゃん。あれってほとんどのプロバイダを網羅してるからあれで十分な気がする。
でも通常使っていても速度はほとんど気にならないんだけど・・、みんなそんなに気にしながらインターネットしてるの!?(わら
唯一気になる時と言えば・・
DebianのCDイメージ落とす時、おいおいwoodyのイメージは何枚なんだ!?
職業としてのプログラマ
Re:相手がいてこそのインターネットでしょ? (スコア:2, すばらしい洞察)
>速度ってなに?って疑問が・・・
太さという意味では、実際には回線が混んでいる時もあるし、そう考えると任意の接続先へのリアルタイムなR値メーターが必要になっちゃいますね。R値が高くてもスループットが上がらなくて実質遅いということはあり得るし。
実際、体感的に遅いか速いかという違いは重要だけども、それは結局その人の使用環境などいろいろな条件が重なってしまうから、R値自身には意味がない気がします。
Re:相手がいてこそのインターネットでしょ? (スコア:1)
不快指数を算出するときの要素の一つ。(笑)
李 露星
プロバイダマップは高々datalink layer (スコア:1)
現実には複数の相手とpeer接続しているISP(厳密にはAS)もかなりあります。この場合、経路制御を工夫することにより、複数の回線の間でload balanceすることができます。したがって、プロバイダマップで出てくる帯域が直ちにend-to-endの帯域となるわけではありません。
わたしの憶測ですが、プロバイダマップで帯域を公開することが広まった背景には、ISP側のこんな読みがあるのかも知れません。
逆にいえば、あたかもマップ上では複数の上流を持っているように見せながら、うち1本ではpacketを大量に流すとコストが上がるため、実際にはほとんど片方しか使っていないという例も十分あり得ます。
実は裏事情として…… (スコア:1)
「ブロードバンドごときで俺様たちの手を煩わせるな!」
と、叫いてみただけだったり――――しませんかね?
速度表示といえばBIGLOBE (スコア:1)
これでバックボーン公開になりますかね。
Re:速度表示といえばBIGLOBE (スコア:0)
これでBIGLOBEやめました。
Re:速度表示といえばBIGLOBE (スコア:0)
#負荷分散は大事です
Re:速度表示といえばBIGLOBE (スコア:2, おもしろおかしい)
# これで知りあいが一人やめましたよ。
…をいをい (スコア:0)
「(ベストエフォードで最大)ほげほげMbpsです。」ってのはどこのISPにも書いてると思うけど…これって総務省的には違うのん?
Re:…をいをい (スコア:0)
みたいに思ってしまう人は多いのかな。
(そもそもベストエフォートの意味がわかる人ってどれくらい……いや、云うまい)
#100Base-Tだって実測値計ってみたら「なんじゃこりゃあ」な速度だし
Re:…をいをい (スコア:2, 参考になる)
さらにいえば、tcpでその速度が出ると思い込んでる人もいるでしょう(これはかなり多そう)。いくらwindowを広げたって、ackが必要なtcpはack待ちのoverheadがないudpを越えるthroughputは出せません。
Re:…をいをい (スコア:1)
Re:…をいをい (スコア:0)
おお! 実はこんなにも速かったのか! アメイジング!
Re:…をいをい (スコア:0)
実際スループットが期待されるような用途もTCPでしょ。
UDPのスループット測っても何の参考にもならんですが。
Re:…をいをい (スコア:1)
transport protocolが選べる場面もあります。例えばtunnelを掘る時は、余分なoverhead(大抵はack待ち)を削るためにudpが使えます。nfsでも最近はdatalink layerの遅延があまり気にならなくなってきたので、tcpを使う理由がなくなってきています。ちなみにこれらはいずれもその上にさらにさまざまなapplicationが載るため、こっちの方がよほどthroughputが必要です。
tcpを使っている理由というのは、
というぐらいのものです。もともと何が何でもthroughputというのが目的ではありません。tcpのthroughputが問題になるのは、これに気づかず安易にtcpを使うことが増えてしまったためです。最初からtransportが選べるなら盲目的にtcpを使う必要はありません。
Re:…をいをい (スコア:0)
Re:…をいをい (スコア:2, 興味深い)
加入先を選ぶ際に『数字が大きいほど速いのだろう』
と思うだけのこと。実際にどれだけの速度が出ているかを計ったりもしません しね。これはネットワークに限ったが話でもない。数字で評価されていると、「そ れって大きい方がいいの、小さい方がいいの」が素朴な反応です。
# エイズの検査で「ネガティブ」といわれ、一瞬青ざめたことを思い出したり、、、。
佐藤亮一 in Frankfurt Germany
Re:…をいをい (スコア:1)
確かに、他に比べるものを知らない人は、それが速いのか遅いのか分かりませんもんね。
そして、調べたりしない限りは、その環境で出る速度が最高速度な訳で…。
そう言う私はYahoo!BBで最高2.2Mbps。
普段は1.5Mbpsぐらいか…。<電話線を短く切ったら遅くなった。(^^; <自業自得
Yasuda
Re:…をいをい (スコア:0)
ベストエフォート (Re:…をいをい) (スコア:1, すばらしい洞察)
>みたいに思ってしまう人は多いのかな。
>(そもそもベストエフォートの意味がわかる人ってどれくらい……いや、云うまい)
PacBellがやってたDSLは、保証値というか速度の下限値を上限値と共に記していた。下り300kBPS、上がり64kBPS位だったかな?こういう発想って、日本のプロバイダには皆無と思われ。だから、某◎CNみたいに名目128kBPS実効20kBPSとか、某多摩地区のCATVインターネットみたいに名目10MBPS実効10kBPSとかの凄まじいサービスがまかり通るんだわさ。
大体、ベストエフォートってな呼び方が悪い。BEは腐った自ネットワークを正当化する方策でしかない、日本では。保証出来ないんじゃなくて保証したくないor保証するつもりがハナっから無いんだね、日本でのBEの意味とは。なら、「極道」とか「ぼったくり」とか「いい加減」とか、適切な呼び方はいくらでもあるのでぁ?
むむむ (スコア:0)
R値ってどういったものなんでしょかね
Codec音声圧縮の評価で MOS というのを聞いたことはありますが :)
帯域は最大でなんぼまで出ますとはあっても、網内でQoSはこのように……とかは見たことないですねぇ
音声サービスだと伝送遅延がクリティカルになるし、帯域もそなりだよなぁ
delay vs isosynchronousness (スコア:1)
遅延がひどいのでは使いものにはなりませんが、よくよく考えると音声のpacketは他のpacketを潰してでもdelayをつめるという方法では不十分です。たとえdelayの平均値が小さくとも、そのdelayが非常に大きな分散を持ってしまうようでは困ります。つまり、packetが飛んでくる周期を一定にしておけば(符号化した音声のbitrateが一定ならば)、不必要に焦ることはないわけです。
通信の述語なのかどうかは知りませんが、OSのschedulingではisosynchornousness(等時性)という考え方があります。isosynchornousなtaskというのは、音声や動画の再生のようにある一定周期で必ず実行すべきものの事だそうです。こんな要求のために作られたUnixがあるそうで、isosynchronousなthreadは普通のrealtime threadをもpreemptできるようになっているとか。networkでもやれば似たようなことができると思いますが、誰かやってるんでしょうかね?
Re:delay vs isosynchronousness (スコア:1)
パケットの優先制御で可能ですね。
特にボイスのようなリアルタイム制が要求されるデータを扱う上では必須になってくると思います。
例えばGWなどでリアルタイムパケットのプライオリティを最優先にして、優先制御をかけてやることが出来ます。
リアルタイムパケットれよりも下位の優先度のパケットに関しては、上位のパケットが転送キューにある限り処理されないので、「なにがなんでも音声最優先!」という構築もできますねぇ。
ただパケットの優先制御もアレですが、足回りの伝送遅延とかGW機器の固定遅延とかは……
Re:delay vs isosynchronousness (スコア:1)
packetにpriorityを与えることができるというのは、以前に話を聞いていました。気になったのは、priorityに対して音声向きや経路制御向きなど、何らかの応用を前提とした意味を持たせる(つまりscheduling policyを自由に決める)ことができるかどうかです。SVR4よろしくrouter用の外付packet schedulerとかがあれば何とかなるでしょうが...