TCP BBRについて
TCP BBRは、2016年のACM Queue(*1)で発表された輻輳（ふくそう）制御アルゴリズムです。輻輳(congestion)とは、物が1か所に集中し混雑する様態のことです。
今日のTCPのロスベース(loss-based)の輻輳制御は、デフォルトのCUBICでも問題があると考えられてきました。例えば、ボトルネックのバッファが大きい場合、パケットロスに基づく輻輳制御によってそれらがいっぱいになり、バッファが膨らむ原因となります。ボトルネックのバッファが小さい場合、パケットロスに基づく輻輳制御はパケットロスを輻輳の信号として誤って解釈し、低いスループットにつながります。これらの問題を解決するには、ロスベースの輻輳制御に代わるものが必要でした。この代替手段が、BBRです。
BBR(*2)とは、Bottleneck Bandwidth and Round-trip propagation timeの略です。
BBRは、パケットの時間の情報を利用して、リンクが混雑しているかどうかを判断します。
このアルゴリズムは、YouTubeのトラフィックの高速化に既に利用され、今後もより多くの人が使うかもしれません。
難しいことはさておき、先ずは実際に使ってみましょう。それで、本当に高速化しているか検証してみましょう。
はじめに、kernelのバージョンが4.9以降であることを確認し、利用可能な輻輳制御を表示します。
$ uname -r 4.18.16-300.fc29.x86_64 $ sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = reno cubic
次に、BBRを有効にする前に、デフォルトのcubicでスピードを確認します。より正確なデータを取るには、何回か確認したほうがいいです。
$ cat /proc/sys/net/ipv4/tcp_congestion_control cubic $ speedtest-cli Retrieving speedtest.net configuration... Testing from So-net Entertainment Corporation (xx.xx.xx.xx)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by OPEN Project (via 20G SINET) (Tokyo) [20.01 km]: 17.529 ms Testing download speed................................................................................ Download: 81.79 Mbit/s Testing upload speed.................................................................................................... Upload: 66.81 Mbit/s
cubicでのスピードを確認したら、BBRを有効にします。/etc/sysctl.confに次の2行を追加し、sysctlでロードします。
# cat /etc/sysctl.conf ... net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr # sysctl -p net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr
tcp_congestion_controlがbbrに変更されていることを確認し、再度スピードを確認してみます。
# cat /proc/sys/net/ipv4/tcp_congestion_control bbr $ speedtest-cli Retrieving speedtest.net configuration... Testing from So-net Entertainment Corporation (xx.xx.xx.xx)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by OPEN Project (via 20G SINET) (Tokyo) [20.01 km]: 16.996 ms Testing download speed................................................................................ Download: 81.17 Mbit/s Testing upload speed.................................................................................................... Upload: 66.39 Mbit/s
残念ながらWi-Fiを使っている環境でかつ東京のサーバに対してテストした結果では、パフォーマンスの向上は見られませんでした。
では、もっと遠いルイジアナ州(LA)Hammondのサーバに対してテストしてみます。今回も何度かテストしてみました。その結果がこちらです。
// cubic $ speedtest-cli --server 16352 Retrieving speedtest.net configuration... Testing from So-net Entertainment Corporation (xx.xx.xx.xx)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Southern Light, LLC (Hammond, LA) [10996.59 km]: 214.103 ms Testing download speed................................................................................ Download: 20.68 Mbit/s Testing upload speed.................................................................................................... Upload: 19.44 Mbit/s //bbr $ speedtest-cli --server 16352 Retrieving speedtest.net configuration... Testing from So-net Entertainment Corporation (xx.xx.xx.xx)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Southern Light, LLC (Hammond, LA) [10996.59 km]: 196.179 ms Testing download speed................................................................................ Download: 21.25 Mbit/s Testing upload speed.................................................................................................... Upload: 35.02 Mbit/s
アップロードのスピードが大幅に向上しています。よって、何か不都合が生じるまでbbrで使い続けてみようと思います。
参照:
1: https://queue.acm.org/detail.cfm?id=3022184
2: https://github.com/google/bbr/blob/master/Presentations/bbr-2017-02-08-google-net-research-summit.pdf
1%のボランティア
当たり前ですが、時間はすべての人に平等です。
一日8時間働く人が、1ヵ月の労働の1％を好きに使っていいとします。
すると、月に96分誰かの為に使うことができます。
1時間30分もあれば、困った人の相談やアドバイスなど充分可能かと思います。
本業のスキルをちょっとだけ貸して欲しいというニーズは、どこにでもあります。
例えば、僕がアメリカで学生していたときから、さまざまなヘルプをしてきました。PCの修理、データの復旧、ソフトウェアの作成、サーバの各種設定などなど。
ある人にとっては、どうしたらいいか分からないことも、他の人にとったら、朝飯前ということはよくあります。
みんなが専門家になる必要など全くなく、必要なときに必要なスキルを拝借できたら、社会はもっとよくなる気がします。
プロボノとはラテン語で「公共善のために」を意味する pro bono publico の略で、
各分野の専門家が、職業上持っている知識・スキルや経験を活かして社会貢献するボランティア活動全般を指します。
今年は、このような社会貢献するボランティアにも参加してみたいです。
寒いとiPadが充電されにくい理由
スマートフォンやタブレットをはじめ、あらゆるモバイル機器に搭載されているリチウムイオン電池は、外部温度と密接な関係があります。
一般的に約5℃ ～ 35℃の環境では問題なく充電ができますが、約5℃を下回る寒い環境下は電池に好ましくない影響を及ぼします。
理由 その1：電池容量の減少
電池容量が減少すると、電池の連続使用可能時間が短くなります。
電池は、その使い始めには起電力としてやや高めの電圧を出力し、放電を行うにつれて電圧は徐々に降下します。やがてある電圧を境にその低下の度合いが急激なものとなり、電池を電源として動作していた機器は停止に至ります。リチウムイオン電池は、放電終止電圧を2.5Vとすることが多いです。また、外部温度によって次のような放電曲線に差が生じます。
理由 その2：内部抵抗の上昇
内部抵抗が上昇すると、取り出し可能な電池電圧が低下します。抵抗とは、内部で化学反応が起こる際、その反応が遅いことを意味します。人間に例えると、寒い環境では、寝起きの際、抵抗してベットから出たくない状況と似ています。
科学的には、アレニウスの式で表現されます。
反応の速度定数 k は、次の値によって変化します。
A ：温度に無関係な定数（頻度因子）
Ea ：活性化エネルギー（1molあたり）
R ：気体定数
T：絶対温度
T（絶対温度）に着目すると、この値が小さくなるとexp内の負の絶対値が大きくなるため、反応速度定数kも小さくなります。
よって、反応が遅くなります。つまり、抵抗が上昇します。
その他の理由として、粘度なども関係すると言われています。温度が高いと粘度が低く、温度が低いと粘度が高い性質があります。
よって、温度が低いほど粘度が上がります。つまり、移動度が下がり、抵抗上昇につながります。
結論として、寒冷地でiPadを使う際には、なるべく部屋をカリフォルニアのようにあったかくして、充電／使用したほうが良さそうです。
きっとAppleの本社が、ロシアやアラスカだったら、-30℃ぐらいでも使用可能なリチウムイオン電池を搭載してくれたかもしれません。
dockerをモニタリングする
ここでは、いくつかの無料のツールを使用して、簡単にモニタリングする方法を紹介していきます。
docker stats
docker statsは、dockerに付属するツールでデフォルトでインストールされています。コンテナリソースをLinuxのtopコマンドのようにライブストリームで表示します。使用方法は、 コンテナIDをdocker statsの後に指定するだけです。
$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a5b713b0be52 ubuntu:latest "bash" 3 minutes ago Up 3 minutes keen_nash $ sudo docker stats a5b713b0be52 CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS a5b713b0be52 keen_nash 4.35% 7.172MiB / 7.48GiB 0.09% 9.49kB / 0B 17.4MB / 0B 1
docker events
docker eventsは、コンテナライフサイクルのイベントをモニタリングします。
例えば、コンテナの起動や終了イベントをモニタリングできます。
$ sudo docker events 2019-01-06T16:28:04.617197272+09:00 container create 267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca (image=ubuntu:latest, name=naughty_lehmann) 2019-01-06T16:28:04.618719113+09:00 container attach 267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca (image=ubuntu:latest, name=naughty_lehmann) 2019-01-06T16:28:04.691576928+09:00 network connect 2c53c1158426b7c0e6dd980104832d0e9f60a14f8291a37e180e68fef4b0ba8c (container=267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca, name=bridge, type=bridge) 2019-01-06T16:28:04.988327654+09:00 container start 267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca (image=ubuntu:latest, name=naughty_lehmann) 2019-01-06T16:28:04.989355465+09:00 container resize 267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca (height=42, image=ubuntu:latest, name=naughty_lehmann, width=169) 2019-01-06T16:28:12.738333362+09:00 container die 267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca (exitCode=0, image=ubuntu:latest, name=naughty_lehmann) 2019-01-06T16:28:12.831735032+09:00 network disconnect 2c53c1158426b7c0e6dd980104832d0e9f60a14f8291a37e180e68fef4b0ba8c (container=267d241fc270daadea8c2a7dc6c02a2a036652ded242cae0b35dc00388f5fcca, name=bridge, type=bridge)
dieメッセージは、コンテナが実行をストップしたときに表示します。
また、--sinceで時間軸を区切ったりすることも可能です。
$ sudo docker events --since 2019-01-06T16:20:00+09:00
cAdvisor
コマンドラインでも充分モニタリング可能ですが、トレンドなど視覚的に把握したい場合、グラフで表示させるとわかりやすいです。
cAdvisorのDockerイメージをインストール／実行するには、次のコマンドを実行します。
github.com
$ sudo docker run \ > --volume=/:/rootfs:ro \ > --volume=/var/run:/var/run:rw \ > --volume=/sys:/sys:ro \ > --volume=/var/lib/docker/:/var/lib/docker:ro \ > --volume=/cgroup:/cgroup:ro \ > --publish=8080:8080 \ > --detach=true \ > --name=cadvisor \ > --privileged=true \ > google/cadvisor:latest Unable to find image 'google/cadvisor:latest' locally latest: Pulling from google/cadvisor ab7e51e37a18: Pull complete [f:id:shinji629:20190107181924p:plain] a2dc2f1bce51: Pull complete 3b017de60d4f: Pull complete Digest: sha256:9e347affc725efd3bfe95aa69362cf833aa810f84e6cb9eed1cb65c35216632a Status: Downloaded newer image for google/cadvisor:latest bcbd00167aa44dd75dfd948e6dac24907baae81398917e0bf3e38988663c9ad2
http://localhost:8080にアクセスするとこのようなグラフが表示されます。
