リアルタイムリナックスについて

**wait_np** · NG

リアルタイムリナックス（RT-Linux）について語り合うスレです。
素朴な疑問やくだらない質問も受け付けます。

RT-Linux　　http://rtlinux.cs.nmt.edu
ART-Linux　http://www.etl.go.jp/etl/robotics/Projects/ART-Linux

わかることは答えます。わからないことは皆さんが答えてください。

**login:Penguin** · 04/12/12 15:43:50

>>610
リルタイム化するハードがあるの？

**login:Penguin** · 04/12/12 15:44:19

×リルタイム
○リアルタイム

**login:Penguin** · 04/12/12 16:01:29

ハードウェア面から見ると、ウォッチドッグタイマは必須だよなぁ。
最悪何か起こったときにひっぱたいてもらわないとダメだし。
って、組み込みのことしらないんだけどね。

俺にとってのリアルタイムOSはCP/MとかMS-DOSだからなぁ。
って、その時代キャッシュなんてものなかったから、
完全に何クロック後に何が起こるか計算できたからなぁ。

**login:Penguin** · 04/12/14 12:31:45

MS-DOS は手軽で最強のリアルタイムOS だったね。
システム性能が把握しやすいからヘタ打つことも少ないし。

Linux だとハードによるけど 300us 程度の周期までかな？
uITRON は知らないけど 10us 以下の周期でもいけるらしいね。
システムにぶら下がる機器で住み分けができるか・・・

**login:Penguin** · 04/12/14 13:55:25

>>614 「リアルタイムOS(笑)」くらいにしておいてくれ。

FreeDOSとか使ってる人、いない？
http://www.freedos.org/

**login:Penguin** · 04/12/14 14:43:38

スケジューラの無いOSとスケジューラしか無いOS。
どちらもOSと名乗れるんだよな～・・・

**login:Penguin** · 04/12/14 16:17:33

まあ資源を管理する事が出来ればOSと名乗ってもいいんでないかと。

ただ、スケジューラーしか無いOSはリアルタイムモニタと名乗っていただけるとうれすい。

**login:Penguin** · 04/12/14 23:37:10

組み込み≠リアルタイムってのは
ネットワーク機能やビデオオーディオのバッファリングストリームもの
の方法論ができてきたからだよね。どれも大量にメモリを消費して
数秒後のリアルタイムを保障？している。
昔はリアルタイムといやステッピングモーター制御やDSP音瑞ｺ処理
だｂﾁたからね。

**login:Penguin** · 04/12/18 16:55:03

リアルタイム処理をマルチタスクのOS上で走らせるだけなら
対象のRTタスク以外は全部切っておくなり、機能やOS周辺
アプリケーションが少ないOSを選べばいいだけかと。

それでもマルチタスクのOSでRT使いたいのは
RTタスクを動かしながら、
対象のOSで動くアプリなりを使いたいからだよね？

制御にかかる秒数だけが問題なら
それこそ昔のDOS使えばいいよｗ

**login:Penguin** · 04/12/18 17:58:30

DOSに割り込み処理時間の最大値の規定ってあったっけ？
DOSがリアルタイムとは思えないんだが。

**login:Penguin** · 04/12/18 19:31:26

>>620
そんなん自力で割り込み処理すりゃいいことですがな。
仮想86モード使われると悲惨な事になるが。

**login:Penguin** · 04/12/18 21:20:14

>>621
それはリアルタイムモニタ上でDOSが動いているんじゃないか？

**login:Penguin** · 04/12/20 23:39:00

　　
スレの雰囲気が、インド人と中国人の会話みたいになってきたね。
やつら偉そうにぺらｐらうわなにをあｓふぃえdosあｊｋヵrtおｄｆ
　　

**login:Penguin** · 04/12/20 23:52:54

>>623
宇宙人ハケーン

**login:Penguin** · 04/12/20 23:55:09

ハードリアルタイム(?)からハードウェアの話になったりして、
なかなか楽しい雑談じゃないか。少なくとも偉そうには見えないな。

**login:Penguin** · 04/12/21 01:13:07

ハードリアルタイムぐらいググれよ…
ttp://homepage3.nifty.com/ryuz/oo/chapt06.html
ttp://www.kumikomi.net/article/explanation/2001/05rtos/12.html

あと、もうちょっと具体的に触れているものだと
ttp://www.microsoft.com/japan/windows/embedded/community/experto/july2002/nframpton.asp
ttp://www.microsoft.com/japan/windows/embedded/community/experto/july2002/nframpton.asp
ttp://www.sakamura-lab.org/TRON/ITRON/DOC/mst97-rt3-ohp.pdf
ttp://www.sakamura-lab.org/TRON/ITRON/DOC/seminar97-ohp.pdf

本だと
ttp://www.cqpub.co.jp/hanbai/books/33/33261.htm

**login:Penguin** · 04/12/21 21:37:43

>>625は、>>610の「ハードなやつ」がハードリアルタイムを言っているのか
分からないから(?)なのだ。

**login:Penguin** · 04/12/24 14:29:41

DIOボードを制御しようとしてlspciでIOポート調べて（0xe000だった。）
outb(0x01,0xe000);
とやってみたのだが出力されない・・・・・
どんなことが考えられるでしょう？ハードウェアはwinで起動して動作しているので
大丈夫のはずなのですが・・・

そのプログラムのポートを0x378にするとちゃんとパラレルポートは動くのに・・・

**628** · 04/12/24 16:16:37

うわっ！大ポカでした！
入力ポートに出力してどーするよ・・・orz

**login:Penguin** · 04/12/24 17:00:44

がんがれ・・・・ﾎﾞｿ

**login:Penguin** · 04/12/25 01:29:20

Monta がハードリアルタイムに手を出すとな。
NTT ドキュモから出資は受けるわ、末期症状かねー？

**login:Penguin** · 04/12/25 11:53:57

門多ビスタはすでに坂村先生とこでT-Linux開発済んでるよ

**login:Penguin** · 05/01/02 13:45:22

RTAI使っているけど、3.0になってから面倒になってきたな｡インストール時のトラブル
は勿論、インストール後も共有メモリ関連でトラブルが発生したり･･･｡MLもその
話題で賑わっている。ユーザー空間でリアルタイム処理ができるので使っていたが、だんだん
困ったもんだ。

**login:Penguin** · 05/01/06 14:31:02

pSOSお勧め

**login:Penguin** · 05/01/06 16:22:46

>>634 もうないって(w

…もしかして、どこかで今でもサポートされてるとか？

**login:Penguin** · 05/01/06 23:52:57

>>635
ウインドリバーが買ったけどサポートされてるとはいえないだろうね。　前の会社でｐSOS使ってて
3年前に新しいボードに移植したときロイヤルティーの交渉はウインドリバーとした。　もちろん
vxWorksに乗り換えることを進められたけどね。　まあうちはpSOSのソース全部もってたから
激しくカスタマイズしてたけど。　TCP/IPのスタックは全部入れ替えたし。

**login:Penguin** · 05/01/07 02:55:46

S-OSかと思った。
あれは便利だったよね。

**login:Penguin** · 05/01/17 17:08:07

Pentium4 1.5GHzでRedhat Linux 9.0のマシンにRTLinux入れようとしているんですがうまくいきません。
前にAthlon2000+のマシンに入れたときはうまくいったんですが。

ttp://yama-tabi.net/blog/archives/2004/12/rtlinuxfree_1.html
を参考にインストールを進めたんですが、make xconfigの設定が分からなかったので
GUIの画面で/usr/src/linux-2.4.20-8/configs/kernel-2.4.20-i686.configをロードして
インストールを進めるとエラーも出ずにdepmod -aまでいき、GRUBの設定を書き換えて
再起動するとKernel Panicが。root=LABEL=/でエラーがでていたのでroot=/dev/hda2にすると
そのエラーは回避できましたが今度は
Warning unable to open an initial console.
Kernel panic: No init found. Try passing init=option to kernel
といわれてしまいました。init=/bin/bashとかつけてもうまくいきません。

どなたか原因わかりませんか？ファイルシステムはext2です。

**login:Penguin** · 05/01/17 20:13:35

>>638
rootの指定が間違っているとしか。
元のカーネルで起動して、'/'がどこにマウントされてるか確認すれ。

**login:Penguin** · 05/01/18 20:37:56

Vine Linux 2.6にkernel2.4.20おとしてきてRTLinux入れたんだけど、
Video4Linux2って入れれるの?
RTのパッチあててxconfigするときにVideo For Linuxはmにしてあるんだけど,
V4L2じゃないよね・・・SAA7130が使いたい。

V4L2のパッチあてたらRTのパッチ当てられないんだろうか。

**login:Penguin** · 05/01/25 22:04:55

RT-Linuxで作った楽器ぽいage
http://linux.slashdot.org/article.pl?sid=05/01/21/012244&tid=141&tid=106
http://namm.harmony-central.com/WNAMM05/Content/Korg/PR/OASYS-studio.html
http://www.korg.co.jp/OASYS/

**640** · 05/01/26 01:19:53

Linuxでビデオスレで聞いてみます。

**login:Penguin** · 2005/03/31(木) 17:46:46

質問があります。
CPU：Pentium4 3.80GHz、マザー：D915PBL(intel915P)、メモリ: DDR2SDRAM(１GB)、
OS：FedoraCore1のマシンに、kernel－2.4.20でRTLinux－3.2－pre2をインストールしました。

ためしに、1秒周期で処理を行うプログラムを作ったところ、10倍弱のスピードで処理してしまいます。
RTLinuxのモジュールを組み込んだ後におかしくなるらしく、
コンソールに普通に文字を打っても、同じ文字が連続して出力されたり
ダブルクリックを受け付けなかったりします。(かなり早くクリックすると受け付けます(笑))

モジュールを組み込んだ後におかしくなるので、rtl_timeが原因なのかと思っているのですが解決法が見当もつきません。
どなたか解決法が分かる方がいらっしゃいましたら、お教えください。
よろしくお願いします。

**login:Penguin** · 2005/03/31(木) 23:39:31

>>643
サンプルプログラムは全部正しく動いているか確認した？

**643** · 皇紀2665/04/01(金) 09:40:50

>>644
返事が送れて申し訳ありません。
サンプルプログラムも10倍弱で動作しました（frank_app等）。
pthread_make_periodec_np()で設定した値の10倍弱の速度で動いているようなんです。

カーネルを2.4.21－pre5にするか、CPUをちょと遅いのに変えるかして
もう一度確認しようと思っています。
引き続き、アドバイスをよろしくお願いします。

**login:Penguin** · 皇紀2665/04/01(金) 10:21:31

>>645
ハイパースレッディングとか大丈夫？

**643** · 皇紀2665/04/01(金) 12:09:21

>>646
BIOSでHyper-Threading Technology [Disable]と設定しました。
カーネルのコンパイル時の設定でハイパースッレディング関係で
気をつけることはあるのでしょうか？

コンパイル時の設定では
・プロセッサータイプが"PenⅢ"になっていたので"Pen４"に変更。
・ネットワークドライバの変更。
の２点をいじりました。

また、RTLinux-3.2-pre3を手に入れ、kernel-2.4.22でインストール
したのですが、症状は同じでした。orz
皆さん、アドバイスありがとうございます。
引き続きよろしくお願いします。

**643** · 皇紀2665/04/01(金) 16:09:05

コンソールに普通に文字を打っても、同じ文字が連続して出力されたり
ダブルクリックを受け付けなかったりする点ですが、
rtl-schedを読み込んだときにそのような症状になります。
リアルタイム処理が設定値の10倍弱で処理される点も、rtl-schedが
原因だと考えているのですが…。色々調べて、また報告します。
よろしくお願いします。

**login:Penguin** · 皇紀2665/04/01(金) 16:55:28

Pen4 でも RTLinux でもないんだが気になったので・・・
kernel config の CPU Frequency scaling はどうなってます？
もし、Enable ならはずしてみそ。

**643** · 皇紀2665/04/01(金) 18:27:26

>>649
アドバイスありがとうございます。
make xconfigでCPU Frequency scaling を探したのですが、
項目を見つけられませんでした。
カーネルのバージョンが古いのでしょうか？
ちなみに、Advanced Power Management ははずしてあります。

**login:Penguin** · 皇紀2665/04/01(金) 20:40:27

>>650
ゴメっ！
間違えた！
kernel 2.4系だったね。 2.6系とごっちゃになってた。
無視して下さい。

**643** · 皇紀2665/04/02(土) 00:00:03

>>651
2.6系だったんですか（^^;）
いえいえ、ありがとうございます。
勉強になりました。

**643** · 2005/04/05(火) 11:01:08

gethrtime()を表示させてみたんですけど、
手で測ってみた時間よりも6倍(10倍弱ではありませんでした)速い…。
でもコンソールでtime <プログラム名>で実行時間を出力してみると
手で測った時間と一緒…。

gethrtime()がおかしいんですけど、
ハードウェアに依存するのならばコンパイル時の設定がだめなのかな？
もっと調べてきます。
皆さん、お気づきの点がありましたらご教授ください。

**login:Penguin** · 2005/06/17(金) 12:03:03

RTLinuxがてにはいりません。こまりました。

**login:Penguin** · 2005/06/17(金) 12:35:52

http://www.fsmlabs.com/rtlinuxfree.html
あるぢゃん。

**login:Penguin** · 2005/06/17(金) 21:51:50

ぢつは RTAI が欲しいだけだったりして
http://www.rtai.org/

**login:Penguin** · 2005/06/19(日) 06:37:27

RTLinuxとRTAIとTimeSysで迷っているのですが、
GPL版ではRTLinuxはユーザー空間でのリアルタイム処理不可の為
RTAIかTimeSysで迷っています。RTAIはGPLしか無いようですが、
TimeSysのGPL版は使える物なのでしょうか？

**login:Penguin** · 2005/06/19(日) 18:14:39

TimeSysのGPL版は、プリエンプティブルカーネルではありますが、
高精度タイマは使えません。
10ms以下のワンショットタイマ、インターバルタイマが欲しいので
あれば、TimeSysのGPL版ではダメです。Realtime版を購入する
必要があります。
プライオリティ付きのトップハーフ、ボトムハーフが必要なだけで、
高精度タイマは不要、ということであれば、GPL版でOKだと思います。
詳細は日新システムズのWebで。
http://www.co-nss.co.jp/products/realtime/realtime-info.html
メンバー(登録無料)専用ページにマニュアルやFAQがあります。

**654** · 2005/06/19(日) 18:54:39

http://www.fsmlabs.co.jp/fsmj/products/rtlinuxfree.html

日本のページではこうでてくるのですが。

リンク先）FSMLabs Japan Products

■RTLinux/Free CD-ROMサービスは終了いたしました。

**login:Penguin** · 2005/06/20(月) 20:22:40

RTLinux Free版は、ここからダウロードできるのでは。
http://www.rtlinuxfree.com/

**657** · 2005/06/21(火) 15:58:33

>>658
貴重なアドバイスありがとうございます。
色々調査した結果です。
１：RTLinux
　文献、資料が他より多く、応答良いがＧＰＬではユーザー空間でのリアルタイム処理不可。

**657** · 2005/06/21(火) 16:11:22

６６１：続き

２：TimeSys
　応答良いがＧＰＬではソフトリアルタイムのみ。ＰＲＯは高価。
３：RTAI
　応答良いが文献、資料が少ない。

結局、貧乏人の私にはＲＴＡＩが一番良いと思われます。
ＲＴＡＩはＧＰＬのみなので差別化も無いし応答も良いし…
用途は機械制御タスクを数ｍ秒毎、測定制御のタスクを数十μ秒毎に走らせたいのです。

ＧＰＬで最強なのは何でしょうか？

**login:Penguin** · 2005/06/22(水) 00:15:02

>>662
ユーザ空間でリアルタイム処理する必要ないし
RTLinuxでよくね？

**login:Penguin** · 2005/06/22(水) 01:33:15

>>662
TimeSysのRealtime版は、かなり安いと思います。デスクトップパソコン1台よりも
安いハズ。Reservation版の値段は知りません。

そもそも根本的に、リアルタイム化している実現方法が、TimeSys/MontaVista/オリジナルKernel2.6と、
RTLinux/RTAIでは違います。
Linux上のアプリケーションをリアルタイムで処理したいなら、TimeSys/MontaVista/オリジナルKernelです。
RTLinux/RTAIは、独自のリアルタイムカーネル上でLinuxを動かす方式なので、Linux上の
アプリケーションはリアルタイム処理できません。リアルタイム処理が必要なものは、Linuxの
アプリではなく、独自のリアルタイムカーネル上で動くように作る必要があります。
↓このへん参照。
http://www.atmarkit.co.jp/flinux/embedded/rtos01/rtos01a.html

**662** · 2005/06/22(水) 01:44:22

>>663
あれ？その通りです…が、逆にＲＴ空間でPCIやLANやその他ドライバ等の
使用出来ない物が多いのでは？

**login:Penguin** · 2005/06/22(水) 01:52:39

で、数10μs間隔の定周期処理を実現するとなると、OSの機能に頼るのでは、
実現は難しいと思います。
http://www.atmarkit.co.jp/flinux/embedded/rtos02/rtos02c.html
ここにオリジナルKernel/RTLinux/RTAIでの測定結果が出ています。
このオリジナルKernelは、"Preemptible"を無効にした状態なので、
リアルタイム処理できない状態です。Preemptibleなら、もっと性能はいいハズ。

RTAIが一番性能がいい結果になっていますが、それでも977μs周期処理が、
負荷をかけていない状態(hackbenchなし)でも最大で5μs程度ずれています。
なので、例えば、正確に10μs周期が必要でも、5μs～15μsの周期になります。
まぁ、90μs周期で、85μs～95μsになる、というのであればいいのかもしれませんが...
どこまで、時間の正確性が必要なのか、というところにかかっていると思います。

**login:Penguin** · 2005/06/22(水) 02:00:26

TimeSys Realtime版では、上記測定結果のRTLinuxと同じぐらいの性能を、ユーザ空間で動く
アプリケーションで実現できます。たぶん、オリジナルKernel2.6のPreemptible版も。
(clock_settimeだったか何だかのAPIで、定周期タイマを生成して、定周期スレッドを
動かす場合。TimeSysのGPL版には高精度タイマがないのでムリ。)

**login:Penguin** · 2005/06/22(水) 02:36:45

RTLinuxやRTAIでは、専用のAPI(システムコール)を必要とするのに対して、
clock_settimeとかはPOSIX APIなので、普通にPOSIXのタイマを使った
アプリを作るだけで、リアルタイム化される、というメリットがあります。

が、そのプロセス/スレッドを、pthread_setschedparam とかでSCHED_FIFO
にスケジューリングポリシーを設定、とかしないといけないので、RTLinux/RTAIで
専用APIを呼ぶのと大差ないかも。

ホントに数10μsの定周期処理で、1μsぐらいの時間の正確性が必要なら、
カーネル空間で動くボトムハーフやタスクレットとして実装(オリジナルKernel2.6の
Preemptible版/MontaVista/TimeSys)するか、RTLinux/RTAIのリアルタイムKernel上で
直接動くタスクを作る(できるかどうか知りませんが...)か、ということを検討する必要が
あるのでは。

**665** · 2005/06/22(水) 02:45:41

>>666
>>667
>>668
あいがとうございます！
実際には100μs周期で測定して±10μsなら良いかな？と思っています。
Pen4の2GHz位で10μs周期で走れば良いのですが。
RTLinuxやTimeSysのPro版は100万位（定価）でとても買えません。
GPL版は性能、機能に差がありすぎて…なんか感じ悪いです。
しかしRTAIはGPL版しか無いので最高の物が使えます。
GPLではRTAIが一番と思いませんか？

**665** · 2005/06/22(水) 03:03:55

RTAIの文献、資料等ぜんぜん見つからないのですが、
何処かにありませんか？

**login:Penguin** · 2005/06/22(水) 19:59:21

>>669
>RTLinuxやTimeSysのPro版は100万位（定価）でとても買えません。
RTLinuxは知りませんが、TimeSysのRealtime版(x86)を去年購入しましたが、そんなに高くないですよ。
1年ぐらい前に、急激に安くなりました。
と思いましたが、安くなったのはx86版だけでした。他のCPUは安くなかったですね...

**login:Penguin** · 2005/06/22(水) 20:17:34

>>669
>GPLではRTAIが一番と思いませんか？
条件によって向き不向き(メリット・デメリット)があるので、一概には言えないですね。

個人的には、
数10μsのタイマ精度までは不要ということであれば、オリジナルKernel2.6を
Preemptibleにするだけで十分。
XIPやファイルサイズの小型化が必要なら、MontaVista。(めっちゃ高いけど)
CPUやネットワーク資源の予約(Reservation)が必要なら、TimeSysのReservation版。
という感じです。

お金が必要なMontaVistaやTimeSysのKernel2.6版も、ライセンスはGPLだと思いますよ。
GPLだからといって無償とは限らないですし、誰でも入手可能にしなければならないことも
ないですし。
(Kernel2.4ベースのTimeSysは、独自の「リソースカーネル」部分はGPLではありません。)

**login:Penguin** · 2005/06/22(水) 20:20:31

>>670
RTAIの資料、ちょっとググってみましたが、結構あるのでは？
http://www.misnet.co.jp/tech/info/linux/bluecat.html
http://www.aero.polimi.it/~rtai/

RTAIのwebにもドキュメントはありますし。
http://www.rtai.org/modules.php?name=Content&pa=showpage&pid=6

**login:Penguin** · 2005/06/23(木) 11:03:31

>>671
>>672
>>673
毎度お世話になります。

>安くなったのはx86版だけでした。
そうですか！私は市販のPC-ATパソコンを使用したいのですが、x86版で使えますよね？
早速、日新システムズに確認してみます。（でも、やはり数十万はしますよね…）

>数10μsのタイマ精度までは不要ということであれば、オリジナルKernel2.6を
>Preemptibleにするだけで十分。
これでいければ一番ですね！Fedora4をDownloadしてPreemptibleにする（どうやるんだ？）ばいいのですね。
数10μsの精度…微妙です。数100μずれるとちょっときついかな？
今はＰＣにＤＩＯボード２枚入れて1msの矩形波を出力するタスクを２本走らせてオシロで観測しています。
最初Redhat7.2で確認したらマウス使うだけで波形がビョ～ンと伸びてビックリ！（あたりまえですが…）
タスク切換周期は100ms位でした。

**login:Penguin** · 2005/06/23(木) 11:46:37

↑つづき
>お金が必要なMontaVistaやTimeSysのKernel2.6版も、ライセンスはGPLだと思いますよ。
>GPLだからといって無償とは限らないですし、誰でも入手可能にしなければならないことも
>ないですし。
そうですね、すみません。どうもGPL＝Freeのイメージがあって…
並びにＲＴＡＩ資料関係ありがとうございました。実験して見ます。

**login:Penguin** · 2005/06/23(木) 19:25:24

>>674
>Fedora4をDownloadしてPreemptibleにする（どうやるんだ？）
カーネルを再構築すればOK。make xconfigとかでconfig画面のどこかの
項目にPreemptionとか何とか出てくると思います。
ただし、もしかしたら安定版カーネルには、まだPreemptパッチが取り込まれて
いないかも。なのでFedora4のカーネルでOKかどうかは知りません。
開発版カーネルには入ってるはずなので、Fedora4のカーネルになければ、
オリジナルの開発版をダウンロードして再構築してみてください。

**login:Penguin** · 2005/06/23(木) 19:45:50

念のため補足しておきますと、いくらカーネルがPreemptibleになっているといっても、
プロセス(スレッド)のスケジューリングポリシーをSCHED_FIFO(2.6では名前が
かわっているかも)にするとか、clock_settimeとかでインターバルタイマを作る
とか、リアルタイム処理になるよう、プログラミングする必要はあります。

RTAIの場合でも、rt_XXXXとかでリアルタイムタスク/タイマ用のAPIを使わないと
リアルタイム処理できないので、そういう意味では同じようなもんですが。

**login:Penguin** · 2005/06/24(金) 01:19:28

>>677-678
2.6ならPreemptionの項目は普通にあると思うけど、
Real-Time Preemptionのパッチの話だったらまだじゃない？
この辺に少し載ってるね。
ttp://www.atmarkit.co.jp/flinux/rensai/watch2005/watch06b.html

674では無いですが、MontaVistaのサイトみたら1m以下で応答する
ように頑張るみたいな事が書いてあったけど、素の2.6で1msの矩形波を
出力できる程のものなんでしょうか？

**674です。** · 2005/06/24(金) 18:31:52

>>676
>>677
>>678
こんにちは。
Fedora4インストールしました。もしかしたらすごい応答良かったりして…なんて思ったのですが、
素のままでは上記Redhat7.2での実験と変わりませんでした。（タスク切換周期約100ms）
make xconfigでPreemptionらしきものが見つからない…どうしよう？
もし見つかればこの□にチェックすれば応答が良くなるのですか？

niceで優先度上げたタスクは100ms内できちんとパルスを出すのですが…
単純にタスク切換周期を100ms→1ms（出来れば100us）にする事は出来るのですか？

**678** · 2005/06/24(金) 23:12:03

>>679
こっちの方に知りたいことが書いてあった。
　ttp://www.atmarkit.co.jp/flinux/embedded/rtos02/rtos02c.html

Real-Time Preemptionの結果が気になるところだけど、ユーザ空間で
1msなんてRTLinuxやRTAIでもお話にならないレベルですね。

素直に、マイクロカーネル上のリアルタイムタスクにするしかなさそう。

**login:Penguin** · 2005/06/25(土) 10:48:21

>>679
>もし見つかればこの□にチェックすれば応答が良くなるのですか？
カーネルがプリエンプティブル(Preemptible)になっていない場合、システムコール発行などで
カーネル内に処理が移ると、そのカーネル内の処理が終わるまで、ユーザ空間のプロセス(スレッド)
は処理できません。カーネル全体をロックしているので「ジャイアントロック」とか「ビッグロック」
とか呼ばれています。このジャイアントロックは結構長い時間(数ms～数10ms)かかるので、
いわゆる「応答時間」の性能はかなり悪くなります。
カーネルをプリエンプティブルにすると、カーネル全体をロックせず、クリティカルセクションだけ
をロックするようになるので、応答時間の性能が良くなります。ただし、ロックをクリティカルセクション
だけにするのは各種デバイスドライバが対応する必要があるので、使用するドライバがどのくらい
きちんとプリエンプティブルにしてくれているか次第、というところがあります。
DIOでパルス出力しているとのことですが、Interface社のDIOボード+Linux用ドライバなどを使っている
場合は、そのドライバがどうなっているか、というところにも依存します。
が、DIOでパルス出力するだけなら、あんまり気にする必要ないかもしれませんね。

**login:Penguin** · 2005/06/25(土) 10:58:26

>>679
>niceで優先度上げたタスクは100ms内できちんとパルスを出すのですが…
niceじゃなくて、スケジューリングポリシーをRealtime(SCHED_FIFO)にした上で、
プライオリティを高くしておかないと、少し負荷がかかっただけで、周期を守れなくなりますよ。

それに、素のままのカーネルでは、インターバルタイマやウェイト/スリープAPIの周期を
10ms以下に設定しても設定通りにはなりません。カーネル内のタイマ周期が10msになって
いるため、それ以下の時間で制御できないためです。
素のカーネルで10ms以下のタイミングが必要なら、プリエンプティブルにするだけでなく、
カーネル内のタイマを1msに設定するなどのconfigも必要です。

**658,664,676,681** · 2005/06/25(土) 11:08:10

>>679
>2.6ならPreemptionの項目は普通にあると思うけど、
>Real-Time Preemptionのパッチの話だったらまだじゃない？
なるほど。
TimeSysのプリエンプティブル化方法は、spin_lockに対して行われているので、
同じレベルにするには、少なくともこのReal-Time PreemptionのPREEMPT_RT
が必要なようですね。

**658,664,676,681** · 2005/06/25(土) 11:39:43

>>680
>Real-Time Preemptionの結果が気になるところだけど、ユーザ空間で
>1msなんてRTLinuxやRTAIでもお話にならないレベルですね。
そのweb記事では、約977μs(記事中に977msと記述されている部分がありますが、
"ms"ではなく"μs"の間違いですね)の定周期割込みが、RTAIでは負荷がかかっても
最大2μs程度しか時間のゆらぎは発生していません。
この数値が、必要としている精度とどのくらい差があるかというところですが...
約1ms周期で2μsのゆらぎなら、私の場合は、十分使えるレベルです。
まぁ、1μs以下の精度が必要なのであればダメですが、その記事では、PentiumMを400MHzに
固定しての結果なので、Pentium4の3.6GHzとかならもっといい性能を出せるかもしれませんね。

**658,664,676,681** · 2005/06/25(土) 12:02:23

>>684
>最大2μs程度しか時間のゆらぎは発生していません。
間違えました。
最大10μsぐらいありますね。それでも私の場合は十分ですが。

この、
　ttp://www.atmarkit.co.jp/flinux/embedded/rtos02/rtos02c.html
の測定方法とは違いますが、「Embedded UNIX Vol.3(CQ出版)」の「TimeSys Linuxの
全貌」という記事に、同じようなジッタの測定結果が出ています。
CPUに50%の負荷をかけた状態で、定周期スレッド(1,2,3,4,5msと変化させて5回測定)が起動する毎に
時間を測定し、そのゆらぎがどのぐらになるか、を測定しています。
最小の1ms周期で、最大19μsという結果です。
Embedded UNIX Vol.3の記事では、測定に使用したCPUやプラットフォームが書かれていませんし、
測定方法が違うので、@ITの記事と比較するのは問題ありそうですが、このTimeSysの数値はRTLinuxと
同じぐらいの数値です。

**679です。** · 2005/06/25(土) 15:15:41

>>680
>Real-Time Preemptionの結果が気になるところだけど、ユーザ空間で
>1msなんてRTLinuxやRTAIでもお話にならないレベルですね。
>素直に、マイクロカーネル上のリアルタイムタスクにするしかなさそう。
そうですか…ユーザー空間での1ms周期はKernel2.6でもRTAIでもTimeSysでも無理なんですか…
やはりRTAIかTimeSysのRT空間使うしかないのかな？
TimeSysは少し違うみたいだけどユーザー空間でリアルタイムタスク走れて、1ms周期とか出来るんですか？

**679です。** · 2005/06/25(土) 15:30:55

>>681
>カーネルをプリエンプティブルにすると、カーネル全体をロックせず、
>クリティカルセクションだけをロックするようになるので、応答時間の性能が良くなります。
すみません。Fedora4で実験しているのですが、まだカーネルをプリエンプティブルにする方法が分からないのです…
DIOはPCIBIOSよりベースアドレスを取得して自前で制御しているのでドライバは使っていません。

**679です。** · 2005/06/25(土) 15:41:19

>>682
>素のカーネルで10ms以下のタイミングが必要なら、プリエンプティブルにするだけでなく、
>カーネル内のタイマを1msに設定するなどのconfigも必要です。
カーネル内のタイマを1msに設定するにはmake xconfig画面内の設定を変更するのでしょうか？

**679です。** · 2005/06/25(土) 16:04:21

>>683
TimeSysはRTAIより良いですか？

**login:Penguin** · 2005/06/25(土) 18:59:09

RTLinuxのインスコの仕方教えてください

手元にあるのは　rtlinux-3.1.tgz
環境は　redhat9

tgzを展開するまではいいのですか
その先が分かりません

**658,664,676,681** · 2005/06/25(土) 19:08:50

>>686
>そうですか…ユーザー空間での1ms周期はKernel2.6でもRTAIでもTimeSysでも無理なんですか…
685に書いたように、私には十分と思える精度がありますがねぇ。
RTAI：977μs周期プロセスのジッタが±約10μs。
TimeSys：1ms周期スレッドのジッタが±約20μs。
どちらも定周期で起動しているのはユーザ空間のプロセス・スレッドです。

**login:Penguin** · 2005/06/25(土) 19:20:30

>>690
まずはドキュメントよく嫁

**658,664,676,681** · 2005/06/25(土) 19:44:22

>>687
>すみません。Fedora4で実験しているのですが、まだカーネルをプリエンプティブルにする方法が分からないのです…
ググると、Fedora4ではないですが、こういうところがヒットしますよ。
http://www.jacklab.net/index.php?option=com_content&task=blogcategory&id=236&Itemid=221&lang=en_EN

>>688
>カーネル内のタイマを1msに設定するにはmake xconfig画面内の設定を変更するのでしょうか？
どうやら、kernel2.6ではdefaultで1msになっているようです。
http://www.lifeflow.jp/diary/index.php?p=114

**658,664,676,681** · 2005/06/25(土) 20:08:41

>>689
>TimeSysはRTAIより良いですか？
条件によって、どちらが良いとは限らないです。

POSIX APIでリアルタイム処理したいならTimeSys。
RTAI専用APIでもいいからより高い応答性能が必要ならRTAI。
というところじゃないでしょうか。
まぁ、仕事で使うなら、それぞれのサポート費用とそのサポート部門の技術力や親切具合
(困ったときにどれぐらい助けてもらえるか)も考慮することになりますね。
ただし、どれぐらいサポートが充実しているかは、サポートを受けてみないとわからないのが
難点です。

**680** · 2005/06/25(土) 21:58:49

>>684
＞ "ms"ではなく"μs"の間違いですね

お陰で1000倍も読み違えるところでした。ご指摘多謝。

**login:Penguin** · 2005/06/26(日) 00:04:06

>>692
どのドキュメントでつか？

**login:Penguin** · 2005/06/27(月) 18:07:08

スタンドアロン方式とリアルタイム性能
http://www.atmarkit.co.jp/flinux/embedded/rtos03/rtos03a.html
連載：LinuxによるRTOSの実現（3）　リアルタイム機能をLinuxカーネル自身で実現するスタンドアロン方式。この方式の具体的な実装やリアルタイム性能を検証する

**login:Penguin** · 2005/06/27(月) 23:25:06

RT-FIFOについて質問なのです．
RT→Linuxという経路でデータを周期的に転送する際に，
RTスレッドの方が実行周期が早いためLinux空間でデータを
FIFOから読み出すより早く次のデータが書き込まれにRT-FIFOから
あふれてしまいます．今のところRT-FIFOを作成する際にできる限り
大きな値で作成してごまかしていますがそれでも送れるデータの数に
限界があります．
mallocによるメモリの確保などと同じように大サイズのRT－FIFOを作る
方法は無いものでしょうか？

**686です。** · 2005/06/28(火) 11:53:54

>>691
>RTAI：977μs周期プロセスのジッタが±約10μs。
>TimeSys：1ms周期スレッドのジッタが±約20μs。
>どちらも定周期で起動しているのはユーザ空間のプロセス・スレッドです。
これはユーザ空間のデータですか！いいですね！このケースだとRTAIが若干いいですね。

**login:Penguin** · 2005/06/28(火) 15:12:59

vine linux 2.6r4にART-linux カーネルをインストールしました。
ARTカーネルで起動するとXが立ち上がりません。
こんな経験をされた方おりませんか？

**688です。** · 2005/06/28(火) 15:31:38

>>693
>すみません。Fedora4で実験しているのですが、まだカーネルをプリエンプティブルにする方法が分からないのです…
>ググると、Fedora4ではないですが、こういうところがヒットしますよ。
>http://www.jacklab.net/index.php?option=com_content&task=blogcategory&id=236&Itemid=221&lang=en_EN
ありがとうございます。英語か…
>どうやら、kernel2.6ではdefaultで1msになっているようです。
>http://www.lifeflow.jp/diary/index.php?p=114
Fedora4(kernel2.6.11)でも確認しました。HZ 1000
USER_HZ 100 は何でしょう？
HZ 1000 なのにタスクが100ms周期なのは？

**689です。** · 2005/06/28(火) 15:49:25

>>694
>POSIX APIでリアルタイム処理したいならTimeSys。
>RTAI専用APIでもいいからより高い応答性能が必要ならRTAI。
的確な回答、大変ありがとうございます。
POSIX APIでリアルタイム処理したいんでTimeSysと言いたいんですが、
お金の問題があるからRTAIです。RTAI専用APIそんなに沢山ないですよね…

>仕事で使うなら、それぞれのサポート費用とそのサポート部門の技術力や親切具合
RTAIもFree版以外にPro版があるのですか？
それとも有料サポートだけですか？

**login:Penguin** · 2005/06/30(木) 01:34:02

>>698
FIFOのサイズが大きければ溢れるのを回避できるという理屈がイマイチわかりませんが、
抜き取り処理がたまに遅れて、そのときに溢れてしまうってことなのかなぁ。

rtlinuxならmbuffでも使ってみたらどうでしょうか？

**691,693,694** · 2005/07/01(金) 18:58:26

>>701
>USER_HZ 100 は何でしょう？
元の100Hz用のdefineを残す、という意図でしょうか。よくわかりません。

>HZ 1000 なのにタスクが100ms周期なのは？
？？？このHzはカーネル内部のタイマの精度のことですよ？
nanosleepなどでwaitする時、以前は10ms以下にしても働いていなかったのが、
1msまでは働くようになった、ということです。どうやって100ms周期タスクを作ってますか？

ただ、オリジナルの2.6のままではあまり正確性はないかもしれません。
http://www.atmarkit.co.jp/flinux/embedded/rtos03/rtos03a.html
↑ここにあるように、Real-Time Preemptionパッチをあてれば、かなりいい感じになるようです。

**691,693,694** · 2005/07/01(金) 19:33:40

>>702
>RTAIもFree版以外にPro版があるのですか？
>それとも有料サポートだけですか？
前は、Lineoがサポートしていたと思ったのですが、現在はよくわかりません。

6/29,30とESEC(組み込み開発技術展)に行ってたのですが、そこで見つけたElinOSというのが
RTAIをサポートしているようです。ただ、このRTAIがDIAPMで開発されているRTAIと同じ
なのかどうなのかは知りません。
http://www.4link.co.jp/products/elinos.html

趣味で使うならダウンロードしていじくっていればいいですが、仕事(製品に組み込む)となると、
何かトラブルが起きたときに自分でがんばるのかサポートを受けるのか、もし知的財産権の侵害が
発覚したときにどう対処するのか(サポートしてくれる会社とどう契約するのか)、などを考え
なければなりませんよね。

**698** · 2005/07/01(金) 20:47:06

>>703
アドバイスありがとうございます．
さっそく試してみます．

**login:Penguin** · 2005/07/02(土) 01:32:49

オセロとか

**login:Penguin** · 2005/07/02(土) 16:57:38

>>704

>>HZ 1000 なのにタスクが100ms周期なのは？
>？？？このHzはカーネル内部のタイマの精度のことですよ？
ありがとうございます。やはり内部タイマでしたか…

>どうやって100ms周期タスクを作ってますか？
100ms周期のタスクを作ったのではなく、1msの矩形波を出力するタスクを２本走らせてオシロで観測したら
周期が100msだったのです。

>http://www.atmarkit.co.jp/flinux/embedded/rtos03/rtos03a.html
>↑ここにあるように、Real-Time Preemptionパッチをあてれば、かなりいい感じになるようです。
おお、新しくなってる！ありがとうございます。

**702です。** · 2005/07/02(土) 17:02:03

>>705

>6/29,30とESEC(組み込み開発技術展)に行ってたのですが、そこで見つけたElinOSというのが
>RTAIをサポートしているようです。ただ、このRTAIがDIAPMで開発されているRTAIと同じ
>なのかどうなのかは知りません。
ElinOS知ってます。これいくら位するのですか？

**704,705** · 2005/07/02(土) 21:03:09

>>708
>100ms周期のタスクを作ったのではなく、1msの矩形波を出力するタスクを２本走らせてオシロで観測したら
なるほど。
でも、素のまま(Preemptibleでない)カーネルのままでも、
* mlockallでページアウト(スワップアウト)を禁止
* sched_setscheduler(pthread_attr_setschedpolicy)でスケジューリングポリシーをSCHED_FIFOにして、
かつ、プライオリティを高くする
とすることで、だいぶマシになると思います。
確かKernel 2.4.18で試したときは、このようにしたプロセスで、nanosleepで20msぐらいの定周期
は実現できたと思います。ただ、ちょっと他のプロセスを動かしただけで、10ms以上の遅延が発生して
しまいましたが。

>>709
>ElinOS知ってます。これいくら位するのですか？
値段は聞かなかったのでわかりません。聞いときゃ良かった...

**login:Penguin** · 2005/07/03(日) 14:53:10

うまくいかなくて思い余って、定周期で割り込みを発生するだけのH/W作ったなぁ。