東京工業大学 情報理工学研究科 数理・計算科学専攻 千葉研究室 栗田 亮 感性を考慮した ジョブスケジューリング 東京工業大学 情報理工学研究科 数理・計算科学専攻 千葉研究室 栗田 亮

音楽聴きながら仕事してます ・・・しながら族 増加中 現在マシンは高性能 音楽を聴きながら 仕事する人は多い 研究室でも多く存在 DVD見ながら仕事 をするツワモノも

仕事が優先(当然!)なのですが・・・ ユーザの希望: 仕事が第一だけど音楽・映像も マシンにその希望は反映されない 実装, 論文作成などの仕事 → すばやく処理 音楽,DVD → 仕事の邪魔にならなければよい マシンにその希望は反映されない 仕事の処理を優先させる 音楽・映像が途切れて不快 音楽・映像再生を優先させる 仕事の処理が遅れる

感性を考慮したQoS処理 仕事があくまで優先! 音楽・映像には感性を考慮したQoS処理を行う マシンには仕事の処理を優先させる 途切れなどによるユーザへの不快感を抑制 例) 音楽のフェードアウト 途切れを防ぐには止めるしかない場合もある その際にフェードアウトさせることでユーザへの不快感を抑えることが可能

Tanma 重要性の低い音楽再生処理に対しQoS処理を行うシステム ユーザに不快感を与える前に音楽を制御 音楽再生処理の進捗情報を利用するスケジューリング 音楽の停止・再開に伴うユーザへの不快感を抑制 音量の自動調整 タイムマシン再生 Linuxカーネル上に実装 アプリケーションを書き換える必要なし

Tanmaのスケジューリング 重要性の高い処理が阻害されているときだけ 音楽を制御 音楽再生処理による阻害 状況に応じて資源割り当てを変更 重要性の高い処理が阻害されているときだけ　　音楽を制御 音楽再生処理による阻害 CPUなどの資源の競合（奪い合い）により処理が遅れる 状況に応じて資源割り当てを変更 阻害されている場合 → 音楽を制御 阻害されていない場合 → 音楽をそのまま続行 従来のCPUスケジューリングでは困難 CPU以外の資源の競合を探知できない

Progress-based regulation [J.R.Doucer 99] 進捗情報を用いるスケジューリング手法 プロセスの進捗をもとに資源競合を探知 重要性の低いプロセスの進捗に注目 進捗が悪化 = 重要性の高いプロセスとの資源競合　　　 → 重要性の高いプロセスの処理を阻害 資源によらずに競合の探知が可能 資源競合を解消するためにプロセスを制御 重要性の低いプロセスを一定時間停止 → 重要性の高いプロセスが阻害されなくなる

Tanmaによる進捗状況判定 Progress-based regulationを音楽処理に適用 進捗値 ＝ カーネルがバッファリングしているサウンドデータの量 通常時： アプリケーションからのデータが十分 負荷時： アプリケーションの遅延によりデータが不足 閾値と比較して進捗状況を判断 閾値 = 過去の進捗値の平均値より計算 デバイス カーネル アプリケーション バッファ

Tanmaによるプロセス制御 進捗の悪化に伴い音楽再生処理を制御 音が途切れる前に音楽を一定時間停止 停止時間: 3秒 停止後に一時的に処理を再開し、再停止 or 続行 重要性の高い処理の終了後、遅くとも3秒後に再開 → ユーザが許容できる待ち時間 一時的に再開 & 進捗チェック 進捗良好 進捗悪化 音楽再生 3秒停止 重要性の 高い処理 開始 終了

音量の自動調整 停止・再開時に音量変更 停止後の進捗状況チェックは音量ゼロ ユーザに不快感を与えないよう停止・再開 一時的な音楽再生をユーザに聞こえさせない 進捗悪化 音量 進捗良好 フェードアウト フェードイン 音楽再生 重要性の 高い処理

タイムマシン再生 フェードアウト前の部分から再生を再開 フェードアウト中の音楽を録音し、再開時に再生 カーネル内の専用バッファにデータを保持 ユーザが音楽の一部を聴けないという事態を防ぐ 一時的な再開時に再生したデータも改めて再生 音量 フェードアウト フェードイン 音楽再生 音楽ストリーム 1 2 3 4 5 6 7 3 4 5 6 7 8 9…

動作検証 既存の音楽プレイヤーに対し動作を確認 デモ realplayer, xmms, mpg123など TanmaによるBGMの制御とQoS処理を示す

実験１： Tanmaによる資源競合回避 資源競合による重要な処理の遅延を検証 BGM起動上で重要な処理（π計算）の処理時間を測定 Tanma未使用（3通り）とTanma使用で比較 実験環境 音楽プレイヤー：realplayer 重要な処理:pi_fftc (π計算アプリケーション) CPU: Pentium Ⅲ 733MHz, メモリ: 512MBの計算機

実験１の結果・考察 考察 Tanmaが音楽プロセスを制御することで、π計算を遅らすことなく処理できる 処理時間 音楽のQoS pi_fftc のみ 711秒 ー pi_fftc + realplayer 821秒(+15%) ○ pi_fftc の CPU優先度↑ 777秒(+9%) × Tanma使用 731秒(+2.8%) △

実験２: Tanmaのオーバーヘッド Tanmaの処理により遅延が生じているかを検証 π計算実行中の音楽プレイヤーの進捗値を測定 進捗値 = カーネルがバッファリングしているデータ量 = データ送信を行うアプリケーションの速度 バッファサイズ: 131,072 byte 通常のシステム、Tanma、Tanma(音量調整を実行中)で比較 実験１と実験環境は同じ

実験２の結果・考察 考察 Tanmaの処理による負荷はほとんどない バッファリング しているデータ量 （=進捗の速度） (byte) 130,000 120,000 110,000 100,000 90,000 80,000 通常システム Tanma Tanma(音量変更中)

進捗情報を用いる別の手法 MS Manners [J.R.Doucer 99] デフラグなどのユーザに見えない処理を制御 重要性の低い処理のQoSは無視 QoS adaptation & real-rate scheduling [A.Goel 01] マルチメディア処理 = 重要性の高い処理 Tanma マルチメディア処理 = 重要性の低い処理 重要性の低い処理のためのQoS処理をプラス ユーザの感性を考慮

まとめ 重要性の低いマルチメディア処理のためのQoSの提案 Tanmaを開発 ユーザに与える不快感を抑制する Tanmaを開発 ユーザの感性を考えて音楽を停止・再開 Progress-based regulationをマルチメディア処理に適用

今後の課題 動画再生処理に対するQoS処理 ネットワーク上の音楽の再生処理 より汎用的な機能が必要 フェードアウトなどの処理はカーネルレベルでは困難 動画中の音楽には可能 ネットワーク上の音楽の再生処理 サウンドバッファの監視では進捗状況把握は困難 アプリケーションによるバッファリングで遅延 ネットワーク流量を監視する方法が考えられる より汎用的な機能が必要