remote screenのlampが、青く点いた。
第29話でイトは、video chunksの間を空けた。
その隙間をcontrol probeが抜け、cueのreplyはamberの締切線より先に戻った。
ただし、映像の進捗slotにはまだ四つしかcutがない。
最後の一つは、色を調整した25 MBのfinal cut。
次のcueまでにremote screenへ届かなければ、青いlampだけが点き、登場人物は途中の表情で止まる。
wall clockの輪が、残り三つになった。
linkの入口には、銀色のplateがある。
100 Mbps。
benchの計算cardには、今回のラボで使う単位が書かれていた。
25 MB = 200 Mbit。
イトは200を100で割った。
「二秒」
そして、final cutを送信queueへ置かずに待った。
ユイ
もう送らないの？
イト
100 Mbpsなら二秒で終わる。早く入れたら、またcueの道をふさぐかもしれない
マコト
その100は、何を数えた100だろう
イト
25 MBを送る速さだよ。plateに書いてある
clockの輪が二つになった。
イトはsend leverを倒した。
青いchunksが、前回と同じ間隔でlinkへ入る。
一秒。
二秒。
amber shutterが閉じた。
remote screenの進捗は、まだ四つ。
最後のslotは、半分だけ青い。
その横でcueのreplyだけが間に合い、lampが点いた。
登場人物は、古い表情のままこちらを見ていた。
換算は合っていた。それでも、締切にはならなかった
イトは計算cardを裏返した。
「200 ÷ 100は2。どこが間違ってるの？」
計算そのものは間違っていない。
小文字のbはbit。
大文字のBはbyte。
NISTの単位解説にあるとおり、1 byteは8 bitsとして扱う。
だから100 megabits per secondを8で割ると、12.5 megabytes per secondになる。
25 MBを12.5 MB/sで割れば、2秒。
ただし、それは同じ量をbitとbyteで言い換えた計算だ。
100 Mbpsというrateが、final cutの新しいdataだけに二秒間ずっと使えるとは証明していない。
イト
式は正しい。でも、式へ入れた100の意味が違った？
ピコ
plateの100と、remote screenが受け取るfinal cutのrateは、同じ場所を測っていないよ
ユイ
数字の大きさではなく、meterの両端を見るんですね
100 MbpsのMは、million、つまり10の6乗を表す。
1 GbpsのGは、10の9乗だ。
BIPMのSI Brochureが定めるSI prefixでは、megaとgigaは10進の倍率である。
一方、端末の容量表示では2の累乗を基準にした値が現れることもある。
その違いは大切だが、今回の失敗を生んだ中心ではない。
イトはラボのcardに明記された10進の25 MBと100 Mbpsを使っていた。
問題は、単位換算の先にある。
何のbitsを、どこからどこまで、何秒間数えたrateなのか。
そこが空白だった。
Mbpsは「ものが動く速さ」ではない
ピコがplateの100 Mbpsを指でなぞると、数字が一秒ごとの透明な箱へほどけた。
Mbpsは、megabits per second。
ある境界を一秒間に通るbitsの量を表すrateだ。
車が一台だけ何km/hで走るかのような「移動の速さ」ではない。
一秒に何本のbitsを数えたか、あるいは数えられるとしたかを見る。
だから、同じMbpsという単位でも、測る境界が違えば別の量になる。
download方向とupload方向でも違う。
sourceからlinkへ出た量と、destinationへ届いた量でも違う。
一瞬の最大値と、十秒の平均でも違う。
protocol headerを含む量と、applicationが新しく使えた中身だけの量でも違う。
「何Mbps？」と数字だけを尋ねると、これらが一列に混ざる。
三つのmeterは、同じ100を示さない
ピコは一本のrouteに、三つのmeterを置いた。
1. linkのcapacity plate
最初は、入口に固定された100 Mbpsのplate。
これは、そのlinkについて定義されたnominal capacityを示す。
道幅に近い上限の情報であって、いまfinal cutだけが使える量ではない。
IP performance metricを整理したRFC 5136は、linkのcapacity、実際のusage、available capacityを分けている。
end-to-endのpathでは、途中にある最も狭い部分が上限を作る。
入口のplateが100でも、相手までのすべての区間や端末が100で働くとは限らない。
2. destinationへ届いたIP-layerのflow
二つ目は、remote側のnetwork meter。
ここでは、決めた時間窓に到着したIP-layerのbitsを数える。
final cutの中身だけではない。
packetを届けるためのheaderも流れる。
同時にvoiceとcueのpacketも通る。
失われたpacketを送り直せば、再送されたbitsもlinkを使う。
meterがよく回っていても、そのすべてがfinal cutの完成を進めるわけではない。
3. applicationが新しく受理したpayload
三つ目は、remote screenの進捗slotにつながっていた。
applicationが重複なく、新しいdataとして受理できたpayloadだけを数える。
同じchunkが二回来ても、進捗は二倍にならない。
headerが届いても、映像のpixelは増えない。
voiceが通ればrehearsalは守られるが、final cutのslotは埋まらない。
イトが締切を決めるために欲しかったのは、この三つ目のrateだった。
マコト
capacityは上限の性質。二つ目は実際のnetwork flow。三つ目は目的に使えた新しい中身だね
ユイ
大きな数字を選べば、完成へ近づくとは限らない
イト
僕は一番上のplateを、三番目の進捗meterとして使ってた
「実効速度」も、測り方を省略できない
benchに、別のspeed testの結果が浮かんだ。
82 Mbps。
次は74 Mbps。
その次は88 Mbps。
100より小さい。
だが、この数字だけでもfinal cutの締切は決められない。
相手はどのserverか。
downloadかuploadか。
何秒測った平均か。
何本のconnectionを使ったか。
network-layerの全bitsか、重複を除いたapplication dataか。
測定中にvoiceとcueは流れていたか。
条件が違えば、同じ「実効速度」という言葉でも答えが変わる。
TCP throughputの測定を扱うRFC 6349は、achievable throughputがbottleneck bandwidthだけで決まらず、round-trip time、buffer、MTU、lossなどにも左右されることを説明している。
access linkの契約上の数字だけで、applicationのend-to-end性能は保証できない。
measurementは未来の約束ではない。
同じ条件を再現したときの、現在の観測だ。
それでも、守りたい仕事と条件をそろえれば、plateだけを見るより締切の判断に近づける。
一番大きな数字を採るか、完成を数えるか
rehearsalをやり直せるのは、あと一回だった。
三つの計画cardが立ち上がる。
- 100 Mbpsを信じ、もう一度二秒前に送る
- plateの数字は変わらない。ただし、同じ条件なら同じ未完了を繰り返す。
- 届いたIP-layerのbitsを全部足し、「高いrateが出た」と報告する
- 大きな数字は作れる。headerやduplicateまで成功へ数えるため、remote screenの完成とはずれる。
- remote applicationが新しく受理したpayloadを、本番と同じ負荷で繰り返し測る
- 数字は小さくなる。開始を早め、voiceとcueの余白を残した締切を作れる。
ユイは一枚目と二枚目の間で指を止めた。
「同じ発表なら、大きい数字のほうが安心してもらえそう」
マコトは、remote screenの空白を指した。
「僕たちの成功は、meterを大きく見せることじゃない。あの五つ目を締切前に埋めることだ」
ピコは、どのcardにも触れなかった。
clockの輪が一つ減る。
イトは二枚目を持ち上げた。
届いたbitsを全部数えれば、100に近い数字が見えるかもしれない。
さっきの失敗を「networkは速かった」と言い換えることもできる。
だが、remote screenは未完成のままだ。
イトは二枚目を戻し、三枚目を選んだ。
「完成したdataを数える。小さい数字でも、次に間に合うほうを使う」
四つの欄を埋め、同じ一秒を比べる
イトは新しいmeterの横に、四つの欄を書いた。
- direction: labからremoteへのupload
- endpoint: remote screen application
- layer: applicationが新しく受理したpayload
- interval: 連続する一秒ごとの窓
そして、本番と同じvoiceを流した。
cue probeも、前回決めた間隔で差し込む。
final cutと同じdataをtest bufferへ送り、remote側で初めて受理されたpayloadだけを数えた。
一秒目。
meterは100より低い場所で止まった。
二秒目。
voice packetが増え、さらに少し下がる。
三秒目。
一つのchunkをretryした。
network meterは再送分も数えたが、application meterは同じdataを二度進捗へ足さなかった。
四秒目。
高い値が出た。
イトは、それ一個を答えにしなかった。
複数の一秒窓を並べ、低い窓が続いても25 MBを受け取り終えられる開始時刻を選ぶ。
最後に、cueが通る余白を一つ残した。
ユイ
100よりずいぶん低い。発表するなら見栄えは悪いですね
イト
うん。でも、この数字なら『二秒前で大丈夫』とは言わない
マコト
capacityを下げたわけじゃない。目的に使えたrateを別に測ったんだ
ピコ
meterの名前より、境界と時間窓が結果を説明してくれるね
速くしたのではなく、早く始めた
最後のrehearsalが始まった。
100 Mbpsのplateは、入口に残っている。
イトはそれを隠さなかった。
ただ、二秒前まで待つのをやめた。
application meterの低い窓から決めた時刻で、final cutをqueueへ置く。
青いchunksの間隔は、第29話で選んだまま。
voiceが隙間を通る。
cue probeも、長いvideo chunkの列に閉じ込められない。
一つのchunkが失われ、retryの印が点いた。
network meterは、同じbitsがもう一度流れたことを数えた。
application meterは、そのduplicateを進捗へ加えなかった。
それでも、早く始めたぶんの余白が残っている。
remote screenの五つ目のslotが、青く満ちた。
amber shutterは、まだ開いていた。
直後にcueのreplyが戻り、lampも締切線の手前で点く。
新しい表情の登場人物が、青いlampに合わせて振り向いた。
イトは100 Mbpsのplateと、低いapplication meterを並べた。
どちらかが嘘なのではない。
違う境界を数えている。
「数字を上げなくても、間に合わせられた」
イトは、最初の計算cardから2秒の締切だけを外した。
100 Mbps ÷ 8 = 12.5 MB/sという換算は残す。
その横に、こう書き足した。
capacityをapplication payloadのrateと決めつけない。
読者が次にできる一手
最初の一手は、Mbpsの横へdirection、endpoint、layer、intervalを書くことだ。100 Mbpsを8で割れば12.5 MB/sになるが、それはbitとbyteの単位換算であって、25 MBのfileが必ず2秒で完成する保証ではない。nominal capacity、実際に流れたIP-layerのbits、applicationが新しく使えたpayloadを分け、守りたい仕事と同じ条件で繰り返し測る。値が低ければ、数字を飾るのではなく、開始を早めるか、同時trafficを減らすか、締切へ余白を足す。
今回の測定で間に合ったからといって、次回も同じとは限らない。
相手、経路、loss、混雑、端末の処理が変われば、使えるrateも変わる。
だから、条件が変わったら同じ境界で測り直す。
次の扉
final cutの送信が終わった。
三つのmeterは、そろって0へ戻った。
100 Mbpsのplateだけが、変わらず光っている。
ユイがremote screenへ、小さな呼び鈴packetを送った。
返事がない。
「0 Mbpsだから、道が消えた？」
イトは首を振った。
いま流れている量が0でも、capacityまで0とは限らない。
だが、呼び鈴へ返事がない理由も、0というmeterだけでは分からない。
ピコが、往復clockの隣に新しいbuttonを置いた。
ping。
次は、このbuttonが何を確かめ、何を確かめないのかを見る。