-173-
V.32 だから 9600bps である。データ圧縮のプロトコルが併用されれば、もっ と速くなる場合もあるが、NIFTY-Serve においてはセンター側で 9600bps に速度 制限しているので、そんな速度は出ない。と書いたら 9600bps 出るのかと誤解さ れそうだから先に書いておくと、9600bps も出ないのである。「なぜか」という のが今回のテーマである。
アクセス手順は、AP の電話番号を除いて、FENICS ROAD-2 と同じである。手順 については、GO NODE の「1. NIFTY-Serve(ESを含む) アクセス方法」の下のメニ ュー、「5. FENICS-ROAD 3 経由」に掲示されている。この掲示だが、いや慌てた ようで、変な所が何ヶ所かある。例えば、
> 2. FENICS-ROAD3に接続後、約 2秒後に以下が表示がされます。という表現。「以下が表示がされます」というのは、日本語としてはおかしい と思うのだが、よほどスケジュールが大変で、校正に十分な時間をかける暇がな かったのだろう。しかし、このような些事に対して揚げ足を取っても別に面白く も何ともないし、誰かセンター宛メールなどで指摘して、いつの間にか修正され ておわり、というパターンになると思うので…え、私が連絡しろって？ そりゃ そうだが。
「２． FENICS-ROAD 3 利用上のご注意」に７項目の注意事項が書いてある。ざ っと要点をまとめると、以下の通りである。
さて、ここで問題にしたいのは、5である。この項目のみ全文引用させてい ただく。内容は 5/1 現在のもので、GO NODE で閲覧できるので、実際に確かめて 欲しい。
現在、市販されている通信ソフトは、ほとんどのものが 9600bpsを使えるよ うになっておりますが、通信ソフトによっては、通信ソフト側の問題で 9600bps の実効速度がでない場合があります。 又、ユーザーのパソコン・ワープロの、画面に文字を表示する時間や処理速 度等により、実効速度が 9600bpsとならないことがあります。ご注意くださ い。さて、どう解釈したらよいか。このコラムは、実際にソフトウェアを作って飯 を食っている人も、あるいは趣味として通信ソフトを作った経験のある人も読ん でいると思うので、具体的に考えてみよう。通信ソフト側の問題で9600bps の実 効速度がでない場合があるか？ 確かにある。文字の表示が遅かったり、その他 の処理で実効速度が 9600bpsとならないことがあるか？ そういうこともある。 9600bps というと秒あたり 960 バイト、とすると 1 行 80 バイトで換算して、 12 行を１秒以内に表示しなければならない。これはビットマップディスプレイの 描画時には、結構厳しいかもしれない。(*1)
実際に、V.32 のモデムで FENICS-ROAD3 に接続して、「ＲＯＭ墓場からの声」 などをダウンロードして、測定した結果があるので紹介する。通信ソフトは ULTmini、パソコンは PC-386M で、ログはなんとフロッピー上に作成した。速度 としては不利だが、ハードディスク上にログを作ると文字化け（文字バケ？）が 発生するのである。これはハードディスクのキャッシュのせいだと誰かに教えて もらった。9600bps で接続したら、1M (って何バイトだ？) のフロッピーなんて、 一瞬のうちに（大袈裟だが）DISK FULL になるので、何とか対策を考えておかな ければならないが…。
5/1 10:00 頃
528 bytes/s (248558 bytes / 471 s)
598 bytes/s (138152 bytes / 231 s)
5/2 09:30 頃
649 bytes/s (175970 bytes / 271 s)
621 bytes/s (245393 bytes / 395 s)
成程、このように通信ソフト側の問題というのも結構深刻なようである。秒あ
たり 600 バイト程度の速度しか出ないというのは、9600bps の理論値では 960
バイト／秒まで出るはずだから、表示の影響というのもこの速度になると無視で
きない、という結論になるようだ。
ちなみに、全く同じ条件で某ネットにアクセスしてみた。(*2)
5/2 10:00 頃
1057 bytes/s (267471 bytes / 253 s)
通信ソフトによっては、通信ソフト側の問題で 9600bps 以上の実効速度が出る
場合もあるらしい。
*
さて、今 V.32 のモデムはお買い得か？ これについて考えてみた。
実際に NIFTY-Serve の V.32 東京 AP に接続した結果、500〜650 バイト／秒 という速度が出ている。このデータを得た時間帯に注目して欲しい。特に、5/2 のデータは、かなり空いている時間帯である。ピークタイムである夜間〜深夜に かけては、これよりも遅くなる可能性が高い。しかし、2400bps AP の場合の測定 値は 160〜200 バイト／秒である。従って、速度としては約 2.5 〜 3 倍程度と 考えてよいだろう。
NETWORKER という雑誌の 1992 年春号に、FENICS-ROAD3 を ISDN 経由で使って いるユーザーの声が出ている。この記事によると「実効速度は 2400bps の場合の ２倍程度」らしいのだ。先程の 650 バイト／秒というのは、240 バイト／秒の倍 よりは随分速い。
NIFTY-Serve の基本料金は、高速回線の場合 25円／分である。実効速度 2.5〜 3 倍なら、損はしない、と一見考えてしまいがちである。しかし、落とし穴が２ つある。まず、インタラクティブな処理は、高速回線を使っても速くならない、 ということ。１行ずつエコーバックを待って発言したり、BRN コマンドで読んだ りするのなら通常回線の方が断然有利である。もう一つは、課金が分単位で行な われることである。数分単位でこまぎれのアクセスをする場合には、切り上げて 課金される分が無視できない。
以上の前提を考慮した上で、さらにもう一つ見落としてはならない問題がある。 東京 AP がずっと話中で、ぜんぜんつながらないのだ。
紹介したデータのうち、5/1 のデータは、15 分のリダイアルの末接続したもの である。5/2 のデータは、まず 30 分程度接続を試みたが接続できず、その後数 時間たって再度挑戦して、20 分のリダイアルの後接続に成功したものである。
回線数が不足しているのか、あるいは利用者が非常に多いのかは判断しかねる が、要するに非常に混雑しているのである。余談ながら、さらに悪いことに、話 中でないが、電話を取ってくれないことがあった。RING 状態が続いて、そのうち NO CARRIER で切れるのである。何か不安定な要因でもあるのだろうか。
さて、結論としてはどうか。電話料金は節約になるだろう。しかし、課金は節 約になるかどうか微妙である。回線は非常に混雑している。しかし、NIFTY-Serve の戦略としては、今後 V.32 回線を今後増強する傾向が予想される。
これらの状況を総合すると、
*
通信メディアの最も重要な条件は、「いつでも使える」ということである。
NIFTY-Serve もこれを目標としていたと思う。なぜこんな当然のことを書くのか、
という裏には、現状がこれを達成していないという事実があるからだ。これは特
に実用性という意味で重要なことである。特に、いつ使えるかわからないメディ
アをビジネスに使うことは、ためらう人が多いはずだ。
「いつでも使える NIFTY-Serve」を実現するためには、十分な回線数、性能、 信頼性という３つの柱が必要である。
残念ながら、話中が多いというのは、回線数が足りない証拠であり、「サービ スはただいま混在しております」という表示が出るのは、（文字通り解釈すれば） 性能が不足している証拠であり、いきなり落とされたりするのは信頼性が足りな い証拠である。
いきなり落ちるなんてことがあるのかというと、混雑時にはあるようだ。5/1、 FPROGでは「ROM墓場からの声」の埋め立て作業があり、一斉に電子会議 に書き込みが集中したようだが、この時「発言する」を選択した直後、無反応と いう障害に遭遇した。結局、FENICS まで落とされた後、再ログインした時には、 会議室は 512 発言まで埋まっていた。ROM墓場恐るべし。
5/2 の 3:00 頃、FPROGでは定期リアルタイム会議を行っていた。この時 間はハロータイムと呼ばれている。3:00 〜にアクセスを始めれば、課金が 2 割 引きになるので、一旦ログアウトして、接続し直す人が多い。ところが、この時 は一旦ログアウトしたら、再接続できないというトラブルが発生した。 FPROG以外でも広範囲に発生したようである。これも信頼性に疑問を感じさせた一件 である。
そりゃ特殊な状況だろう、という指摘はその通りなのだが。
(*2) おそらくアスキーネットだと思う。
(*3) これも昔話と解釈して欲しい。ちなみに、1996年2月現在、FENICS-ROAD5が似た状況になっているが、当時と比べて大きな違いが二つある。まず、料金がROAD4と同じであること。従って、速い回線を使える方が、当然トクである。そして、速度である。東京ROAD5は、実測値で、30,000bps程度を超えることもある。特に、ログを一括表示する時には軽快である。もちろん、時間帯の影響はあるかもしれないが。
当時と同じ現象も発生している。話中で、全然繋がらないのだ。
COMPUTING AT CHAOS RUINS -173-
1992-05-04, NIFTY-Serve FPROG mes(3)-134
FPROG SYSOP / SDI00344 フィンローダ
(C) Phinloda 1992, 1996