基本情報 平成29年度 秋期 問17：テクノロジ系に関する問題

答えは d です。

送信タスクが受信タスクより速いので、毎秒「送信量 − 受信量」だけバッファに溜まっていきます。

7秒間続けて送ると、バッファに溜まる最大量は (送信速度 − 受信速度) × 7秒 ぶん。

この量を入れられるサイズが必要、というのがバッファ設計の基本ルール！

👉 覚え方：差の速度 × 時間 ＝ 必要なバッファ容量。

ほかの選択肢は引き算の方向や時間の掛け方を間違えた誤式。「速い方 − 遅い方」がプラスになる方向で覚えよう。

なぜこれが正解か

正解は d。送信速度をS、受信速度をR（S>R）、転送時間を7秒とすると、毎秒の余剰量は (S−R)、これが7秒間蓄積されるのでバッファ必要サイズは (S−R) × 7。これを満たさないとオーバーフローが発生する。

計算の考え方

• 送信は7秒間に S×7 バイト送る
• 受信は同じ7秒間に R×7 バイト処理
• バッファに溜まる最大量＝送信総量 − 受信処理総量 = (S−R)×7
• よってバッファサイズは ≧ (S−R)×7

各選択肢の解説

• 差の方向（R−S）：負になるので不可能。
• 時間項の誤り：7秒間連続送信なら掛けるのは「7」または「次転送までの間隔」ではなく送信継続時間。
• d：(S−R)×7 = 正解。

覚え方・ひっかけ注意

バッファ最小容量 = (流入速度 − 流出速度) × 流入継続時間、ただし流入>流出のとき。逆ケース（受信が速い）はバッファ不要。生産者・消費者問題、ストリーミング、フロー制御で共通する基本式。

理論的背景

この問題は生産者・消費者モデル（Producer-Consumer pattern）の典型。生産速度 λ、消費速度 μ、観測期間 T のとき、必要バッファ最小サイズ B は

B ≥ (λ − μ)⁺ × T （ただし λ > μ のとき）

で与えられる。これはネットワーク輻輳制御、ジッタバッファ、IO スループット設計の共通基盤。

関連する設計問題

• リーキーバケット（leaky bucket）：トラフィックシェーピング。一定速度で流出、バーストはバケツで吸収。バケツサイズ＝最大許容バースト量。
• トークンバケット（token bucket）：トークン蓄積で平均レート＋バースト許容を制御。
• ジッタバッファ：VoIP/ストリーミングで到着間隔の揺らぎを吸収。サイズと遅延のトレードオフ。
• TCP受信ウィンドウ：受信側のバッファ余裕を送信側に通知し、流量を動的調整。

マルチタスク間通信の実装

• メッセージキュー（POSIX mq, RTOS API）：固定サイズバッファ、満杯時はブロック/非ブロック選択。
• リングバッファ（circular buffer）：lock-free実装で高性能。組込み・カーネルバッファで多用。
• ダブルバッファリング：送信用と受信用を切替、コピーレイテンシを隠蔽。

試験での位置づけ

FE「ハードウェア／組込み」分野で類題が多い。バッファ容量計算、レイテンシ vs スループット、リアルタイム性は組込みシステムスペシャリスト試験（ES）の中核。応用情報ではプロセス間同期（セマフォ、モニタ）まで踏み込む。

実装上の留意点

• オーバーフロー対策：上位レイヤへのフロー制御通知、バッファ拡張、データ廃棄方針（最古破棄 vs 最新破棄）。
• アンダーフロー対策：消費側の停滞時にフィラーデータ挿入、再送要求、ストリーミング中断通知。
• バッファ膨張（bufferbloat）：過大なバッファはレイテンシ悪化を招く現代的課題。CoDel等の AQM（Active Queue Management）が対策。

選択肢の発展補足

本問は静的な計算問題だが、実務では送信がバースト的（VBR）な場合が多く、最大バースト幅と平均レートの両方を考慮する。CBRストリーミングなら簡単、VBRなら統計的多重化（statistical multiplexing）で実効バッファを縮小可能。