TidBITS: Apple News for the Rest of Us  TidBITS-J#367/24-Feb-97

何が大型電器店の販売員を奮い立たせるのか考えたことがあるだろうか? それは、お金である! Ian Gregson 氏が昨年の年末商戦で体験した話を読 んでみて欲しい。また、この号では、Emailer 2.0 のベータ版リリースと Apple 社の CFM-68K Runtime Enabler に関する情報に加え、Mark Anbinder からは WebTV について、また、超高速な新型モデムがどんな形で応答時間 に支配されているかについて Stuart Cheshire 氏が事細かな考察を加えて いる。

目次:

Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。

TidBITS 日本語版は以下のメンバーのボランティアによって翻訳・発行されています。
Kaz Yoshikawa <kaz@fact.com>
井ノ本琢也  <inomoto@helix.mgh.harvard.edu>
尾高 修一  <odaka@iprolink.ch>
尾高 里華子 <odaka@iprolink.ch>
小山 純一  <vb4j-oym@asahi-net.or.jp>
加藤 たけあき<oiso@wolfenet.com>
米谷 仁志  <comet@kk.iij4u.or.jp>
齊藤 聡   <akkun@ca2.so-net.or.jp>
杉浦 雄一郎 <ysugiura@direct.ca>
高島 均   <hitak@kk.iij4u.or.jp>
西村 尚   <hisashin@st.rim.or.jp>
水木 潔   <HGH03125@niftyserve.or.jp>
村上 浩   <murasan@yk.rim.or.jp>
矢倉 遠十吉 <oto@mb.infoweb.or.jp>
山浦 礼子  <raeko@bnn.co.jp>

今回の TidBITS のスポンサーは:


MailBITS/17-Feb-97

(翻訳:村上 浩 <murasan@yk.rim.or.jp>)

CFM-68K Beta -- 昨年 12 月、アプリケーションによっては深刻なクラッ シュやデータの消失を引き起こしかねないことから、Apple 社は 68K Mac ユーザーに対し CFM-68K Runtime Enabler を使わないよう勧告 ( TidBITS-356 を参照)、Mac OS 7.6 でも CFM-68K はサポートされな かった。そして今回、同社は 68K Mac 用 の CFM-68K Runtime Enabler 4.0b1 をリリースした。このベータ版はサポート範囲外(つまり、各自の 責任において使用)であることを同社は強調しているものの、初期段階の 動作テストを見る限り、CFM を必要とする 68K アプリケーションは動作可 能になっている。ただし、Cyberdog 1.2.x と 2.0 は除く。同社は新バー ジョンの CFM-68K を Mac OS 7.6.1 で出荷する計画で、早くも来月にはリ リースの予定。 [GD]

<http://www.macos.apple.com/macos/cfm/cfmbeta.html>

BBEdit 4.0.3 -- Bare Bones Software 社は、好評の商用版テキストエ ディタ BBEdit をアップデートした( TidBITS-365 を参照)。新バージョ ンの BBEdit 4.0.3 では、FTP と HTML のサポートが強化されており、 CodeWarrior との統合機能にも改良が加えられ、起動時間も短くなってい る。また、PowerPC 603 と 604 プロセッサ上でのパフォーマンスも向上し ている。アップデータのサイズは約 2.5 MB である。 [GD]

<http://www.barebones.com/updates.html>

Emailer 2.0 Beta -- Claris 社は Emailer 2.0 の公開ベータ版を発表 した。このバージョンでは、全てのメッセージは一つのファイルに保存さ れ(これにより、以前のバージョンが抱えていたパフォーマンス上や保管 上の深刻な問題はなくなった)、フィルター機能も強化されている。この ベータ版には改良点も多く含まれているが、ちょっとテストしてみた感じ からして、その安定度は怖いもの知らずのユーザーが使う分には事足りる といった程度に過ぎない。ダウンロードサイズは約 5 MB である。 [GD]

<http://www3.claris.com/emailer_beta/>


最前線での Performa 販売

by Ian Gregson <igregson@portal.ca>
(翻訳:尾高 里華子 <odaka@iprolink.ch>)

Mac を置いている大型家電販売店で、販売員があまり頼りにならなかった りするのは(そして時としては愛想さえ良くないのは)どうしてだろうと 思ったことはないだろうか ? 私は、去年のクリスマスの買い物シーズンで の体験から、Macintosh を買おうとしている人が販売員から冷たくされる 理由を学んだ。

私は 1989 年以来 の Mac ユーザーである。そして、このあいだのクリス マスの直前に、Apple Demo Days という店内プロモーションの仕事を Apple から請け負った。2 日間の研修を受け、カナダの B.C. 州 Vancouver のあ たりで一番混んでいる Future Shop のある店(クリスマス前のショッピン グ地獄の中と言い換えても良いだろう所)で仕事をした。

報賞金とその影響力 -- 販売員が、優秀な販売成績に対してメーカーか ら(“報賞金”という名の)見返りを受けとっているということが分かっ た。 Acer 社、Compaq 社、IBM 社、Apple 社はいずれも奨励金制度を設け ている。私がいた店で、奨励金を一番たくさん出していたところはどこか お分かりになるだろうか ? Acer 社だ。一番売れていたところはどこか ? Acer 社だ。では、奨励金が一番少なかったところはどこか ? Apple 社だ。 一番売れていなかったところは ? もうお分かりになるだろう。

奨励金はメーカーによってもまちまちだが、さらにモデルによっても違っ てくるのだ。例えば、Performa 6400/200 や 6400/180 の奨励金の方が、 新しい 6360 モデルよりもずっと高いのだ。

この販売促進制度が、販売員達に与える影響は絶大だろうし、これが、 Macintosh を買おうとしている人よりも Acer 社の Aspire を買おうとし ている人の対応に販売員が時間をかけるという結果になって現れるのだ。 さらには、販売員は Mac を売るどころか Acer 社の製品を押し付けようと さえするという結果を招くことがある。5 倍以上の奨励金を目の前にして は、“使い易い”とか“プラグ & プレイ”などという言葉は何の意味もな さなくなるのだ。

私が Future Shop にいた期間中、Acer 社の Aspire は Macintosh のおよ そ 10 倍の勢いで売られていた。見るのも居たたまれなかった。 新参のコ ンピュータユーザーは、自分が入り込もうとしている世界のことが分かっ ていない。ほとんどの人達はインターネットのできる安いマシンを欲しがっ ていたし、Aspire は、いつの日かは、その望みをかなえてくれるものなの だ。

こういった初めてコンピュータを買おうとしている人達大勢と話をした。 先ず最初に、「Macintosh のことを考慮したことがありますか?」と問いか けた。9 割の人が「ない」という答えだった(これは答えとしては、おと なしい方だった)。時には、「ふざけているのですか?」とか「それで Windows は動くのですか ?」「私の周りはみんな Windows 95 を持ってい るのに、なんで Mac なんかを」などと言われることもあった。彼らの Macintosh というものに対するあからさまな懸念を無視したままデモを行 うと、必ずみんな感動するのだ。フロッピーや CD が、ドライブに差し込 むだだけで、デスクトップに現れるのにはみんなが驚いた。その使い易さ に圧倒された。 Mac 経由でケーブルテレビを観せると驚きは絶頂に達し た。中には真剣に(5 分間ぐらい)Mac も検討する人がいるが、結局は Acer を買って帰るのだ。

実際のところ、Mac ユーザーの 9 割が私に出会ったことを喜んでくれた。 Mac ファンの人達と、いかに Mac が素晴らしいか、そして、いかに Apple のマーケティングがお粗末かということを長々と喋った。(残りの 1 割 は、Performa 6400 を発売直後に買ってしまった人達だ。Apple は、6400 シリーズを販売から 2 ヶ月で 700 カナダドル値下げしたのだ。)

初めてコンピュータを買おうという人が、どのコンピュータを買うかあら かじめ考えてから店にやって来るのはわかりきっていることだった。彼ら は決断を下しに来るのではなく、決めたマシンを買いに来ているのだ。自 分が買おうとしているものに対してほんのわずかでも戸惑いを持っている と、Acer を薦める販売員のささやきとその戸惑いが結び付いて、Mac の売 上が多少とも下がることになる。

Apple が為すべきことは ? Acer 社の Aspire よりも数多く売るために は、Apple 社は、もっと積極的な広告戦略が必要だ。30 分間の情報コマー シャルもよいが、建設的でわかりやすい 30 秒の広告の方がもっと効果的 だ。あらゆるメディアを同時に考慮しなければならない。

販売員に対する Apple の奨励金は、増えたが(例えば、Future Shop のあ る店の全販売員が、ある期間中の Macintosh の販売成績が最も良かった報 奨として PowerBook 190 をもらった)、優秀な販売成績への見返りとして は、固くて冷たいカネに優るものはないのだ。実際、販売員の何人かが、 私に自分の貰った PowerBook を買わないかと持ち掛けたのだから。

大型家電販売店での Mac の売上があまり芳しくないのに、どうしてひたす らそこで売ろうとするのだろうか? それは、大型家電販売店が、コンピュー タのことをあまり知らない人が、低予算で、初めて、最初のマシンを購入 する場だからだ。Future Shop の店舗は、新規購入者に支配力を伸ばす戦 いの最前線なのだ。

自宅にコンピュータを持っている人よりも、持っていない人の方がまだは るかに多い。Apple 社は、初めてコンピュータを買う人が店内に足を踏み 入れる前に、彼らの心を捕まえておかなければならない。これと販売員が 新規購入者へ Apple の製品を薦めようという気持ちが結び付いて始めて、 Apple の売上は飛躍的に伸びるだろう。


テレビ世代のためのインターネット

by Mark H. Anbinder <mha@tidbits.com>
(翻訳:齊藤 聡<akkun@ca2.so-net.or.jp>)

Web は情報と娯楽に飢えている多くの人々の注目をがっちりとつかんでい る。また、National Hockey League や Oregon Shakespeare Festival の ようなさまざまなグループが魅力があり含蓄のある Web サイトを構築する ことに莫大な労力を払っている。しかし、TidBITS の読者に限ればすでに インターネットにアクセスする手段はあるだろうが、多くの家庭にはネッ トワークに接続するために必要な、比較的新しいコンピュータ、モデム、 インターネットサービスアカウントはないのである。

<http://www.nhl.com/>
<http://www.mind.net/osf/>

Philips Magnavox 社と Sony 社から新たに家庭用の電子機器製品が登場し た。どちらも WebTV という名前をライセンスしている。これはテレビと電 話線のある家に住む人なら誰でも(テレビと電話線の差し込み口がかなり 物理的に接近していなければ、という例外付きでほとんど誰でも)Web と 電子メールのサービスを受けられるというものである。そのなめらかなブ ラックボックスの価格はおよそ 300 ドルである(オプションとしてキー ボードを希望すると別に 100 ドルかかる - 絶対に必要になるのだが)。 インターネットサービスは月 20 ドルである。たいていの家庭でケーブル テレビにかかるコストよりも小さいのだ。

<http://www.sel.sony.com/SEL/webtv/index.html>
<http://www.magnavox.com/hottechnology/webtv/webtv.html>
<http://www.webtv.net/>

WebTV の大きな利点のひとつはあらゆるものが準備されているということ である。いろいろいじり回さなければならないソフトウェアはない。音を 出したりビデオを見たりするために特別なユーティリティをダウンロード することもない。メモリ不足エラーも一般保護違反もない。高速モデム (33.6Kbps v.34bis)が内蔵されているので、必要なのは WebTV と電話、 コンセント、テレビをケーブルでつなぐことだけである。

<http://www.webtv.net/corp/HTML/home.specs.html>

WebTV のコンセプトはホームユーザーが娯楽と情報を求めてそれを使うと いうことである。基本的な WebTV の構成では、キーボードはなく、手元の リモコンで目的を達成することになる。Web ページを見るために離れたと ころから矢印ボタン使ったり、リンクを追ったりオプションを選択するた めに Go ボタンを使ったりして、自分の興味を惹くコンテンツをブラウズ する。これはマウスに慣れた人にとって奇妙に感じられるが、違いすぎる ということはない。私はビデオデッキの録画予約を連想する。

WebTV はテレビの画面に Web ページを表示する。たとえテレビがコン ピュータの画面よりも非常に大きいものであったとしても、十分な情報は 表示できない。たとえ WebTV の S-Video 端子を使えば S-Video 端子のつ いているテレビに少しは良質な画像が送れるとしても、テレビは 640 × 480 モニタと同じ解像度ではないのである。WebTV 上では、たいていの Web ページは Netscape Navigator や Microsoft Internet Explorer で見たも のとは異なって見える。例えば、テレビ画面ではインターレースを行うた め、WebTV では幅が 1 ピクセルしかない水平線はちらついてしまう。一般 的に言って、テキストは Web ページの作成者が意図したのではないところ で改行されるかもしれないし、グラフィックもそれとは別のところに表示 されるかもしれない。非常に大きなモニタで見るようにデザインされた Web ページ(私の見解ではこれは良くないことだ)を見るのは困難になるだろう。

リアルタイムアップデート -- 最新の WebTV は RealAudio をサポート している。これは ユーザーに Web 上でコンサートやニュース放送やその 他の音をリアルタイムで聞けるようにするものである。モデム接続の帯域 幅でも、音声(ニュース放送のような)は良好に聞こえ、音楽(コンサー トのような)は聴取可能であり、十分に忠実な音再生が可能である。初期 に WebTV を購入した人は、それがこの機能などを備えるように自動でアッ プデートできることに気付くだろう。WebTV のデベロッパーが新しい機能 を完成させると、それぞれの WebTV は必要なソフトウェアやアップデート をそれ自身で取り入れようとする。アップデートはモデムで数分かかるの で、WebTV はそれを実行する前にその時間をかけてもよいかどうか質問し てくる。

万人のための電子メール -- WebTV は電子メールを扱うことができる。 また、個人的なメールボックスを 5 つ用意できる。この電子メール機能 は、大学の子供に送ったり、あるいは子供たちがおばあちゃんに送るのに おそらく最良だ。大きなメッセージを表示するためにテレビ画面に多くの 文字を表示することは WebTV には合わないし、(Helvetica に似た)プロ ポーショナルフォントがせっかく整形された電子メールをだいなしにして しまう。しかし、短いメッセージの送受信には役立つだろう。

これにはタイプの問題が伴う。たいていのインターネットユーザーは、た とえ電子メールを使っていなくても、時々タイプする必要が生じる。 “www.cnn.com”や“www.tidbits.com”に WebTV を使って行くためには、 そのアドレスをタイプしなければならない。WebTV では Newton を連想さ せる画面上のキーボードでリモコンを使ってキーを探し回ることになる。 これを修得するのは容易だ(標準的な QWERTY タイプライター配列とアル ファベット配列のどちらかをスイッチで切り替えられる)が、入力は苦痛 なほど遅い。

キーボードは WebTV のリモコンと同じ赤外線リモートコントロール技術を 使っている。ソファに座ってひざの上にそのキーボードを置いてタイプす ることができる。それはコンパクトなキーボードで慣れるのに時間がかか るが、リモコンでタイプするよりはずっとましである。

著者は気に入っている! 私は WebTV に次第に好感を持ってきている自 分に驚いている。私はカウチポテト形式で行う Web サーフィンを楽しんだ し、テレビ番組やコマーシャルに現れる URL から Web ページに飛ぶとい う機能を評価している。言い換えると、昔からのインターネットユーザー でさえヘビーな WebTV ユーザーになれるということである。当然、WebTV の対象としている市場はコンピュータのない家庭であるが、私はすでにイ ンターネットに接続している家庭に対してさえ WebTV を導入する価値があ ると思う。 WebTV を購入したなら、おばあちゃんのためにもう一つ買って ほしいものだ。


バンド幅と応答時間: 問題は応答時間にあり(第一部)

by Stuart Cheshire <cheshire@cs.stanford.edu>
(翻訳:尾高 修一 <odaka@iprolink.ch>)

もう何年も前、Stanford 大学で David Cheriton 氏は当時あまりにも当然 のことと感じられたことを教えてくれた。容量の小さいネットワーク接続 なら、たくさん並列に並べて大容量の接続を得ることができるが、応答時 間が悪いネットワークはどれだけお金をかけて並列にしても応答時間の良 い接続にはならない。あれから何年もが過ぎ、家庭向けのネットワーク用 ハードウエアやソフトウエアを作っている企業にはこのことが忘れられて いるようだ。もう一度説明し直さなければならない時が来たのだと思う。

スピードと容量 -- 頭の良い人でも応答時間がスループットにどんな影 響をおよぼすかを完全に理解するのは難しい。その原因の一つに、“高速” という言葉が誤解を招くような使い方をされていることがある。ボーイン グ 747 は ボーイング 737 より 3 倍“高速”だと言えるだろうか? もち ろんそんなことはない。どちらも 時速約 500 マイルで飛ぶのだ。違いは、 747 は 500 人の乗客を運べるのに対し、737 は 150 人しか運べないとい うことだ。ボーイング 747 は 737 より 3 倍 大きい のであって、3 倍 速いのではない。

どうしても早くロンドンにたどり着きたかったら、時速約 1,350 マイルで 飛ぶコンコルドに乗るべきだ。コンコルドは 100 人しか乗客を乗せること ができないので、この 3 つの中では最も小さい。大きさと速さは同じでは ないのだ。

一方、1,500 人を運ばなければならず、かつ飛行機が一機しかないとした ら、747 なら 3 往復で全員を輸送できるが 737 なら 10 往復かかる。し たがって、747 は大勢の人を 737 より 3 倍速く輸送することができると は言うことができるが、747 が 737 より 3 倍 速い とは決して言わな いだろう。

これが今日の通信機器が抱えている問題の一つなのだ。メーカーは 容量 と言う意味で 速度 という言葉を使う。もう一つの問題は、エンドユー ザーが最も関心があることは、大きなファイルを速く転送したいというこ とだ。この目的には大容量で低速な接続が一番向いているように見える。 エンドユーザーが気が付かないのは、コンピュータはファイルを転送する ために小さな制御用メッセージをたくさん送受信しているということだ。 コンピュータを使った通信がテレビやラジオと違うのは情報が双方向に流 れるということであり、双方向通信は小さなメッセージの送受信に依存し ているのである。

先程登場した“大容量で低速の接続”という言葉は多分奇妙に見えるだろ う。私にも奇妙に見える。私たちはあまりにも長い間誤った考え方に慣れ 親しんでしまったため、正しい考え方が奇妙に見えてしまうのだ。大容量 の接続が遅いとはどういうことだ ? 大容量なら高速なはずではないか? 不 思議なことに、この主張は他の分野では当てはまらない。誰かが“大容量” タンカーの話をしたら、ただちにそれがとても高速な船のことだと思うだ ろうか? まず思わないだろう。誰かが“大容量”トラックの話をしたら、 ただちにそれが小さなスポーツカーよりも高速だと思うだろうか?

通信においても、再度この区別をはっきりさせなければならない。だれか があるモデムの速度が 28.8 Kbps だと言った時、28.8 Kbps はそのモデム の容量なのであって、速度ではないことを思い出さなければならない。速 度とは距離を時間で割ったものなのであり、“ビット”は距離の単位では ないからだ。

しかし、体感されるスループットを左右するのは速度と容量だけではない。 ここで応答時間が問題となるのだ。ハードディスクを買う時にはシークタ イムを調べるべきだということは多くの人が知っている。最高転送レート も大事なスぺックだが、もっと大事なのはシークタイムだ。誰もモデムの “シークタイム”を問題にしないのはなぜなのだろう? 応答時間はシーク タイムと全く同じもので、ハードディスクのシークタイム同様、データを 要求してから獲得するまでの最短時間を意味する。これはハードディスク の場合と同じぐらい重要なことなのだ。

厄介者 -- 一旦悪い応答時間に捕まってしまったらもう逃げられない。 通常、大きなファイルをモデム経由で転送するには数分を要するはずだ。 送るデータが少なければ所要時間は短くなるが、これには限界というもの がある。どれだけ小さなデータを送っても、これ以上はどうしても短縮で きないという限界がネットワークデバイスにはあるのだ。これがデバイス の応答時間というものだ。普通の Ethernet 接続の場合、応答時間 はだい たい 0.3 ms(ミリセコンド、つまり 1/1000 秒)だ。通常のモデム接続の 場合、ping や traceroute でのテストによれば応答時間は約 100 ms、つ まり Ethernet より 300 倍悪いことになる。

33 Kbps のモデムで 10 字(1 字あたり 8 ビット)を送りたいとしたら、 所要時間は

    80 ビット / 1 秒あたり 33000 ビット = 2.4 ms

となると思うかもしれない。ところが、そうはならないのだ。モデムの応 答時間である 100 ms が間に入るため、102.4 ms かかるのだ。

大量(たとえば 100 K)のデータを送りたい場合、所要時間は 25 秒なの で 100 ms の応答時間はあまり気にならない。しかし、たとえば 100 バイ トの小さなデータの場合には、応答時間が実際の送信に必要な時間を上回 ることになる。

だからどうだというのだ? どうして小さなデータが問題になるのだろう? ほとんどのエンドユーザーにとっては、小さなファイルではなくて、大き なファイルの転送が頭痛の種なのだから、製品を購入する際に応答時間の ことなど考えもしない。現実に、モデムのパッケージには誇らしげに“28.8 Kbps”や“33.6 Kbs”とは書いてあるものの、応答時間には全く触れてい ない。

ほとんどの人が気づかないのは、コンピュータが大きなファイルを転送す る際には何百もの小さな制御メッセージをやりとりしなければならず、し たがって、小さなデータパケットの転送性能がネットワーク上のすべてに 直接 影響するということだ。

それでは、私たちが電話線経由のモデム接続以外に可能なネットワーク接 続が存在しない世界に住んでいると仮定しよう。モデムの応答時間は 100 ms なのだが、もっと短い応答時間を必要とすることをしているとしよう。 あるいはネットワーク経由でオーディオをやろうとしているのかもしれな い。100 ms はたいしたことないように感じられるかもしれないが、音声の コミュニケーションにおいては気が付くぐらいのエコーとディレイが生じ るので、会話に支障を来すことになる。あるいはネットワーク経由でイン タラクティブなゲームをしているのかもしれない。ゲームは極めて小さな データしか送信しないが、100 ms の遅延はゲームの応答を確実に重たくす る。

それではどうしたらいいのだろうか? できることは 何も無いのだ 。デー タを圧縮することはできるが、何の役にも立たない。そもそもデータは最 初から小さかったのだし、100 ms の応答時間は依然として存在するのだ。 80 本の電話回線を並列に引いてそれぞれの回線に 1 ビットずつ同時に送 ることはできても、100 ms の応答時間は依然として残る。

言い換えると、悪い応答時間を持ったデバイスを使っている以上、良い応 答時間のデバイスに換える以外に方法はないのだ。

モデムの応答時間 -- 現在の一般向け機器の応答時間はとてつもなく悪 い。通常の Ethernet カードの応答時間は 1 ms 以下だ。インターネット のバックボーンも全体としては非常に応答時間が短い。ここで実例を挙げ よう。

というわけで、インターネットはなかなか優秀だ。時がたつにつれもっと 良くなるかもしれないが、光速よりも速くなることはないことはわかって いる。言い換えると、MIT までの往復 85 ms は少しは速くなるかもしれな いが、48 ms より速くなることはありえない。我々は既に理論的に可能な 最高速の半分以上に達しているのだ。これはなかなか立派なことだ。これ までの水準に達している技術はそう多くはない。

これをモデムと比較してみよう。仮にプロバイダから 18 km の地点にいる としよう。ファイバー内の光の速度(またはこれと同じぐらいである銅線 内の電気の速度)をもってすれば、応答時間は以下のようになるはずだ:

    18000 / (180 * 10^6 m/s) = 0.1 ms

モデムによって多少は異なるが、モデムの応答時間は 75 ms から 130 ms の間である。モデムが現在動作している速度は、光の速度の 1/1,000 の速 さだ。しかも、応答時間は往復どちらにも影響する。普通のモデムを使っ た通信の応答時間が片道 130 ms だとしたら、往復は 260 ms になる。

もちろん応答時間が 0.1 ms のモデムなど現れるはずがない。そんなこと は期待しないでおこう。大事なのは、一つのパケットの送信(送信側のソ フトウエアがパケットを送った時から受信側のソフトウエアがパケットの 最後のビットを受け取るまで)に際しての合計の時間のロスなのだ。送信 における時間のロスは、一定値である応答時間(光の伝達時間を含む)と 送信時間そのものの和である。36 バイトのパケットなら、送信時間は 10 ms となる(288 ビットを 28.8 Kbps で送るのに要する時間)。実際の送 信がたったの 10 ms なのに、応答時間を 0.1 ms にしようと努力するのは 意味が無い。必要なことは、実際の送信時間に対する応答時間の割合が比 較的小さくすることだけだ。28.8 Kbps の転送レートを持ったモデムなら、 5 ms の応答時間が妥当な努力目標だろう。

送信遅延を理解する -- 各ホップにおける全体としての送信時間は二つ に分けることができる。バイト単位の送信時間と一定値のオーバーヘッド だ。バイト単位の送信時間は転送レートだけに左右されるので、簡単に計 算することができる。一定値のオーバーヘッドの方はソフトウエアのオー バーヘッドや、ハードウエアのオーバーヘッド、それに光速の遅延などに 原因がある。

モデムの場合、距離は通常短いので、光速の遅延はほぼ無視できる。しか し、データレートが低いため、各バイトを送るのには長い時間がかかる。 バイト単位の送信時間がパケットを送るのに必要な時間のほとんどを占め ていると考えて良いだろう。28.8 Kbps モデムで 100 バイトを送るには、

    100 バイト * 1 バイトあたり 8 ビット / 1 秒あたり 28800 ビット = 28 ms

となる。とうことは、往復ならこの倍、つまり 56 ms になる。現実に要す る時間は 260 ms に近い。なぜなのだろう? 全体の送信時間にはほかに 2 つの要素が影響を与えているからだ。

まず、モデムはシリアルポートに接続されていることが多い。多くのモデ ムユーザーは、28.8 Kbps モデムを 38.4 Kbps でシリアルポートに接続し ていれば性能に影響はないと思っている。38.4 は 28.8 より大きいから だ。シリアルポートがスループットを制限しないのは事実だが、遅延を加 えることにはなる。一旦加わった遅延が無くなることはない。したがって、 シリアルポートから 100 バイトをモデムに送るには、

    100 バイト * 10 ビット / 38400 bps = 26 ms

を要することになる。

次に、モデムはデータをブロックにまとめようとする。モデムは受け取っ たデータを送り出す前に、約 50 ms 待ってブロックに加えるべきデータが さらに送られてくるかどうか様子を見る。それでは合計時間はどうなるだ ろう?

    26 ms (100 バイトをシリアルポートからモデムに送るまで)
50 ms (モデムの固定待ち時間)
28 ms (28.8 Kbps での電話回線経由の送信時間)
26 ms (100 バイトを受信側のシリアルポートが受け取る時間)

したがって、合計では片道 130 ms となり、往復では 260 ms になる。さ らに悪いことには、この 100 バイトがインタラクティブゲームの 2 人の プレーヤーによって使われているとしよう。両方のプレーヤーのいずれも がモデムでプロバイダに接続しているとしたら、プレーヤー間の合計往復 時間は 520 ms となり、タイトなレスポンスを要するものには絶望的なこ とになる。これが今日のネットワークゲームに反映されていると言って良 い。では多少なりとも改善することができるのだろうか?

応答時間の改善 -- ここで気をつけなければいけないことは、ほとんど の人が問題だと思わないコンピュータとモデムの間にある 38.4 Kbps のシ リアル接続が、実は 52 ms の遅延をもたらしていたことだ。実はこれが電 話回線を通じての通信時間の 2 倍以上に相当し、最大の要因になってい る。なにかできることはあるのだろうか? モデムを両端で 38.4 Kbps では なく、115.2 Kbpsで接続すれば、シリアルポートが原因の遅延は各 9 ms に短縮することができる。さらに、シリアルポートを経由しない内蔵カー ドのモデムを使えば、遅延は全くなくなることになり、全体での遅延は往 復 156 ms になる。

こうしてシリアルポートが原因となっている遅延を克服したら、次に問題 となるのはモデム自体に組み込まれている 50 ms のオーバーヘッドだ。な ぜ固定された 50 ms のオーバーヘッドが存在するのだろうか? その理由 は、最近のモデムが多くの“機能”、つまりデータ圧縮やエラー訂正機能 を搭載しているからだ。効率的に圧縮とエラー訂正を行うためには、モデ ムはデータをブロック化して扱わなければならない。つまり、送られてき たデータは、モデムが効率的に扱うことができるだけの量に達するまでバッ ファに溜めておかれることになる。データがモデムのバッファに溜ってい く間、電話回線に送り出されていくデータが途絶えることになる。たとえ ば 100 バイトの小さなデータを送りたいとしよう。これではモデムが効率 的に扱うためには小さすぎるので、もっと大きなブロックが好ましいのだ。 この 100 バイトを受け取った後、モデムはもっとデータが送られてこない か待つ。しばらく(約 50 ms)して、もうデータが来ないと判断したら、 モデムはデータを圧縮して送り出す。モデムが来るはずのないデータを待っ て過ごす 50 ms は取り返すことのできない無駄使いされた時間なのだ。

モデムはそもそもリモートターミナルアクセス用に開発されたものだ。モ デムは一方ではユーザーが入力し、他方ではメインフレーム機から送信さ れる文字を小さなブロックにまとめて送るためのものだった。ユーザーが 入力を終えたこと(またはメインフレーム機が応答し終えたこと)を示す 唯一の目安は、データストリームが途絶えることだった。誰もモデムに 「これ以上はデータが来ないよ」と教えてあげなかったので、モデムは自 分で推測するしかなかったのだ。

しかし今では状況が違う。ほとんどの人はインターネットに接続するため にモデムを使うのであって、古いメインフレームに接続するのではない。 インターネット上のトラフィックは明確なパケットで構成されているので あり、文字の連続したストリームではない。

この問題には単純な解決法がある。モデムがインターネットパケットを送っ ていることがわかるようにしてあげればいいのだ。モデムが PPP(Point to Point Protocol)の End-Of-Packet キャラクタ(0x7E)を受け取った 時、パケットが終りだということに気が付いて、50 ms の間待ったりせず にただちに溜めてあるデータブロックを圧縮して送り出すのだ。この単純 な解決策で 50 ms の固定オーバーヘッドを取り除くことができ、モデムで PPP 接続をした際の遅延を往復 56 ms に抑えることができる。これなら今 日の標準的なモデムより 5 倍優秀なことになる。

[来週号では、Stuart はバンド幅と応答時間の関係、それにソフトウエア で応答時間の問題にどう取り組むことができるかについて述べる予定だ。]


非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

tb_badge_trans-jp2Valid HTML 4.01!Another HTML-lint gateway