(toppers-users 4554) Re: 周期タスク内でのファイルシステム利用時の処理時間について

森崇 tmori @ esm.co.jp
2016年 6月 8日 (水) 17:38:55 JST


日立オートモティブシステムズ 坂田様

永和システムマネジメント 森と申します.

お世話になります.

私も過去にSDカードのアクセス性能が極めて遅い現象を経験しており,
もしかすると似た原因かもしれませんので,情報展開させていただきます.

坂田様の調査・対応方針の参考になれば幸いです.

■現象
 ログファイルに,512byteのデータを追加書き(毎回sync)すると,
 1回のI/O復帰時間が極めて遅い場合があった.
 ※最悪値で数十ミリ以上かかっていましった(平均値で2ミリ程度).

■原因
 ①書き込み時に毎回open⇒lseek⇒closeしていた.
  ※これはWindows環境で試しても同じ結果でした.
  ※closeするとsync発生しますので性能劣化しますし,
  ※また,Fatfsの場合,lseekするとクラスタチェーンの参照によりREADが毎回でていました.
 ②ファイルシステムの下位レイヤ・インタフェース(SDカード・ドライバ)の
   データ転送コマンドがシングルブロックしか対応していなかった.

■改善施作
 ①書き込みタイミングでのopen, closeは行わない
  ※ただし,syncされないので,システムが落ちた場合は
  ※ファイルシステム破壊が発生する可能性があります..
  ※別途,検討が必要になります.
  ※ 例.定期的にsync発行する.システムダウン時は,ファイルシステムチェックを行う等.
 ②lseekせず,追加書きしつづける.
 ③ファイルシステムに対する要求書き込みサイズを増やす
  ※RAMに余力があったので,128KBまで増やしました.
 ④ファイルシステムのクラスタサイズを増やす(Fatfsの場合)
 ⑤下位レイヤ・インタフェース実装をマルチブロック対応した

 上記施作を行うことにより,10倍以上性能改善しました.

以上,よろしくお願いいたします.

2016年6月7日 17:41 SAKATA,KOSUKE / 坂田昂亮
<kosuke.sakata.oy @ hitachi-automotive.co.jp>:
> 高橋様、村中様、今様
>
> 大変お世話になっております、坂田です。
> とても分かりやすいご指摘を頂き有難うございます。
> 皆様からのご指摘を受けてだんだんと症状の原因が理解できて来ました。
> とはいえ、まだまだやってみなけりゃ分からないという状態なので、
> まずは皆様から頂きましたアドバイスを愚直に実行することが、問題解決の近道と思っております。
>
> 少なくとも周期タスクの中で毎回書き込み処理を行うことが不適格なようですのでまずはここから見直してみようと思います。
> 周期的に書き込みデータをキューして、一定の容量がたまった次点で他タスクにて書き込みという構成を取るように試みます。
>
> また、fpritnfの利用も見直してみようと思います。
> ある程度の書き込みデータを溜め込んで低水準の関数を用いて書き込みを行った場合の処理時間がどう変化するか
> 大変興味が沸いております。
>
> 短期間に非常に多くの、また的確なアドバイスを頂くことが出来て感激しております。
> 皆様の好意に報いるよう改善に励みたいと思います。
>
> 坂田
> -----Original Message-----
> From: users-bounces @ toppers.jp [mailto:users-bounces @ toppers.jp] On Behalf Of Masaki Muranaka
> Sent: Tuesday, June 07, 2016 10:29 AM
> To: users @ toppers.jp
> Subject: (toppers-users 4549) Re: 周期タスク内でのファイルシステム利用時の処理時間について
>
> みなさま、おはようございます。
>
>> うろ覚えですがFatFs場合、内部処理の待機にmsオーダーでWiatが入ることがあります。
>
> すべてのバージョンの FatFs を読んだわけではないのですが、FatFs の中に wait 処理は
> ないはずです。ファイルシステムにwaitを入れる理由もありませんし。
> その下のデバドラでは何があったとしても不思議ではありませんけれども。
>
> …とまで書いて、EV3RT 固有の話かも? と思ってざっとデバドラ読みましたら、確かに
> tslp_tsk(1000) など書いてあるコードでした。
> しかし時間の桁が違うので、今回の話との関係は薄いかなという気がします。
>
>
>
> 2016年6月7日 9:23 Nozomu Kon <nozomu.kon @ embedded-property.net>:
>> 日立オートモティブシステムズ 坂田様
>>
>> 今と申します。
>>
>> 他の方もおっしゃっていますが、SDカードとファイルシステムは状況によっては
>> 処理に時間がかかることがあります。
>>
>> 周期タスクは4ms内で完了する必要のあるクリティカルなものでしょうから
>> 周期タスク内でwirteを行うのではなく、ファイルシステム用のタスクを設け、
>> 周期タスクからはメッセージ送信のみに切り替えるといいのではないでしょうか。
>> (ファイルシステムタスクにメッセージをキューするイメージです)
>>
>> ファイルシステムタスクが4ms以内に受信可能状態に戻る保証はありませんが、
>> 少なくとも周期タスクは4msで定期的に動作するものと思われます。
>>
>> うろ覚えですがFatFs場合、内部処理の待機にmsオーダーでWiatが入ることがあります。
>>
>>
>> On 2016/06/06 10:10, SAKATA,KOSUKE / 坂田昂亮 wrote:
>>
>> お世話になります、日立オートモティブシステムズの坂田と申します。
>>
>> 弊社では例年新人教育の題材としてETロボコンに参加させて頂いており
>> 開発環境としてToppers殿製EV3RT hrp2 beta6-2を使用させて頂いております。
>> このたび、弊方では原因が分からない症状が発生いたしましたので、
>> 有識者の方々からのアドバイスを頂きたく投稿させて頂きました。
>>
>> 症状はファイルシステムの利用中に発生しております。
>> Mindstorms EV3に挿入するmicroSDカード内に予め作成したログ保存用フォルダに、
>> .csv形式で任意のテキストデータを書き込むプログラムを作成いたしました。
>> 書き込み処理(fprintf関数)は周期起動タスクで実行させており、周期は4msと設定しております。
>> fopen,fcloseは下記のごとく周期起動タスク外でタスク起動前、タスク終了後に実行しております。
>>
>> プログラム開始→fopen→周期タスク起動→(~~4ms周期で書き込み~~)→周期タスク終了→fclose→プログラム終了
>>
>> 症状はこの書き込み周期タスクの処理時間が一定の時間間隔で4msを大きく超えるタイミングが発生するというものです。
>> 書き込み周期タスクの処理時間は、平時は1ms以下で処理されるようですが、およそ180msに1回の時間間隔で10ms~20msほどかかるタイミングが発生しており、4ms周期を守れていません。
>> ちなみに、1周期の処理で書き込むデータ量は4byteの変数値1つ(+改行コード)です。
>> また、既定周期を4ms→10msと変更した場合でも、上記の症状が発生することを確認しており、
>> その場合、周期オーバーが発生する時間間隔が、およそ180ms→およそ450msに変化します。
>> 処理時間のモニタにはget_utm関数で取得したμ秒タイマ情報を使用しています。
>> 以上がこちらで確認している現象となります。
>>
>> つたない情報で恐縮ですが、一定時間間隔で処理時間が増大する症状の原因について、ご助言をいただければ幸いです。
>> 弊方がRTOSについて知識不足のため、初歩的なことを質問しているのかもしれませんが
>> これを機会にしっかりと学びたいと思っておりますので何卒宜しくお願い申し上げます。
>> ***************************************
>> 日立オートモティブシステムズ株式会社
>> 技術開発本部 先行開発室 スマートADAS技術開発部
>>  坂田 昂亮 Sakata Kosuke
>> TEL : 外線 080-9045-6345/029-276-9379 内線 54244
>> Mail: kosuke.sakata.oy @ hitachi-automotive.co.jp
>> 〒312-8503 茨城県 ひたちなか市 大字高場 2520番地
>> ***************************************
>>
>>



-- 
組込み技術センター
森 崇(もり たかし)
TEL:0776-25-8490
email:tmori @ esm.co.jp

Platformingサービス:http://www.esm.co.jp/service/platforming_service
AUTOSAR製品開発:http://www.esm.co.jp/service/autosar
組込みソリューション:http://www.esm.co.jp/service/etec_service