#68 Article 4817 Posted at 1994/10/30 03:05:40 by MSP-Iris (MAP4370) [BATCH]
Subject: 転送効率論・再燃
バッチシステム導入直後に結構激しかった効率論ですが、最近再燃して
きたようです。で、あたしも当時から通信環境を改善しましたし、もう一
度初心に帰って考えてみることにしました。
・実験端末
PC286VG(80286/16M) + PCLINK-296SX (V32+LAPM-V、DTE38400)
ファイルはすべて RAMDISK へ転送（Hardware EMS + rz4、EMM未使用）。
ソフトは ktx ver1.26、常駐物は WX2+VJ2 ver2.56 と ezkey のみ。
・実験方法
ランダムサンプリングということで、未読のいっぱいあるボードをだいたい
３等分して、それぞれ非圧縮バッチ／圧縮バッチ／ベタ読みでダウンする。
これを数ボード実行する。
消費時間の計測はホストの時計を利用する。
・実験結果
１．非圧縮バッチ
コマンドは batch -n -z です。理論的に Zmodem が最速のはずなので、これ
をもって代表とします。
平均値 #A #B #C #D ボード
86.1kB 133.3kB 87.6kB 178.5kB ファイルサイズ
46sec 60sec 42sec 86sec Zmodem 転送時間
2063cps 1872cps 2222cps 2084cps 2075cps Zmodem 転送速度
15sec 18sec 15sec 21sec 転送ファイル作成時間
61sec 78sec 57sec 107sec 総消費時間
1581cps 1411cps 1709cps 1537cps 1668cps 総合転送速度
転送ファイル作成時間とは、バッチコマンド実行時に処理内容をファイルに作成
する時間です。総合転送速度とはファイル作成時間を加味した転送速度です。
ファイル作成時間は以下のように一次近似で概算できます。
t(makefile) =(filesize kB / 13 kB/sec)+ 8 sec
２．圧縮バッチ
コマンドは batch -gzip -z です。-lha よりも -gzip の方がパフォーマンスが
良いというのは散々言ってきた（かつ言われてきた）ことなので、これをもって
代表とします。
平均値 #A #B #C #D ボード
**** 171.6kB 93.5kB 201.8kB ファイルサイズ
**** 77.4kB 31.6kB 61.3kB 圧縮後サイズ
36% **** 45% 34% 30% 圧縮率
**** 71sec 29sec 57sec Zmodem 転送時間
1085cps **** 1089cps 1090cps 1076cps Zmodem 転送速度
**** 48sec 29sec 59sec ファイル作成圧縮時間
**** 119sec 58sec 116sec 総消費時間
1598cps **** 1442cps 1612cps 1740cps 総合転送速度
ファイル作成圧縮時間とは、バッチコマンド実行時に処理内容をファイルに作成
し、圧縮する時間です。総合転送速度とはファイル作成圧縮時間とファイル圧縮率
を加味した転送速度です。一応、非圧縮のデータに若干勝ってはいます。
ここで、#A のデータがありませんが、これはホストのバグによりファイルを
数ｋＢ作ったところでバッチが中止されたため、データの信憑性に疑問がある
ためです。
圧縮にかかる時間は以下のように一次近似で概算できます。
（だれか時間のある方、最少二乗法して下さい）
t(compress) = filesize kB / 6.5kB/sec
３．ベタ読み
コマンドは bbs read です。ただのダイレクトコマンドです。このときはマクロ
から display_off と backlog_stop してあり、受信バッファはたまっていません。
マシンは完全にモデムについていってます。
平均値 #A #B #C #D ボード
76.5kB 114.5kB 53.2kB 130.7kB ファイルサイズ
61sec 57sec 38sec 62sec 総消費時間
1254cps 2009cps 1400cps 2108cps 総合転送速度
なにも変わった手段を用いていませんので、総合転送速度は単にサイズ／時間
になります。あまりにも数値がばらばらなので平均値は算出してありません。
・考察
１．バッチによる総合転送時間の概算式は以下の通りである。
time(-n) =(filesize kB / z_rate(-n) kB/sec)+ t(makefile)
time(-gzip)=(filesize kB * comp_rate / z_rate(-gzip) kB/sec)
+ t(makefile) + t(compress)
ただし、z_rate(-n) = 2.06
z_rate(-gzip) = 1.09
comp_rate = 0.36
t(makefile) =(filesize kB / 13 kB/sec)+ 8 sec
t(compress) = filesize kB / 6.5kB/sec
filesize = 100kB とすると、
time(-n) =100/2.06+100/13+8 =48.5+7.7+8 =64.2sec
time(-gzip)=100*0.36/1.09+100/13+8+100/6.5=33.0+7.7+8+15.4=64.1sec
となり、実は大差がないという結果となった。
なおかつ、-n の方はモデムに圧縮機能をまかせているため、ホストが重い時でも
同等のパフォーマンスを発揮するであろうことが予想される。
２．ベタ読みの転送速度は信頼できる値を得ることができなかった。これはベタ読み
が様々な状況の変化によって速度が急変する、言い換えればホストの状態に非常に
センシティブであるからであると思われる。理論的には転送ファイル作成時間が
ない分だけ、非圧縮バッチよりもベタ読みの方が速いはずであるが、どうもそう
簡単にはいかないようである。端末側のバッファはまったくたまっていないので、
これはホスト側のスピードダウンである。
３．いままで、「9600 では -gzip」と主張してきたが、今回の結果では -n と
-gzip とはほぼ同等の速度であった。これは以前に行った実験と今回とでは通信
環境が異なるからである。以前は Wterm の、それも ver9.20 位で、しかもファイル
書き出しは遅い HDD (seek23ms)であったのが、現在は ktx と高速 ramdisk-driver
である。とくに ktx の力は絶大で、地元につないでいる時のベタ読み効率は
１．５倍以上になっている。
以上の結果をふまえて、これからはこういう意見に鞍替えすることに決定。
9600+Wterm 9600+ktx 14400+ktx
<-- -gzip 優位-->+<-- -n 優位-->
もっとも、これは286/16M程度のマシンパワーの時の話であって、486マシンならば
Wtermでも十分な速度を出すことが可能であろう。
・謝辞
この実験のきっかけを与えてくれた 河合_純さん、NLさんに感謝いたします。
＃長文失礼。
MAP4370 MSP-Iris