cpuinfo に含まれる Revision を見る。

$ cat /proc/cpuinfo  | grep Revision
Revision        : a01041

RPi HardwareHistory - eLinux.org に書いてある通りに表を参照する。

上記の例では

a01041	Q1 2015	2 Model B	1.1	1 GB	(Mfg by Sony)

(写真は練習の別の候補問題のもの)

日曜日が試験日だった。どうやら筆記試験と違って、試験会場が県あたり1つしかないようで、試験会場の最寄りのマイナー駅がものすごい混雑だった。こんなに受験者がいるのかーとびっくり。

候補問題が13問なので2週間ぐらい前から1日1問ずつ消化していった。練習してみると結構欠陥 (不合格) を出してしまう。特に電線の種類・長さを間違えると、他の欠陥に比べて取り返しがつかないことになる。ということで当日は特にこのへんを気をつけようという心掛けをした。

出題問題は候補問題7の4路スイッチを含む回路だった。

あんまり好みの問題ではなかったけど一通りやるだけやったという感じ。電線色が任意の箇所が多いので逆に不安になる。約15分ほど残して終わり。見た目的には教科書通りという感じだけど、一通りチェックはしても細かい欠陥があるかどうかは、勘違いとかもあるのでよくわからない。合格発表は8月20日。合格していなかったら下期に再受験。

今更ながらいまいち理解できてないポイントがあったので、いっかい自分でまとめてみることにする。当たり前のことではあるが……

• これまで採用されていた輻輳制御アルゴリズムの多くはパケットロスベースであった
  • CUBIC / (New) Reno など
• しかし実際はパケットロスと輻輳は厳密に対応しない
• 輻輳はネットワークの処理能力の限界を超えたときに発生する
  • 処理すべきデータ容量が処理可能なデータ容量を超えると発生する
• パケットロスは瞬間的なトラフィック増加や、電気的ノイズなどネットワーク処理能力以外の要素でも発生する現象
  • 無線ネットワークのように原理的にパケットロス率が高いことも多い

BBR では通信先との間の実際に使える帯域を推定し、パケットロスが起こっていても、あるいはパケットロスが起こらなくても、輻輳しない程度に最大のスループットを出す。

実際のアルゴリズムは解説してるサイトを見るほうが早い。

curl は POST や PUT でリクエストボディの長さが長いなどの特定条件になると、まず Expect: 100-continue をつけてリクエストを送り、サーバ側の対応を待ってからリクエストボディを改めて送るという行儀が良い実装になっている。

しかし、特に IoT っぽい機器では Expect: 100-continue に対応していないものもあるので、抑制したい場合がでてくる。そういうときは以下のようにする。

curl -H "Expect:" -d ... url

空の Expect ヘッダを指定することで上記のような挙動をしなくなり、最初からリクエストをフルで送りつけるようになる。