MacBook Airの冷却構造を調べてみた ��
前回調べた旧Airの冷却構造を踏まえつつ新Airの構造を調べてみます。
で、新Airを見てみるとこんな感じです。
CPUとチップセットの上にそれぞれヒートシンクがネジ4本で十字に固定されており、二つのヒートシンクの
中心をヒートパイプが通っています。ヒートパイプ右端部にある四角い部分は冷却フィンが取り付けられた
ブロックだと考えられます。さらにブロックの上から別の部品が嵌めこまれ、冷却フィンとその下にある
シロッコファンの接続部から吹き出す風が逃げないようにカバーしているように見えます。
冷却フィンとファンの位置から考えて、ファンから吹き出す風が直接冷却フィンに当たりヒートパイプから
伝わった熱を排出する、という流れになっていると考えられます。前回の扇風機でたとえるなら、ちゃんと
扇風機の正面に立って直接扇風機からの風を受けて冷している感じです。
このファンと冷却フィンの位置やヒートシンクの構造はAir以外のMB、MBPなどのノートとほぼ同一です。
これで新Airの底面に給気用のスリットがなければ他のモデルと全く同じ構造・空気の流れになり、
これまでに実績のある冷却構造を新Airでも採用したということになりそうです。
新Airの実物を見に行きたいところですが、近所にアップルストアなどは無いわけでorz。
仕方がないので写真を探してみても、新Airの写真はいろいろあるものの肝心の底面が写ってる画像がなく、
あちこち探したところengadgetのこちらのページでやっと発見。
やや奥のほうでボケていますが新Airの底面には給気用のスリットは空いていない様に見えます。
ほかに参考になるものはないかと探してみたらアップルのデモビデオで底面が映るシーンを発見。
2:30あたりと2:40あたりを見ると底面に給気口はない模様。
となると新Airはアップルの他のノートと同様に、キーボード面などの隙間から吸気、液晶パネルのヒンジの
根元部分から排気する構造でほぼ間違いないと思われます。
ただ冷却構造の静音性や冷却性能を他のメーカーと比べるといまいちアップルの設計は必要最低限というか
もうすこし頑張ってもいいんじゃ？と思うものもあるので期待しすぎは禁物かもしれませんが。
なんにせよ旧モデルと比べて新Airの冷却構造は著しく改善されたと言って差し支えない内容かなという印象。
と購入に向けて自分を納得させるテスト。
で、新Airを見てみるとこんな感じです。
CPUとチップセットの上にそれぞれヒートシンクがネジ4本で十字に固定されており、二つのヒートシンクの
中心をヒートパイプが通っています。ヒートパイプ右端部にある四角い部分は冷却フィンが取り付けられた
ブロックだと考えられます。さらにブロックの上から別の部品が嵌めこまれ、冷却フィンとその下にある
シロッコファンの接続部から吹き出す風が逃げないようにカバーしているように見えます。
冷却フィンとファンの位置から考えて、ファンから吹き出す風が直接冷却フィンに当たりヒートパイプから
伝わった熱を排出する、という流れになっていると考えられます。前回の扇風機でたとえるなら、ちゃんと
扇風機の正面に立って直接扇風機からの風を受けて冷している感じです。
このファンと冷却フィンの位置やヒートシンクの構造はAir以外のMB、MBPなどのノートとほぼ同一です。
これで新Airの底面に給気用のスリットがなければ他のモデルと全く同じ構造・空気の流れになり、
これまでに実績のある冷却構造を新Airでも採用したということになりそうです。
新Airの実物を見に行きたいところですが、近所にアップルストアなどは無いわけでorz。
仕方がないので写真を探してみても、新Airの写真はいろいろあるものの肝心の底面が写ってる画像がなく、
あちこち探したところengadgetのこちらのページでやっと発見。
やや奥のほうでボケていますが新Airの底面には給気用のスリットは空いていない様に見えます。
ほかに参考になるものはないかと探してみたらアップルのデモビデオで底面が映るシーンを発見。
2:30あたりと2:40あたりを見ると底面に給気口はない模様。
となると新Airはアップルの他のノートと同様に、キーボード面などの隙間から吸気、液晶パネルのヒンジの
根元部分から排気する構造でほぼ間違いないと思われます。
ただ冷却構造の静音性や冷却性能を他のメーカーと比べるといまいちアップルの設計は必要最低限というか
もうすこし頑張ってもいいんじゃ？と思うものもあるので期待しすぎは禁物かもしれませんが。
なんにせよ旧モデルと比べて新Airの冷却構造は著しく改善されたと言って差し支えない内容かなという印象。
と購入に向けて自分を納得させるテスト。
MacBook Airの冷却構造を調べてみた ��
やっと発表されたMacbook Airの新モデル。
初代モデルからAirは気になっていたのでネットでいろいろチェックしていました。
そんな従来のモデルから比較して気になる部分といえばCPUの冷却構造です。
初代モデルではCPUの冷却が不十分なのかせっかくのデュアルコアなのに、CPU負荷が
大きくなると片方のコアが熱のため停止してシングルコア動作になってしまうという
いわゆる『片肺問題』が報告されていました。
以降のモデルではある程度改善されたのか、片肺とまではいかないもののCPU負荷が
大きくなるとファンがうるさい、CPU付近がやたら熱くなるなどの指摘が目につきました。
新モデルも調べたいところですがいい機会なので旧モデルの冷却構造も参考のため調べてみました。
旧モデルの分解についてはifixitが詳しい。冷却に関連ありそうな部分はこんな感じ。
空気の流れとしては製品内部に給気ファンがあり、底面に開けられた給気口から外気を取り入れて
いるようです。CPUとチップセットには一体型のヒートシンクが装着されています。ヒートシンクの
端部が給気ファン周囲にまで伸びており、ファンから周囲に散る風がヒートシンクに当たることで
CPUとチップセットを冷却するという感じです。
ただヒートシンクは薄い金属製の板一枚でCPUやチップセットに接触するヒートパイプも無いように
見えます。もしかするとファンの右側をかすめてヒートシンクの外周を下側に向けてぐるっと回ってる
細い凸形状の部分がヒートパイプかもしれませんがCPUやチップセットのコアからも遠くあまり効果が
あるようには見えません。
ヒートシンクの固定もL字型の薄い金具をヒートシンクの中央にネジ一本で固定して押えているだけの
ように見えます。
またファン周囲の構造を見てもダクトなどで積極的に風を送るのでなく、給気ファンが吸った空気が
なんとなくヒートシンクの周囲に流れるというような感じです。この配置を扇風機に例えるならば、
扇風機の正面に立つのではなく、わざわざ後ろに回って周囲の風が扇風機に吸い込まれる流れで
冷やそうとしているようなものです。
これは厳しいというか、厳しかったに違いないという印象。
で、本題の新Airについてはこちらに分けました。
初代モデルからAirは気になっていたのでネットでいろいろチェックしていました。
そんな従来のモデルから比較して気になる部分といえばCPUの冷却構造です。
初代モデルではCPUの冷却が不十分なのかせっかくのデュアルコアなのに、CPU負荷が
大きくなると片方のコアが熱のため停止してシングルコア動作になってしまうという
いわゆる『片肺問題』が報告されていました。
以降のモデルではある程度改善されたのか、片肺とまではいかないもののCPU負荷が
大きくなるとファンがうるさい、CPU付近がやたら熱くなるなどの指摘が目につきました。
新モデルも調べたいところですがいい機会なので旧モデルの冷却構造も参考のため調べてみました。
旧モデルの分解についてはifixitが詳しい。冷却に関連ありそうな部分はこんな感じ。
空気の流れとしては製品内部に給気ファンがあり、底面に開けられた給気口から外気を取り入れて
いるようです。CPUとチップセットには一体型のヒートシンクが装着されています。ヒートシンクの
端部が給気ファン周囲にまで伸びており、ファンから周囲に散る風がヒートシンクに当たることで
CPUとチップセットを冷却するという感じです。
ただヒートシンクは薄い金属製の板一枚でCPUやチップセットに接触するヒートパイプも無いように
見えます。もしかするとファンの右側をかすめてヒートシンクの外周を下側に向けてぐるっと回ってる
細い凸形状の部分がヒートパイプかもしれませんがCPUやチップセットのコアからも遠くあまり効果が
あるようには見えません。
ヒートシンクの固定もL字型の薄い金具をヒートシンクの中央にネジ一本で固定して押えているだけの
ように見えます。
またファン周囲の構造を見てもダクトなどで積極的に風を送るのでなく、給気ファンが吸った空気が
なんとなくヒートシンクの周囲に流れるというような感じです。この配置を扇風機に例えるならば、
扇風機の正面に立つのではなく、わざわざ後ろに回って周囲の風が扇風機に吸い込まれる流れで
冷やそうとしているようなものです。
これは厳しいというか、厳しかったに違いないという印象。
で、本題の新Airについてはこちらに分けました。
『さんかれあ』の紫陽町が地元すぎる件
気づいたらはっとりみつるの最新作『さんかれあ』の単行本が出てたので買ってきた。
というかアマゾンでお届けされてみた。
予約受付時の表紙イラストでドレスが紫色だったり髪飾りのデザインが紫陽花ぽいので
なんか紫陽花が話の小道具とかネタに関係あるのかねとちょっと気になってたわけで。
そういえば奇遇にもうちの地元もあじさい祭りとかやってるよなぁ
なんて思いつつ届いた単行本読んでみたら、まんまロケーションが地元周辺地域で吹いた。
どうみてもK県足倉郡って神奈川県足柄上郡w
読み進んでいくと、どこかで見たような背景がちらほらとあってつい気になる。
どこかで見たというよりも、地元民ならほぼ特定可能な感じ。
川沿いのサイクリングロードの鉄橋あたりの芝生のとこか、とか。
紫陽花が多いという設定は間違いなく開成町だけど、風景の様子や話中の地理的な
位置関係からすると、実際のロケーションは隣の松田町に相当する場所も多いっぽい。
あと一部大井町とか山北町も。
前作のウミショーがアニメ化されてるだけに、さんかれあもちょっと期待してたり。
ただそうなった場合、関東最古の神社で有名な埼玉の某所とかのアニメで町おこし的な
手法に乗っかろうとして、開成町観光協会がタイアップで町おこし的な悪ノリをしないかと
ドキドキです＞＜
ちょっとまえにこんなニュースを目にしていただけに”あじさいゾンビ祭り”とか無理矢理
やったりしないかと妄想してみたが、これなんてカオスw
たまに某匿名巨大掲示板のアニメ関連スレなどで聖地巡礼や現地特定の話がでると
”こんな場所よく分かるな→地元民なら探さんでも分かる”、とか
”地元経済にプラスになるからいいだろ→静かな住宅地にわざわざ来るな。ウザい”
的な流れを見かけるけど、ちょっとだけその気持ちが分かりましたw
漫画の話自体ももちろんですが、その他いろいろも含めて2巻が楽しみですw
というかアマゾンでお届けされてみた。
予約受付時の表紙イラストでドレスが紫色だったり髪飾りのデザインが紫陽花ぽいので
なんか紫陽花が話の小道具とかネタに関係あるのかねとちょっと気になってたわけで。
そういえば奇遇にもうちの地元もあじさい祭りとかやってるよなぁ
なんて思いつつ届いた単行本読んでみたら、まんまロケーションが地元周辺地域で吹いた。
どうみてもK県足倉郡って神奈川県足柄上郡w
読み進んでいくと、どこかで見たような背景がちらほらとあってつい気になる。
どこかで見たというよりも、地元民ならほぼ特定可能な感じ。
川沿いのサイクリングロードの鉄橋あたりの芝生のとこか、とか。
紫陽花が多いという設定は間違いなく開成町だけど、風景の様子や話中の地理的な
位置関係からすると、実際のロケーションは隣の松田町に相当する場所も多いっぽい。
あと一部大井町とか山北町も。
前作のウミショーがアニメ化されてるだけに、さんかれあもちょっと期待してたり。
ただそうなった場合、関東最古の神社で有名な埼玉の某所とかのアニメで町おこし的な
手法に乗っかろうとして、開成町観光協会がタイアップで町おこし的な悪ノリをしないかと
ドキドキです＞＜
ちょっとまえにこんなニュースを目にしていただけに”あじさいゾンビ祭り”とか無理矢理
やったりしないかと妄想してみたが、これなんてカオスw
たまに某匿名巨大掲示板のアニメ関連スレなどで聖地巡礼や現地特定の話がでると
”こんな場所よく分かるな→地元民なら探さんでも分かる”、とか
”地元経済にプラスになるからいいだろ→静かな住宅地にわざわざ来るな。ウザい”
的な流れを見かけるけど、ちょっとだけその気持ちが分かりましたw
漫画の話自体ももちろんですが、その他いろいろも含めて2巻が楽しみですw
Ubuntu10.04でepgrec
昨日に引き続きいろいろやってみた。
epgrecの設定で何か所か嵌ったんでメモ。
・番組情報取得の際にgetepg.phpから呼ばれるepgdumpがsegmentation faultで
こっそりと落ちるせいでtsファイルがあるのに番組表のデータが更新されない罠。
up0200.gz、up0246.zip、up0248.zipのパッチ適用とroot権限で動作でほぼ問題無し。
・ブラウザ上で設定をする際のパスの指定に注意。
"録画保存ディレクトリ"と"サムネール保存ディレクトリ"は/var/www/epgrecからの相対パス。
"EPG取得用テンポラリファイル"は絶対パス。
これが間違ってると予約録画の登録をしてもatの指定時間にrecfriioが起動しない。
・上記で指定したフォルダはパーミッションは755でグループをwww-dataにしておくこと
面倒くさいとかセキュリティを気にしないなら777でも可。
epgrecの設定で何か所か嵌ったんでメモ。
・番組情報取得の際にgetepg.phpから呼ばれるepgdumpがsegmentation faultで
こっそりと落ちるせいでtsファイルがあるのに番組表のデータが更新されない罠。
up0200.gz、up0246.zip、up0248.zipのパッチ適用とroot権限で動作でほぼ問題無し。
・ブラウザ上で設定をする際のパスの指定に注意。
"録画保存ディレクトリ"と"サムネール保存ディレクトリ"は/var/www/epgrecからの相対パス。
"EPG取得用テンポラリファイル"は絶対パス。
これが間違ってると予約録画の登録をしてもatの指定時間にrecfriioが起動しない。
・上記で指定したフォルダはパーミッションは755でグループをwww-dataにしておくこと
面倒くさいとかセキュリティを気にしないなら777でも可。
Ubuntu10.04とHDUSF
サーバの環境をちょっといじったので、しばらく同じことはやりたくないなー
と思いつつ次作業するときのためにメモ。
1. 必要なパッケージの導入
2. 一度シャットダウンしてカードリーダを接続する
装置の接続と先ほどインストールしたパッケージに含まれている各種サービスの有効化のため
いちどPCをシャットダウンします。
次にカードリーダーとチューナをUSBに接続します。カードはまだ差し込まないでおきます。
USBケーブルがつながってることを確認したらPCを起動して次へ。
3. カードの読み取り状況の確認
カードをカードリーダに差し込みます。
正しい向きに差し込まれていればカードリーダのLEDがチカチカと点滅を始めるはずです。
カードの装着に問題なければ、カードの読み取りができるかチェックします。
出力に Japanese Chijou Digital B-CAS Card (pay TV) という文字列が
含まれていればOK。^X ^Cで終了して次へ。
4. チューナーのデバイスIDの確認
次のコマンドを実行してPCに接続されているUSBデバイスの一覧を表示させます。
出力された一覧に ID 1738:5211 というIDを持ったものがあるか確認してください。
これがファームウェアをロードする前のチューナーのデバイスIDです。
このIDが無い場合はUSBケーブルの交換や、別のコネクタへの接続などを試してください。
5. ソースにパッチを当てる
up0777.zip - recfriioのソース
up0127.zip - recfriioをhdusに対応させるためのパッチ
up0257.zip - hdus対応の改善パッチ
up0215.zip - 復号のためのパッチ
上記の書庫を展開していきます。
まずはup0777.zipを展開するとrecfriior4が出てくる
次にup0127.zipを展開するとhdus-recfriior4が出てくる
さらにup0257.zipを展開するとrecfriio-newpatchが出てくる
最後にup0215.zipを展開するとrecpt10.0.6patchが出てくる
ソースフォルダに移動してひたすらパッチを当てていく
次にb25復号のためのソースがあるフォルダに移動してそっちもパッチを当てる。
6. プログラムのビルド
ここでビルドエラーが起きるので下記の修正を加える
・RingBuf.hppの頭に #include を追加。
・setting.hpp, Recordable.hppの頭に #include を追加。
・Udp.hppの頭に #includeを追加。
・Makefile 32行目の -lboost_filesystem を -lboost_filesystem-mt に変更。
この辺まではネット上の情報として既出。うちの環境ではさらに修正が必要だった。
・IoThread.cppの頭に #include を追加。
・FriioBlack.cpp、FriioWhite.cppの頭に #include を追加。
で、ひとまずビルドが最後まで問題なく通ることを確認したら日経の記事を参考に
Hdp.cppとHdus.cpp、as11loader.cを修正していく。
以上の修正がすべて完了したら本番のビルド
recfriior4/recfriioとarib25v021/arib25/src/b25ができてるか確認したら
次はファームウェアのローダのビルド
こっちもちゃんとas11loaderができているか確認しとく。
7. プログラムのインストール
7. ファームウェアの準備と確認
ファームウェアを準備する。
ファームウェアが正しくロードできるか確認してみる
ファームウェアロード前はデバイスID 1738:5211として見えていたチューナが
デバイスID 3275:6051 VidzMedia Pte Ltdとして表示さるようになっていればOK
8. ファームウェアの自動ロード設定
中身はこんな感じ。
SUBSYSTEM=="usb", SYSFS{idVendor}=="1738", SYSFS{idProduct}=="5211", RUN+="/lib/udev/as11loader /lib/firmware/SKNET_AS11Loader.sys"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="3275", ATTRS{idProduct}=="6051", MODE="0644", GROUP="video"
1行目でチューナーが接続されたら手動でやってたファームウェアのロードを自動的に実行
2行目でファームウェアがロードされたチューナーに対してパーミッションの設定
9. テストしてみる
まずはチューナとカードリーダを一回わざと抜いて再度接続してみます。
これまでの手順で行ったように正しく認識され、各種設定が自動で行われているか確認しておきます。
問題なければ試しに録画してみます。放送局とチャンネルの対応はこんな感じ。
放送局名 ch
NHK総合 27
NHK教育 26
日本テレビ 25
テレビ朝日 24
TBS 22
テレビ東京 23
フジテレビ 21
東京MX 20
放送大学 28
復号あり、ドライバはhdusという設定で21chを30秒、rec.tsというファイル名で保存してみる。
vlcで保存されたファイルを開いて問題ないか確認しておきます。
ついでにwineが使える環境であれば念のため
としてドロップが発生していないか確認しておくと安心。
さらにもっと長い時間録画させつつ
として30秒ごとに計10回のシステムの状況をチェックしてみたりすると
録画時のPCの負荷状況が把握できたりするのでさらに安心。
ちなみにうちのBOXD510MOにRAM1GBのマシンでvmstatで見てみるとこんな感じ。
topも同時に実行してリアルタイムで見ていたけどCPUの使用率は25%以下に収まってる感じ。
専用マシンにするならD410でも十分ぽい。
ただ、このマシンはRAID1を組んでsmbサーバとして運用中。
なので録画とそれ以外のファイル操作が重なった状況を想定して、録画しつつ他のマシンから
ファイルを書き込んでテストしてみたけどCPU使用率はrecfriioが25%、smbdが40%という感じ。
保存ファイルをtsselectでチェックしてもドロップはゼロだったのでファイルサーバとしての
同時運用も問題なさげ。
・参考にしたもの
http://gedit.blog40.fc2.com/blog-entry-7.html
http://nagou.cocolog-nifty.com/haley/2009/01/ls-glhdus-fb77.html
http://blog.livedoor.jp/sakuranomorino/archives/51171774.html
某スレ 668 ：名無しさん＠編集中[sage]：2009/10/30(金) 21:02:25 ID:/LmhL6JR
と思いつつ次作業するときのためにメモ。
1. 必要なパッケージの導入
$ aptitude install libccid
$ aptitude install pcsc-tools
$ aptitude install build-essential
$ aptitude install linux-headers
$ aptitude install libboost-dev
$ aptitude install libboost1.40-all-dev
$ aptitude install libglib2.0-dev
$ aptitude install libpcsclite-dev
$ aptitude install libusb-dev2. 一度シャットダウンしてカードリーダを接続する
装置の接続と先ほどインストールしたパッケージに含まれている各種サービスの有効化のため
いちどPCをシャットダウンします。
$ shutdown now -h次にカードリーダーとチューナをUSBに接続します。カードはまだ差し込まないでおきます。
USBケーブルがつながってることを確認したらPCを起動して次へ。
3. カードの読み取り状況の確認
カードをカードリーダに差し込みます。
正しい向きに差し込まれていればカードリーダのLEDがチカチカと点滅を始めるはずです。
カードの装着に問題なければ、カードの読み取りができるかチェックします。
$ pcsc_scan出力に Japanese Chijou Digital B-CAS Card (pay TV) という文字列が
含まれていればOK。^X ^Cで終了して次へ。
4. チューナーのデバイスIDの確認
次のコマンドを実行してPCに接続されているUSBデバイスの一覧を表示させます。
$ lsusb出力された一覧に ID 1738:5211 というIDを持ったものがあるか確認してください。
これがファームウェアをロードする前のチューナーのデバイスIDです。
このIDが無い場合はUSBケーブルの交換や、別のコネクタへの接続などを試してください。
5. ソースにパッチを当てる
up0777.zip - recfriioのソース
up0127.zip - recfriioをhdusに対応させるためのパッチ
up0257.zip - hdus対応の改善パッチ
up0215.zip - 復号のためのパッチ
上記の書庫を展開していきます。
まずはup0777.zipを展開するとrecfriior4が出てくる
$ unzip up0777.zip次にup0127.zipを展開するとhdus-recfriior4が出てくる
$ unzip up0127.zipさらにup0257.zipを展開するとrecfriio-newpatchが出てくる
$ unzip up0257.zip最後にup0215.zipを展開するとrecpt10.0.6patchが出てくる
$ unzip up0215.zipソースフォルダに移動してひたすらパッチを当てていく
$ cd recfriior4/recfriior4
$ patch -p1 < ../../hdus-recfriior4/recfriior4.diff
$ patch -p1 < ../../recfriio-newpatch/recfriior4-newhdus.patch次にb25復号のためのソースがあるフォルダに移動してそっちもパッチを当てる。
$ cd ../arib25v021
$ patch -p1 < ../../recpt10.0.6patch/arib25v021_023.patch6. プログラムのビルド
$ cd recfriior4/recfriior4
$ makeここでビルドエラーが起きるので下記の修正を加える
・RingBuf.hppの頭に #include
・setting.hpp, Recordable.hppの頭に #include
・Udp.hppの頭に #include
・Makefile 32行目の -lboost_filesystem を -lboost_filesystem-mt に変更。
この辺まではネット上の情報として既出。うちの環境ではさらに修正が必要だった。
・IoThread.cppの頭に #include
・FriioBlack.cpp、FriioWhite.cppの頭に #include
で、ひとまずビルドが最後まで問題なく通ることを確認したら日経の記事を参考に
Hdp.cppとHdus.cpp、as11loader.cを修正していく。
以上の修正がすべて完了したら本番のビルド
$ cd recfriior4/recfriior4
$ makerecfriior4/recfriioとarib25v021/arib25/src/b25ができてるか確認したら
次はファームウェアのローダのビルド
$ cd hdus-recfriior4/as11loader
$ makeこっちもちゃんとas11loaderができているか確認しとく。
7. プログラムのインストール
$ cd recfriior4/recfriior4
$ sudo install -m4755 ./recfriio /usr/bin/
$ cd recfriior4/arib25v021/arib25/src
$ sudo install -m755 ./b25 /usr/bin/
$ cd hdus-recfriior4/as11loader
$ sudo install -m755 -s ./as11loader /lib/udev/7. ファームウェアの準備と確認
ファームウェアを準備する。
$ cp SKNET_AS11Loader.sys /lib/firmware/ファームウェアが正しくロードできるか確認してみる
$ /lib/udev/as11loader /lib/firmware/SKNET_AS11Loader.sys
$ lsusbファームウェアロード前はデバイスID 1738:5211として見えていたチューナが
デバイスID 3275:6051 VidzMedia Pte Ltdとして表示さるようになっていればOK
8. ファームウェアの自動ロード設定
$ sudo vi /etc/udev/rules.d/52-as11loader.rules中身はこんな感じ。
SUBSYSTEM=="usb", SYSFS{idVendor}=="1738", SYSFS{idProduct}=="5211", RUN+="/lib/udev/as11loader /lib/firmware/SKNET_AS11Loader.sys"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="3275", ATTRS{idProduct}=="6051", MODE="0644", GROUP="video"
1行目でチューナーが接続されたら手動でやってたファームウェアのロードを自動的に実行
2行目でファームウェアがロードされたチューナーに対してパーミッションの設定
9. テストしてみる
まずはチューナとカードリーダを一回わざと抜いて再度接続してみます。
これまでの手順で行ったように正しく認識され、各種設定が自動で行われているか確認しておきます。
問題なければ試しに録画してみます。放送局とチャンネルの対応はこんな感じ。
放送局名 ch
NHK総合 27
NHK教育 26
日本テレビ 25
テレビ朝日 24
TBS 22
テレビ東京 23
フジテレビ 21
東京MX 20
放送大学 28
復号あり、ドライバはhdusという設定で21chを30秒、rec.tsというファイル名で保存してみる。
$ recfriio --b25 --hdus 21 30 /tmp/rec.tsvlcで保存されたファイルを開いて問題ないか確認しておきます。
ついでにwineが使える環境であれば念のため
$ wine ./tsselect.exe /tmp/rec.tsとしてドロップが発生していないか確認しておくと安心。
さらにもっと長い時間録画させつつ
$ vmstat 30 10として30秒ごとに計10回のシステムの状況をチェックしてみたりすると
録画時のPCの負荷状況が把握できたりするのでさらに安心。
ちなみにうちのBOXD510MOにRAM1GBのマシンでvmstatで見てみるとこんな感じ。
$ vmstat 60 20
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 240 23088 17032 327800 0 0 4 8 21 16 0 0 99 0
0 1 240 9368 10760 343480 0 0 8 1855 425 745 5 1 93 1
0 0 240 9052 7248 348672 0 0 0 1988 430 749 5 1 94 1
0 0 240 9748 7384 349068 0 0 0 2011 433 755 5 1 94 0
0 0 240 10084 7488 348904 0 0 0 2007 434 755 5 1 94 1
0 0 240 9784 7612 349396 0 0 0 1864 422 722 4 1 95 0
1 0 240 9040 7720 349896 0 0 0 1966 436 758 4 1 94 1
0 0 240 10156 7828 348880 0 0 0 2007 432 755 5 1 94 1
1 0 240 10048 7948 348908 0 0 0 1931 429 757 4 1 94 0
0 0 240 9420 8068 350088 0 0 0 1947 427 749 4 1 94 0
2 0 240 9704 8204 348752 0 0 0 2002 435 749 4 1 94 0
0 0 240 9068 8320 349620 0 0 0 2000 430 751 5 1 94 0
1 0 240 9924 8424 348336 0 0 0 2001 439 756 5 1 94 0
0 0 240 9172 8544 348792 0 0 0 2001 436 746 5 1 94 0
0 0 240 9324 8668 348916 0 0 0 2000 432 748 5 1 94 0
0 0 240 9120 8804 348844 0 0 0 2011 446 761 4 1 94 0
0 0 240 10000 8944 347804 0 0 0 2026 443 772 5 1 94 1
0 0 240 8992 9076 348388 0 0 0 2024 436 753 5 1 94 1
1 0 240 9140 9188 348136 0 0 0 2022 437 761 5 1 94 0
0 0 240 9800 9300 347828 0 0 0 2014 443 768 5 1 94 0
topも同時に実行してリアルタイムで見ていたけどCPUの使用率は25%以下に収まってる感じ。
専用マシンにするならD410でも十分ぽい。
ただ、このマシンはRAID1を組んでsmbサーバとして運用中。
なので録画とそれ以外のファイル操作が重なった状況を想定して、録画しつつ他のマシンから
ファイルを書き込んでテストしてみたけどCPU使用率はrecfriioが25%、smbdが40%という感じ。
保存ファイルをtsselectでチェックしてもドロップはゼロだったのでファイルサーバとしての
同時運用も問題なさげ。
・参考にしたもの
http://gedit.blog40.fc2.com/blog-entry-7.html
http://nagou.cocolog-nifty.com/haley/2009/01/ls-glhdus-fb77.html
http://blog.livedoor.jp/sakuranomorino/archives/51171774.html
某スレ 668 ：名無しさん＠編集中[sage]：2009/10/30(金) 21:02:25 ID:/LmhL6JR