まず、前回で未解決だった問題。
あと、src_send.py からの nc と tar によるファイルコピーで、 サイズが大きいと落ちる現象が出てしまうのですが、、、 原因が突き止められてません(>_<)
判りました。
色々試してみると、 sshでリモートマシンに手動でログインして、手動でcmd.pyを起動した場合では何の問題も出ず。 cmd_send.py で cmd.py をリモートマシンに送りつけて起動すると、問題が出ます。 怪しい。
cmd_send.py の
rmt_cmd = 'cd /tmp ; tar xf - ; ./cmd.py port={}'.format( get_port(lcl_base, cmd) )
cmd = 'tar cf - cmd.py | ssh {} {} {} "{}"'.format(opt_exp, opt_fwd, rmt_host, rmt_cmd)
ここ!
ここで、リモートマシン側で ./cmd.py を起動するときの標準入力が、 sshを経由して、接続元のローカルマシンで流し込んだ 「tarデータの終端」が見えてる状態になってました。
cmd.pyから起動する全てのコマンドの標準入力は、この状態を受け継いでました。 ファイルコピー用のデータを受け取るncコマンドも例外やおまへん。 ncは標準入力から読み込み、接続先のソケットに送信しようとしますが、 標準入力では「データの終端」EOFが見えてるので、終了してしまう。
さてどうしたものか。 発想を切り替えて、ファイルコピー時はローカルマシン側でncをサーバに、 リモートマシン側でncをクライアントにして対応してみました。
ローカルマシン側でncサーバをたてて、誰かが繋ぎにきたらtarデータを送りつけます。
リモートマシン側ではssh経由でncクライアントを起動して、ローカルマシンに繋ぎにいきます。 繋がるとtarデータが流れてくるので、tarコマンドで受けて展開します。
これでsshの標準入力にtarデータを流さずともよろしかろうと。
あと明日への布石のため、動画を書き込む処理を画像サーバに含めてしまいました。
こうしておけば、複数のレイトレサーバが個別にピクセルを処理した後、 おのおのが画像サーバに結果を渡せるようになるはずです。 レイトレサーバに一度に複数のピクセルを処理させるための変更が、楽になりそうです。
$ mv rt_v33 rt_v34 $ cat v34.patch | ( cd rt_v34 ; patch -p1 ) $ cd rt_v34 $ make clean $ make
では、速度確認。
$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=objs name=out_v34/objs_1_2_sc n=1 init_sec=5 div=2 : wh : 76800/76800(100.0%) : fin 38.47s
以前の v32 wh : 76800/76800(100.0%) : fin 26.84s v31 wh : 76800/76800(100.0%) : fin 40.50s v30 wh : 76800/76800(100.0%) : fin 38.39s v29 wh : 76800/76800(100.0%) : fin 1m 44.72s v28 wh : 76800/76800(100.0%) : fin 1m 18.06s v27 wh : 76800/76800(100.0%) : fin 1m 8.39s v26 wh : 76800/76800(100.0%) : fin 1m 6.02s
速度的には後退。 まぁそうなりますよね。 明日への布石という事で。
視点移動の高さ方向を抑制してみてobjsのデータを眺めてみます。
$ ./cg.py eyep=[0,0,12],[100,100,10],10 sec=10 data_name=objs name=out_v34/objs_tst div=4 fps=1 : wh : 18860/19200(98.2%) : total 14.25s : rest 0.25s : 2018/05/09 01:29:10 wh : 19200/19200(100.0%) : fin 14.27s frm : 10/10(100.0%) : fin 2m 10.59s
( 2*60+10.59 ) * 4 * 4 * 30 / 60 / 60 = 17.41 時間の予想
$ ./cg.py eyep=[0,0,12],[100,100,10],10 sec=10 data_name=objs name=out_v34/objs : wh : 307200/307200(100.0%) : fin 3m 41.64s frm : 300/300(100.0%) : fin 17h 46m 26.78s
ほぼ予想時間通りでした。
ベンチマークでさんざんしがんだデータでも、視点を変えてみるとまた違った味わいがありますね。