On 6/10/07, Kazumaro Aoki <[EMAIL PROTECTED]> wrote:
> いまどきのハードウェアであれば、 数MBぐらい使用しても問題ないと思います。 > （一応 kernel 内の wired page なので、 いくらでも大きくできるわけではないですが） > 適当なパラメータが見つかりましたら、 是非教えてください。 デフォルトを変更します。 数分間試した感じではこんな感じです。NCHUNKのみを大きくしてみました。 1. NCHUNKはいくら大きくしても、USB storage相手の読み書き(でかいファイ ルのcp)と並行してfwcontrol -Rしていると、overrunが起きるまでの時間 が長くなるもののいずれ、連続して取りこぼすようになる。
これは、 fwcontrol -R で書き込んでいる disk と USB storage 間の転送でしょうか？ このとき top や ps での STATE MWCHAN は何になっていることが 多いでしょうか？ これを見ると、 どこで block されているのかわかります。
2. fwcontrol -R中にdd if=/dev/zero of=hoge bs=32mを同じHDに対して実行。 NCHUNK=32ぐらいだと、回数は減るがやっぱりoverrunが発生。NCHUNK=64に すると出なくなった。なお、実験に使ったHDは ad0: 238475MB <HDS722525VLAT80 V36OA6MA> at ata0-master UDMA100
まあ、 これをやると、 disk i/o になんらかのプライオリティを付けてあげないかぎりは なかなか難しいですね。 一時的なdisk 帯域の低下は buffer を増やすことで 対処できますが、 入ってくるレートが出ていくレートより大きくなると、 遅かれ早かれ あふれます。
NCHUNK=64にしたもので、暫く(一週間ぐらい？)様子を見てみたいと思います。 一週間の間に30時間以上はfwcontrol -Rすると思います。 > 本質的な原因は、 以下の2つが考えられます。 > > 1. interrupt のサービスが遅れる > IRQ を share している 他の device driver が ithread を握りつづけている > 可能性や、 USB と FireWire driver(6-stable) は共に Giant lock が > 必要で同時に動作できないこと、 なとが考えられます。 > FreeBSD-current の FireWire driver は ithread を使用しないで, > fast interrupt(interrupt filter) を使用し、 Giant free なので > interrupt latency が小さいと思います。 もし機会があればお試しください。 > > 2. storage のスピードの問題. > DV では定常的なスピードが要求されます。 sync のために 1秒とか disk i/o > ブロックされると fwcontrol の packet の読み出しも止まってしまい、 buffer > が溢れます。 この手の問題には, /usr/ports/misc/buffer のようなものを > 使って出力を buffering するのも手かもしれません。 > （fwcontrol で aio(4) とか multi-thread化するのは面倒なので） ithreadとかGiant lockとかは用語はどこかで見たことはありますが、知識が 無いので理解は出来ていませんが、FreeBSD-currentとか使う機会があったら 試したいと思います。また、ports/misc/bufferも今回初めて知りました。こ れも、問題解決に使えそうな感じがするので、NCHUNKを増やしたfwcontrol -R の調子が期待ほどにはならなかった場合は、試してみたいと思います。
1点だけ確認させてください, fwohci と IRQ を share しているものはありますか？ （例えばUSBとか） あと, AV/C という AV機器を FireWire からコントロールする規格があるのですが、 最近の6-stable と 7-current で動く, 実験的なコードがあります。 どなたかテストしていただける方がいたら、 私のほうまでメールを頂けたらと思います。 （どのような機器があるかの情報を含めて） 実際テストをお願いするのは、 しばらく先になるかもしれませんが。。。。 -- /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED]
