X

Linuxでテレビ総合スレ 避難所 3

■ このスレッドは過去ログ倉庫に格納されています
0542名無しさん＠編集中 (ﾜｯﾁｮｲ 01b8-0BNU)
垢版 |
2019/06/26(水) 22:35:46.34ID:NwthLkwO0
>>541
たしかに安い値段で性能高いものが手に入るなんて甘い話すぎるし、落とし穴がありそうw

https://blog.hackster.io/meet-the-new-raspberry-pi-4-model-b-9b4698c284
>Using the PCI Express bus provided by the new BCM2711 means that not only do we now have USB 3.0 capability,
> but the Gigabit Ethernet than was previous provided via the USB bus and the LAN7515 chip
>?which had a maximum throughput limited to around 300Mbps?
>is now provided using the Broadcom BCM54213PE on a separate bus to the USB traffic.
新しいBCM2711で提供されるPCI Expressバスを使用するとUSB 3.0の性能が発揮できるだけでなく、
以前にUSBバス経由で(約300Mbpsに制限されていた)LAN7515チップから提供されていたGigabit Ethernetが
USBトラフィックと別のバスでBroadcom BCM54213PEを使用して提供されるようになりました。
0543名無しさん＠編集中 (ﾌﾞｰｲﾓ MM75-2ul2)
垢版 |
2019/06/26(水) 22:53:15.76ID:vEQet30pM
最近の安スマホ向けのSoCの性能からも互換性を意識するにしてもさすがにPiのバスの作りはかなりアレなんでPi4では多少モダンになるのではないかと
というか安く上げるためだったこれまでの作りを踏襲しようとするといいかげんかえって高く付くんでない？
0544名無しさん＠編集中 (ﾜｯﾁｮｲ 59f0-0BNU)
垢版 |
2019/06/26(水) 22:55:36.18ID:7AgxgTV80
>>542
Raspberry piスレでも既に指摘されているが、Raspberry pi 4の一番の落とし穴は”発熱”だと思われる。

・真面目に発熱対策をしないと本来の性能が出せない可能性
・電源仕様で性能を絞られている可能性

基板サイズの何倍もあるヒートシンクでないとファンレス駆動が出来ないのではという噂まで出ているが、実機が出るまで真偽は不明。
0549名無しさん＠編集中 (ﾌﾞｰｲﾓ MM2e-TYPP)
垢版 |
2019/06/28(金) 11:51:05.45ID:KxvBXBR2M
px4_drvでデバッグログを有効にする方法で、dkmsを使わない場合は make を make DEBUG=1 と実行する方法は分かったのですが、dkmsを使う場合はどのように操作すれば良いでしょうか？

OSがハングアップする原因を調べているのですがなかなか該当するエラーを見つけられないのでドライバのログを見ようと思い質問しました
0551名無しさん＠編集中 (ﾜｯﾁｮｲ 5d52-XxYO)
垢版 |
2019/06/28(金) 22:28:56.30ID:whztl+Ty0
>>549
作者です
dkms使用時にデバッグログを有効にするためには、dkms.confの
MAKE="cd ./driver; make KVER=${kernelver} px4_drv.ko"
の行を
MAKE="cd ./driver; make KVER=${kernelver} DEBUG=1 px4_drv.ko"
と置換した上で再度ドライバのインストールを行ってください

…ところで、OSがハングアップするとは具体的にどのような症状でしょうか
0554名無しさん＠編集中 (ﾌﾞｰｲﾓ MM39-TYPP)
垢版 |
2019/06/28(金) 23:28:20.36ID:SONjon7xM
>>551
ありがとうございます
いやそれが録画もしていない時に突然OSごと固まってしまい、最初はハード障害かと思い各種診断ツールを使っても正常、今はaspm=off以外にACPI周りの設定見直しとCPUのC-State無効化をしようとしているところです

環境的にはEPGStation+Mirakurunで、Mirakurunのチューナー設定でデバイス指定をあえてしてませんでしたのでpx4_tsdev_open x:x: failed. (ret: -114)のデバイス使用中エラーが定期的に複数出ますが直接は関係ないと思っています

なのでまずはOSだけで確認して、問題なさそうであれば録画アプリ周りを調査しようかなと
0555名無しさん＠編集中 (ﾜｯﾁｮｲW 1564-zpX8)
垢版 |
2019/06/29(土) 00:05:40.18ID:554/+oWi0
>>554
横からだけど、実はハングしてたとかではなくてすごく応答が遅くなってたとかない？
録画も途中できれてSSHでも繋がらない、ping投げても応答なしだったけど30分ぐらい放置したら動いてたってことならあったから参考までに

あとは調べてたら悪いんだけど、microSDだったらそっちも疑った？読み込めても書き込めないとか一部だけ読み書きが異常な速度になってたりとか。
ハングに近い症状も出た気がするから一応だけど書き込んどくね
0556名無しさん＠編集中 (ﾜｯﾁｮｲ a1c2-tCwj)
垢版 |
2019/06/29(土) 00:07:35.61ID:Ady0QOis0
少し前までMSSProfessional2018R2使ったffmpegをEPGStationでエンコードできなくて悩んでたんだけど、これ見て解決した。
俺の場合、エンコードスクリプトのlibva関連の環境変数指定がキモだったな。

ttps://www.digital-den.jp/simplelife/archives/5100
0557名無しさん＠編集中 (ﾜｯﾁｮｲWW 1abd-TYPP)
垢版 |
2019/06/29(土) 00:38:23.93ID:FioFVbsq0
>>555
PCなのでmicroSDではないのです
ストレージはSSDで、あと数時間経っても延々と復帰しないのは外に出ていけるLAN、NASと直結しているLAN(NAS側からもlinkup,downが記録される)のネットワーク2系統から確認済み
またカーネルパニックでもない
でもわざわざ情報ありがとう
0559名無しさん＠編集中 (ﾌﾞｰｲﾓ MM2e-TYPP)
垢版 |
2019/06/29(土) 03:38:40.39ID:Jltj+S7JM
>>558
電源というかCPUの省電力機能に関する不具合ですね
Xeon系でハングアップやCPU Internal Error、フリーズが発生する障害広報を会社で見つけたので、その予防策を採用する事にしました
（ネットだとXeon以外の一部世代のCPUでも同様の対処が話題として話されていました）
0564名無しさん＠編集中 (ﾆｸｸｴ 5d52-XxYO)
垢版 |
2019/06/29(土) 14:00:18.71ID:b1vFo/tG0NIKU
>>554
>>559
なるほど、そういうことでしたか
CPUの省電力機能の不具合なんてこともあるのですね

px4_tsdev_open x:x: failed. (ret: -114)のエラーですが、通常使用下においてエラーメッセージが繰り返し出力されるのはやはりおかしいと思ったので、rev: 152 @ develop にてログレベルをデバッグに変更しました
この変更により、DEBUG=1をつけてビルドせず、コンソールへ出力するログのレベルを変更しない限りは、このエラーが出力されることはなくなります

私がpx4video*に対してrecpt1を叩くときは全ての場合においてデバイスファイルを指定していたので、ご指摘いただいたことに気がつきませんでした
ありがとうございます
0566名無しさん＠編集中 (ﾆｸｸｴ 5d52-XxYO)
垢版 |
2019/06/29(土) 15:13:52.39ID:b1vFo/tG0NIKU
MiyouTunerですか…

画像を見る限り1ボードにTC90522とIT9173が混在していますが、どちらのチップを使用して受信するかによって感度に差がありそうです
私はIT9173と同様の受信部を持つと思われるIT9179を搭載したKEIANチューナーを所有していますが、TC90522を搭載したPX-W3U4と比べて全体的に感度が低く、キー局以外の一部のチャンネルはIT9179では受信が困難です
なのでMiyouTunerでは、地域や電波状況によっては同一ボード上の個々のチューナーによって受信できるチャンネルにばらつきが起こることが考えられます (キー局は全てのチューナーで受信可能だと思われます)

そしてT側は、アンテナ線からすぐとIT9173への入力の手前にブースターの機能を持つと思われる小さなチップが挟まっています
これがQ1UDの場合と同じように、受信にかえって悪影響を及ぼすことがないかが気になります
0567名無しさん＠編集中 (ﾆｸｸｴ 5d52-XxYO)
垢版 |
2019/06/29(土) 15:15:38.98ID:b1vFo/tG0NIKU
そして非公式Linuxドライバですが、手持ちのチューナーが沢山あり、これ以上増えても繋ぐアンテナ線がないために今のところ入手するつもりがないので、対応予定はありません
ただ、製品版が"本当の"PCIe接続で登場したら考えます

(どうせならIT9173じゃなくてTC90527を6つ積んでくれないかな…チップの数が増えるけど)
0570名無しさん＠編集中 (ﾌﾞｰｲﾓ MM39-TYPP)
垢版 |
2019/06/30(日) 22:20:21.79ID:sIwtFbJ5M
>>564
ドライバの修正ありがとうございます

CPUハングアップは「低電力モードから動作モードに復帰した場合、復帰直後のメモリアクセス等の遅延が発生する場合があります。
その結果、CPU内部に動作矛盾が発生しシステムのハングアップやIERR、フリーズに至ると推測しております。」との事で、BIOSの設定見直しと共に、RHEL向けにはカーネルパラメータ
processor. max_cstate=0 intel_idle.max_cstate=0
がベンダーから案内されています
当方Ubuntu18.04 &骨董品のXeonですが設定したら動作が安定し始めました

ちなみにintel_idle.max_cstateだけだと、intel_idle ドライバが無効になり、acpi_idle ドライバに切り替わるのですが、それだけではダメでした…
0571名無しさん＠編集中 (ﾜｯﾁｮｲ 86a4-9F60)
垢版 |
2019/07/01(月) 07:42:11.17ID:V/wrpgxN0
miyoutuner おくればせながらついさきほど存在を知ったが...

地上波8チャネルもねえから要らんww
東京にいる人のことしか考えてねえからこういうお花畑な発想になるんだろうな

アースのしゃちょーに掛けあって費用出すからPT3製造させてくれ、とか
やってくれるほうが世にとってはうんと有益なんだけどな
0574名無しさん＠編集中 (ﾌﾞｰｲﾓ MM2e-66DY)
垢版 |
2019/07/01(月) 17:02:15.97ID:jkVlexsLM
>>571
ひろゆきが東京中心な思考なのは今に始まった話ではないしな
0576名無しさん＠編集中 (ﾜｯﾁｮｲ 25b3-pT+E)
垢版 |
2019/07/01(月) 21:40:14.52ID:+aR9gpBy0
Pi3+Q3U4で衛星側だけものすごく受信感度悪くなるんだけど何が原因だろう
Windows側でSignal16でて問題ないの確認してそのまま環境持っていっても
C/N6くらいでエラーだらけになっちゃう
0577名無しさん＠編集中 (ﾌﾞｰｲﾓ MMea-TYPP)
垢版 |
2019/07/01(月) 22:22:16.50ID:3Qi+jf3kM
>>218
の「MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 finish listeners added. Use emitter.setMaxListeners() to increase limit」はMirakurunで複数の録画をパラレルで行った際、11番目の録画実行で出るエラー
うちの環境は上記条件で必ずエラーが出るよ
0578名無しさん＠編集中 (ﾜｯﾁｮｲ 5d52-XxYO)
垢版 |
2019/07/01(月) 23:17:23.75ID:FQAVyf+P0
>>570
なるほど
情報共有いただきありがとうございます

>>576
ご報告ありがとうございます
手元のQ3PE4では同様の現象が再現しないために不具合の詳細な状況が把握できていないのですが、とりあえず一番怪しそうな箇所を変更してみました (rev: 156 @ develop)
お試しください
0579576 (ﾜｯﾁｮｲ 25b3-pT+E)
垢版 |
2019/07/01(月) 23:48:49.19ID:+aR9gpBy0
信号は勘違いだった模様

>>578
ありがとうございます
b23c1a2入れ替えてみましたが状態変わらず
衛星側ずっとエラーカウント、地上側は問題なしです

Windows機の方につなぎ替えると問題なく受信してるので、何か環境かとも思うんですが
何を確認するべきか教えていただけるとありがたいです
0580名無しさん＠編集中 (ﾜｯﾁｮｲ 8663-a57L)
垢版 |
2019/07/02(火) 03:02:17.75ID:dXFFfgO/0
そういえば数日前Rock64にその時の最新のドライバー入れてQ3U4使ったら
CSが弱い感じだった、W3U4に変えたら治ったからQ3U4壊れたかなって
もう一回Q3U4繋いだら治ってて、なんだったんだろーって思った
0582名無しさん＠編集中 (ﾌﾞｰｲﾓ MMea-TYPP)
垢版 |
2019/07/02(火) 18:59:35.67ID:7lldoCdHM
BSといえば
PCのUbuntu(Murakurun+EPGStation)とPX-Q3PE4 x2 で地デジ7+BS7の全録を昨日から試してたら、半日経ったあたりでNHKBS1だけが定期的にドロップし始め、5時間連続で発生しているところで停止、昨日作者さんの書込みを見てドライバを最新化してみました

その後も地デジ7+BS7で試したら、やはりNHKBS1でドロップが発生しているけど頻度は減少
なんでNHKBS1だけ発生するのかは不明だけど、最新ドライバで動作が不安定になるって事は今の所ないかな
0585576 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/02(火) 22:33:23.42ID:osLk4ilD0
色々ドライバ変えてみたけどC/N数値がpx4_drvと公式ドライバで違うのだけわかった
単に数値違うだけなのかな

ただどっち使っても衛星側エラーファイルになるのでなんか根本間違ってそう
Windowsだと問題ないけど症状的には受信感度落ちまくりって
手っ取り早くブースター買ってきて試すほうがいいのかな

何かそういう設定ないのだろうか
0587名無しさん＠編集中 (ﾜｯﾁｮｲ 5d52-XxYO)
垢版 |
2019/07/02(火) 23:24:48.54ID:Pk7kz79l0
>>579
>>582
ありがとうございます
>>582さんのご報告では「ドロップの頻度が減少した」とのことでしたので、昨日変更した部分に更に手を加えてみました
いかがでしょうか

>何を確認するべきか教えていただけるとありがたいです
エラーカウントが増えるチャンネルと、使用しているデバイスファイル名(px4video0-7)やチューナーの使用状況が分かると助かります
0588576 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/03(水) 00:16:24.18ID:0OVC6k190
>>587
状況と行った事はは
Q3U4+Pi3でraspbian使用
PT3で使ってたアンテナ線を繋ぎ変え
px4video0,1,4,5衛星側チューナー単体どれか
recpt1使用でチャンネルBS01_0やBS09_0で15秒程度保存
tsselect通してみるとエラーだらけのファイル

何かが根本おかしいみたいで悩んで
余ってるPCでCentOS7/Win10デュアル環境作ってみましたが
Linux上で保存したものはエラーだらけになります

Linux環境になにか問題ありそうなんですが
わかる方いましたらアドバイスください
0593名無しさん＠編集中 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/03(水) 02:20:32.95ID:XJYZN6du0
テストなのでB25とかはあえて使ってないです
今WinLinuxデュアルブート状態で
OS以外には全く差がないのでなんでだろうかと
LinuxでもQ3U4問題なく動いてる人いるんですよね？
0594576 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/03(水) 02:40:37.92ID:XJYZN6du0
px4_drv rev132まで一気に遡ってみたら衛星側ちゃんとファイル吐けるようになりました
時間あるときにここから登っていってどこでおかしくなるか探ってみます
0595名無しさん＠編集中 (ﾌﾞｰｲﾓ MM2e-TYPP)
垢版 |
2019/07/03(水) 13:00:58.89ID:OVJCHYMoM
rev: 156 @ developを入れてPX-Q3PE4x2の地デジ7BS7録画を続けていましたが、昼前に地デジ,BS問わず複数のチューナーが暴れだし、同時刻帯の番組録画にDrop多発、でも以降の録画は正常
Mirakurunのエラーには
warn: TSFilter is closing because EIT p/f timed out for eventId=xxx
が複数出てるけど、サーバの時刻には狂いなし

帰宅したらドライバの最新化とドライバのデバッグ情報を出す様にしてみます
0596576 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/03(水) 21:12:06.43ID:DYVzSTrR0
rev:149@developまで上げたところでC/N下がってエラーするのを確認して
rev:148に戻してみて問題がないってわかりました

問題なく動いてる人との違いってなんだろう

とりあえず手元の環境だと149以降駄目でした
0597名無しさん＠編集中 (ﾜｯﾁｮｲ 0ac0-xFLg)
垢版 |
2019/07/03(水) 22:01:28.39ID:meIEkSsf0
うちのも特定のチャンネルの受信レベルが低くて、天気のせいにしてたけど
（避難勧告出ているし）さっきドライバを更新してrev:160に上げたら回復した。
偶然かも知れない。
0598名無しさん＠編集中 (ﾜｯﾁｮｲ 5d52-XxYO)
垢版 |
2019/07/03(水) 22:03:17.69ID:ZI/Annis0
>>588
>>594
>>596
わざわざ問題のないバージョンまでご確認いただきありがとうございます
そして、お手数をお掛けしてしまい申し訳ございません

デバイスファイルに関係なくTSファイルの頭からエラーだらけ、かつ、チューナーのドライバに大きな変更を行った後に問題が発生しているとのことで、
チューナーの設定パラメータに問題があるのだろうと思い改めて確認したところ、一箇所設定値に誤りがありましたので、修正を行いました
https://github.com/nns779/px4_drv/commit/1741ce2870c134ce1cf972b0541eeeaffb568733

いかがでしょうか

>>595
長時間の多チャンネル録画試験ですか…すごい
ちなみにチューナーが暴れだした中でも、Dropが全く発生しなかったチャンネルはございませんでしたか…？
0599576 (ﾜｯﾁｮｲWW 2501-+ANf)
垢版 |
2019/07/03(水) 22:38:08.80ID:q8Zzh0zj0
>>598
素早い対応ありがとうございます
1741ce28に入れ替え確認したところ
Win10上とC/N値同じくらいになりエラーなし正常になりました

このくらいの簡単なテスト報告ならできても、
ファーム開発は無理なのでありがたい限りです

あと蛇足ですがアッテネーター入れたら
B高周波数になるにつれ減衰していく症状直りました
入力強すぎるの駄目なんですねこのチューナー
0600名無しさん＠編集中 (ﾜｯﾁｮｲW 1564-zpX8)
垢版 |
2019/07/03(水) 23:44:35.05ID:Qh/hX+Bn0
他チューナーで正常に受信できるときに、U4やPE4系はアッテネーターを挟むのは常識。
TS抜きをする人ならもっとチューナーの特性の下調べをしとくべきだったね。
まあ解決したようでなにより
0601名無しさん＠編集中 (ﾜｯﾁｮｲWW 6326-iwKd)
垢版 |
2019/07/04(木) 00:05:25.03ID:WH/wdsJo0
Ver149以降は信号強度上限が低くなってたのが576さんのまめな調査で判ったという事でありがとう
境界条件の不具合は見つけにくいものだしわかって良かった
作者さんもいつもメンテしてくれてありがとう
0603名無しさん＠編集中 (ﾌﾞｰｲﾓ MM67-Q6AM)
垢版 |
2019/07/04(木) 14:09:13.87ID:uL+bOQ5kM
>>598
Dropですが地デジ7BS7のうち、地デジ3チャンネルは同時間帯もDrop無しでした

ちなみにマシンのリソース的には、Zabbixエージェントで収集していたCPU使用率やディスクI/Oを見ても、通常録画時と変わりがありません
PX-Q3PE4は2枚とも別々のUSBホストコントローラに1対1で接続、カードリーダーは内蔵USB接続、PX-Q3PE4は2枚ともV2.0といった環境です

長時間の多重録画はあくまでテストなので実運用ではこんなに録画は行いませんが、構成的にどの位安定するのか知りたくて試しています
でもSSDの書き込み数がどんどん上がっていくので今週で終わりにすると思います。笑

あと、どうセッティングしたのか試して色々気付いた事はそのうちネットでメモ書きとして公開しよかなぁーと
0604名無しさん＠編集中 (ﾜｯﾁｮｲ 63ba-Pv24)
垢版 |
2019/07/04(木) 18:39:05.01ID:T7kYyVAv0
尼のD-PLAZAのPX-Q3PE4の在庫は他店と共有されたりするのかなあ？
D-PLAZA指定でも他店の古い在庫が送られてV2.0からハズレる？
0605名無しさん＠編集中 (ﾜｯﾁｮｲW 835f-4srP)
垢版 |
2019/07/04(木) 19:03:09.17ID:DRC4MT5r0
>>604
6月半ばにAmazonのD-plazaで買ったのは思いっきりV1.1でした。期待して損しました。そもそもメーカーが返品されたのをごちゃ混ぜにして再出荷しているだけかも。
0606名無しさん＠編集中 (ﾌﾞｰｲﾓ MM67-Q6AM)
垢版 |
2019/07/04(木) 21:09:40.64ID:EF6dSd8hM
>>604
うちのV2.0 2枚はヤフショのD-PLAZA店で購入したものです
5の付く日などのセールではAmazonより安いのと、元々見掛けた書込みがヤフショ店の方で買ったと書いてあったのが理由です
V2.0か違うかは運みたいなものでしょうか
あと荷物の追跡情報見たら名古屋神宮（名古屋Ａ）引受でした
0608名無しさん＠編集中 (ﾜｯﾁｮｲ 63ba-Pv24)
垢版 |
2019/07/04(木) 21:35:59.18ID:T7kYyVAv0
twitter見せてもらいますわ
0611218 (ﾜｯﾁｮｲ 6fbb-SWYH)
垢版 |
2019/07/07(日) 00:41:22.40ID:cPSdusv10
>>577
ありがとうございます。このエラーは無視していいというのは、この構成でずっと運用してきて納得しています。

218とかを書き込んだ時点では、こういうバカなことを試している人間がいると、
誰かの知見になるかと思いましたが、散々な反応だったので、書き込みをやめましたが、
その後、BonDriver_Mirakurunの扱い方もなんとなくわかり、ほとんどはTVTestで、
いったん他のチャンネルを選び、元のチャンネルに戻すと大丈夫とか、
TVTest側でエラーが出てもMirakurunを再起動すれば大丈夫とかはわかってきました。

また10chとかを並べて見るには、完全にウィンドウの枠を消せるTVTestが美しいので、
似た機材構成でWindows上でVMwareのWorkstation ProにMirakurun+Chinachuの環境を作り、
Windows側からBonDriver_Mirakurunを介して、TVTestで10ch同時に表示させるというのは
比較的安定していましたが、ネットワーク上の他のWindowsからTVTestで見るとちょっと
カクついて残念なのと、録画までやってしまうと、録画先がSSDでも、知らないうちに
2分ぐらい再生が遅れてしまうので、諦めました。
ただ、Macとかでも、複数起動できて、ストリーム再生可能な動画プレーヤーがあれば、
この「10ch並べ見」も再現可能ということもわかり、軽い組み合わせを探しています。

地上波4波の実家にもPX-Q1UD×2の構成で全録サーバーを置いたのですが、不安定ぶりに
嫌気が差し、機材自体をPX-Q3PE4+PX-W3PE4の構成のものの置き換えたところ、
ド安定で運用しています。

つくづく先人に感謝しかありません。ありがとうございます。
0612名無しさん＠編集中 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 11:33:33.67ID:xoPGFwCk0
dropってなぜ、発生するのでしょうか？
なにか根本的な対策はあるのでしょうか。

うちの環境だと処理の順番は、
- PX-Q3PE4
- px4_drv
- recpt1
- mirakurun
- chinachu(epgstation)
となっていますが、

(1) PX-Q3PE4 -> px4_drv
(2) px4_drv -> recpt1 (デバイスファイルをread?)
(3) recpt1 -> mirakurun (標準入出力?)
(4) mirakurun -> chinachu (TCP)

と考えたとき、それぞれどのような処理になっているのかまでは見ていないのでわからないですが、
録画プロセス以外が動くとdropするっぽいということから、PX-Q3PE4、px4_drvかrecpt1あたりの
バッファがいっぱいになってしまって取り逃しになっているんじゃないかと予想しています。
0613名無しさん＠編集中 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 11:35:05.80ID:xoPGFwCk0
(長くなったので連投すみません)

じゃあ、niceで優先度上げておけばいいのでは？と考えてmirakurunとrecpt1をreniceしてみると
多少改善したような気はします。
linuxの仕組み上優先度を最高にしても完全に他に優先して動かすことはできないらしいので、
「改善はするけど、完璧にはできない」ようです。
リアルタイムLinuxカーネルにしてチューナからデータの取り込みを最優先でやるというのは
根本的な対策になるかもしれないなと思っています。触ったことないですけど。

昔、キーボードやマウスを動かすとdropするというのを聞いたこともあります。
そうするとUSBバス、USBハブ、PCIバスも気にする必要もありそうでしょうか。
そうすると専用機にするしかない、ということになりそうですが。

うまいやり方を知っている方、いませんか？
0614名無しさん＠編集中 (ﾜｯﾁｮｲ 03a0-rgZK)
垢版 |
2019/07/09(火) 11:55:31.22ID:U8366zjx0
専用機にすればいいんじゃね？録画環境はどのみち放置＆再起動もしたくないだろうし
専用機として運用した方が気楽だと思う。グラボやHDDとか意味もなく積載しなければ
電気代もそんなにいかないしさ
0615名無しさん＠編集中 (ﾌﾞｰｲﾓ MM27-Q6AM)
垢版 |
2019/07/09(火) 12:12:44.42ID:Q9YFUhkHM
プロセスの優先度ねぇ…
長時間録画テストをする機会があればMirakurunのチューナー設定のcommand箇所でniceコマンドを挟めるか試してみるか

うちは接続用のUSB2.0増設ボードとか用意したりしたけど、専用機にした方が何かあった時に調査・検証しやすいからね
0616名無しさん＠編集中 (ﾗｸﾍﾟｯ MM47-Slb1)
垢版 |
2019/07/09(火) 12:17:46.62ID:hfPM0Dl5M
リアルタイム処理だから受信からts保存までの処理をバッファ範囲内でやりきれなければどこかでdropなりバッファ溢れなりするわな

録画と無関係なプロセスにはなるべくCPU使わせないのが1つの解ならば
専用機にするか、コンテナ等の仮想化で他の影響を最小化するか
0617名無しさん＠編集中 (ﾜｯﾁｮｲ 7fea-zYa2)
垢版 |
2019/07/09(火) 14:09:40.40ID:Om3Cohfl0
PCスペックが晒されてないのでアレですが、録画と同時に何か別の作業をする環境なのであれば、現状スペック不足なのではないでしょうかね。

たとえば私の環境は EPGStation on KVM の仮想環境ですが CPU/MEM/SSD に十分なスペックを用意しリソース配分をしてるので
同一ホスト上の別VMが高負荷になっていようが録画が drop するようなことはありませんし。
0618名無しさん＠編集中 (ﾜｯﾁｮｲ 6343-XqLb)
垢版 |
2019/07/09(火) 14:27:48.88ID:1jRXxixe0
Ryzen5 2400G/MEM 16GB/NVMe 256GB/HDD 4TB/PT3
これでLXD使って動かしてるけど
特にドロップするような感じはないかな
同時にKVMでOPNsensも動かして
他にWEBとかFTPとか他いろいろやってるけど
どこに負荷かかってもドロップはしてないように思う
0619612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 15:58:00.95ID:xoPGFwCk0
みなさまありがとうございます。

環境ですが、
CPU i7-6700 / MEM 32G / SSDで
px4_drv/recpt1/mirakurunがKVMに入っていて、VCPU=2 MEM=2Gです。
ディスクとネットワークはvirtioです。

epgstationとchinachuがKVMホストのdockerで動いています。
録画データはHDDに書いていて、それ以外はSSDです。
epgstationのh264エンコードにはniceをつけて優先度低にしています。

普段は止まっているdockerの作業用環境があったり、DHCP、VPN、DLNAのサーバがdockerで動いています。
特に高負荷なものではないです。

他にKVMのWindowsがあってこれはゲームするときだけ起動します。
GPUをパススルーしています。4-6VCPU 8-16GBで試行錯誤中です。
0622612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 16:07:48.04ID:xoPGFwCk0
30分の録画で、
Windows停止中は、数個から数十個のdrop。
無負荷のWindowsを動かしておくと数十〜数百drop。(無負荷なのにtopで見るとkvmプロセスがCPU100%ぐらいうごいている)
WindowsでGPUバリバリのゲームをすると数千以上drop。

8コア中1-2コア専有させていいので他のコアでゲームしてもdropなしにできたらいいなと思うのです。

dockerのものをKVMの中に持っていったら上手にCPUわけわけできる気がしてきました。

実は、KVMにする前にVirtualBoxのVM2つでそれぞれmirakurunとchinachuを動かしていてほぼdropなしにできていました。
最近KVMとDockerにして(Windowsも増やして)環境を作り直したらちょいちょいdropするので、
対策したく、そもそも何が原因でdropしているのが知りたくなったというわけでした。

そういえば、以前はarib-b25-stream-testだったデコード処理をrecpt1のオプションに
つけるように変えていました。
recpt1でdropしているならば、recpt1はデータ受け取りに専念して、
デコードは別プロセスとするほうが、dropしにくいかもしれません。
0624名無しさん＠編集中 (ﾌﾞｰｲﾓ MM27-Q6AM)
垢版 |
2019/07/09(火) 16:31:53.40ID:Q9YFUhkHM
自分ならMirakurun/ChinachuをKVMかDockerコンテナのどちらかに寄せて混ぜないかな

arib-b25-stream-testだったデコード処理をrecpt1のオプションのこれ、前者のほうが基本的に良い結果になるとChinachuの方の発言を見掛けた事があるから私は長時間録画テスト時にarib-b25-stream-testを使ったよ
https://twitter.com/Chinachu_REC/status/1095890150955966469?s=19

ちなみにDropの症状的に、Mirakurunはエラーログに何も出してないんですよね？
https://twitter.com/5chan_nel (5ch newer account)
0626612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 16:51:35.78ID:xoPGFwCk0
上のKVMでやってるひとのレス見て、VCPU=2で設定してるけど、これ専有できていないんじゃないかと疑ってます。

『
ホストで直接動くプロセスと、dockerのプロセスは、忙しかったら8コア自由に使う。
VCPU=2で2個減って6になるのではなく8です。
「VCPU=ホストの1スレッド」で、ホストのプロセスと平等にCPUを取り合う。
KVMのmirakurunのVMはmax使えて2コア。VCPU=8にしておいたほうがましってこと。
』
↑いまのところこう理解しています。

VCPU=6のVMを作ってホストとdockerのプロセスを中に入れればきれいにCPUをわけわけしてくれて安定するんじゃないかなと。
drop原因がmirakurunのVMにあるとすれば、ですが。

VCPU=2/2GBはVirtualBoxのときにそれぐらいだったからというのと、raspberry piで動くっていうんだからそんなもんだろう
という感じで決めています。

epgstationをKVMの別VMに閉じ込めてエンコードの影響を分けられないか試してみようと思います。
0628612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 17:25:51.00ID:xoPGFwCk0
mirakurunがKVMでchinachuがdockerになっている理由は、
* ホストにドライバインストールしたくなかった
* mirakurunのVMにはドライバインストールが必要
* dockerにはドライバインストールできない
* chinachu/epgstationはdockerでインストールがかんたん
という理由からです。
もうインストール手順にも慣れたのでホストに入れちゃってもいいんですが、
KVMで高負荷タスク(ゲーム)とdropなしの録画タスクを共存できるかもしれないので、
KVMに寄せてみます。


arib-b25-stream-testの方が良いかもの件は、
b25デコードがrecpt1のデータ受け取りの足を引っ張ってdropするという可能性が
構造的にあるのなら、recpt1のデータ受け取りとb25デコードを別スレッド(プロセス)に
するのは効果がありそうですね。コード見てないので仮定の話ですけど。
0629612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 17:26:39.01ID:xoPGFwCk0
CPU専有設定の件、
2CPU独占するようにできるんですか？
「CPU kvm 専有」とかでググって調べたんですが、わからなくて。。
CPU Pinningは見つけたんですが、これは他のVMからの影響を受けないように設定できるけど
ホストのプロセスは関係なくCPU奪いに来るんじゃないかと理解していました。
0631612 (ﾜｯﾁｮｲ 6f02-l1sj)
垢版 |
2019/07/09(火) 17:38:46.89ID:xoPGFwCk0
>>627
「LinuxにおけるCPU割当制御」という素敵なページを発見しました。
ありがとうございます。
0633名無しさん＠編集中 (ﾜｯﾁｮｲ 7fea-zYa2)
垢版 |
2019/07/09(火) 19:35:21.91ID:Om3Cohfl0
Win停止中(他のVMがなければほぼ無負荷状態？)でも30分で数個 drop してる時点で何かおかしそうですね。
受信環境にもよりますが普通は drop 0 と考えておくのがよいかと思いますし。

Mirakurun VM へのチューナ割当はUSBパススルーですか？USBホストアダプタどパススルーですか？
私の環境では USBパススルーではどうしても drop するのでUSBホストアダプタをパススルーをしています。
この状態で EPGStatiaon/Mirakurun/MariaDB すべて同一の VM(docker on VM on KVM) に入れていますが、
8番組同時や12時間番組等を録画しても電波的な問題以外では特に drop はしないですね。
0635名無しさん＠編集中 (ﾜｯﾁｮｲWW bf32-Slb1)
垢版 |
2019/07/09(火) 20:01:23.69ID:bTt01EcQ0
今は使ってないけど以前KVMだったときは
PX-W3U4をUSBパススルーすると確実にドロップしたな
一方わざわざホストにUSBデバイスサーバ入れてゲストで共有したらなぜか正常
KVMのパススルー機能との相性が悪かったんだと思っている

その後lxcに移行し、ホストにpx4_drv入れることで全く問題なくなった
0638名無しさん＠編集中 (ﾜｯﾁｮｲWW 6360-qXaR)
垢版 |
2019/07/10(水) 10:36:16.99ID:4j9TT94Q0
>>553
同感、大抵の地方なら地デジは4チューナーで足りる。
衛星が4チューナーあるとありがたい。

PLEXの地上・衛星5チューナー、あれに非公式ドライバが対応してくれると喜ぶ人も多いと思うけど。
0639名無しさん＠編集中 (ﾌﾞｰｲﾓ MM27-b9fz)
垢版 |
2019/07/10(水) 16:25:52.58ID:mBVTgOsiM
衛星12チューナー
0640612 (ﾜｯﾁｮｲ b602-6qrA)
垢版 |
2019/07/11(木) 16:07:19.95ID:rC55OqXk0
途中経過です。

MainVM : VCPU=6 その他全部をいれる
WinVM : VCPU=6 停止
TunerVM : VCPU=2 MEM=2G

ホストで動いているもの＆ホストのdockerをMainVMにいれました。
MainVMの中にchinachuとepgstationがいます。
chinachuとepgstationで同じ番組を同時に録画した結果、
aribts/sample/check_packet.jsで確認すると、
完全に同じ位置にdropしているので、drop原因はchinachuとepgstationではないと判断。

mirakurunの--b25をarib-b25-stream-testに変更。
TunerVM VCPU=4に変更。
reniceで、TunerVMを優先度高、MainVMを優先度低に設定。
この時点で1番組録画でも30分で数個〜数十個のdropする場合があるので、CPU負荷じゃないと判断。
0641612 (ﾜｯﾁｮｲ b602-6qrA)
垢版 |
2019/07/11(木) 16:09:13.68ID:rC55OqXk0
タイミング？
https://bugzilla.kernel.org/show_bug.cgi?id=196527

そこで、デバイスサーバで改善したという話があったので、
直接チューナデバイスをVMに割り当てていたのをやめて、
[仮想マシンマネージャ]の[仮想マシン]->[USBデバイスのリダイレクト]から選択して
割り当てるようにしてみました。
これが、効果ありですっきりさっぱりdrop=0になっています。
デバイスとの相性で直接接続とリダイレクトで性能が変わるようです。
VM起動時にUSBリダイレクトで自動接続するようにしたい。

KVMのUSBリダイレクトのメニューが出たり出なかったりしたのでAppArmorを消した。
USBリダイレクトのメニューが出たり出なかったりする場合は[仮想マシンマネージャ]を開き直すといいかもしれない。
ちなみにVirtualBoxのUSB割当はdrop=0だったので優秀。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況