remote screenのlampが、青く点いた。
第31話でイトは、pingのreplyとapplicationのreplyを同じ答えにしなかった。
本番用screenは、Echoへ返事をしないときもあった。
それでもapplication preflightはfinal cutを5 / 5受理し、正しいcue sequenceを返した。
いまはEcho Replyも戻っている。
application receiptも戻る。
ところが、イトの手元にあるpreviewだけが、二秒おきに止まった。
登場人物が振り向く。
固まる。
二秒後に、まとめて動く。
イトはremote quality leverを一段下げた。
「serverが重いんだ。送る映像を軽くすれば直る」
remote screenの新しい表情が、粗いblockへ変わる。
ユイのwired monitorにも、粗くなった映像が出た。
それでもイトのpreviewは、また止まった。
遠くの映像を軽くしたのに、手元の停止は残った。
ユイ
私のmonitorは止まっていません。でも、画質だけ一緒に下がりました
イト
同じserverなら、どうして僕だけ止まるの？
マコト
同じなのはserverだけかな。deviceと、そこへ出る道は違うね
イト
それなら、network settingsを全部初期化してやり直す
イトは、laptopの赤いreset leverへ手をかけた。
本番まで、あと九分。
初期化を始めれば、再起動と再接続が必要になる。
保存してあるnetwork条件も変わる。
直るかもしれない。
だが、直らなかったときには、どの条件で止まっていたのかまで失う。
ピコが点検boardを開いた。
device。
application。
Wi-Fi / LAN。
routerから外のpath。
remote service。
札は並んだが、正解の札だけは光らない。
「九分で、どれを選べばいいんだ」
「ネットが遅い」は、まだ原因名ではない
イトのpreviewは止まる。
この症状だけからは、複数の範囲が残る。
- laptopのCPU、memory、background task、adapter、OS
- preview applicationのdecode、cache、session
- laptopからrouterまでのWi-Fi
- 家のLAN、router、access line、ISP側path
- remote service、配信拠点、その手前のroute
一つのpacketも、これらの境界を順に通る。
だから「ネットが遅い」を一つの部品名へ置き換えることはできない。
必要なのは、最初から犯人を当てることではない。
次に見る範囲を狭める比較だ。
点検boardは、近い順にすべて再起動する手順書ではない。
同じ仕事を、条件の違う二本の道へ通し、結果がどこで分かれるかを見る。
最初に、遅かった一回を固定する
ユイは白い観測cardを置いた。
イトはreset leverから手を離し、いまの症状を書く。
- device: イトのlaptop
- app: remote preview application
- target: 本番用remote screen
- task: current final cutを再生し、次のcueへ追従する
- connection: ラボ奥のbenchからWi-Fi
- time: 本番九分前
- symptom: 約二秒おきに映像が止まり、その後まとめて動く
このcardは、原因を説明していない。
だが、次の結果と比べられるbaselineになる。
IP performance measurementの枠組みを拡張したRFC 7312は、測定のrepeatabilityが、どのparameterを固定できたかに左右されることを説明している。
wirelessのように状態が変わるpathでは、完全に同じ条件を作ること自体が難しい。
だからこそ、変えた条件と変えていない条件を記録する。
守りたいapplicationと違うtrafficだけを測り、その結果を本番へそのまま広げるのも避ける。
今回は、speed testだけではなく、実際に守りたいpreview taskを比較へ使う。
別deviceの成功は、答えではなく分岐になる
同じ時刻、ユイのwired monitorは滑らかに動いている。
マコトのtabletも、routerの近くでは同じremote previewを再生できた。
この二つから、remote service全体がすべての利用者へ停止している、とは考えにくくなる。
しかし、serverが完全に正常だと証明したわけでもない。
device、OS、application instance、connectionが違うからだ。
別device comparisonは、範囲を狭める入口になる。
最終回答にはならない。
イト
ユイはwired。マコトはrouterの近く。僕と違う条件が二つ以上ある
マコト
だから次は、違いを一つに減らす
ユイ
同じlaptop、同じapp、同じtargetを残して、道だけを変えられます
ピコ
比較で答えるのは『原因の名前』ではなく、『次に残す範囲』だよ
pingとMbpsも、札ではなく条件つきの観測
イトは、点検boardへ前二話のmeterを戻した。
ping。
Mbps。
どちらにも正常という緑札を貼らない。
pingのRTTは、決めたtargetとpacket type、timeoutで観測した往復sampleだ。
speed testのMbpsも、決めたserver、direction、protocol、時間窓、端末、connectionで得たrateである。
round-trip delayを定義するRFC 2681は、target、packet type、path、timeoutなどのcontextが測定の意味へ関わることを示している。
TCP throughput testingのRFC 6349も、throughputをbottleneck bandwidthだけで読まず、RTT、buffer、MTU、lossなどと合わせる枠組みを取る。
一回の高いMbpsと短いpingがあっても、preview applicationの連続再生を自動では保証しない。
逆に、一回の低い数字だけでISPやserverを犯人にもしない。
meterは、条件をそろえて前後を比べるために使う。
九分をresetへ使うか、比較へ使うか
本番まで、あと七分。
三枚の計画cardが立ち上がる。
- laptopのnetwork settingsを全初期化する
- 広い範囲が一度に変わる。再接続に間に合わず、何が効いたかも分からない可能性がある。
- remote qualityをさらに下げ、serverの負荷として扱う
- イトのpreview停止は一段下げても残った。remoteの映像品質だけをもう一度失う。
- 同じlaptop / app / target / taskを保ち、connectionだけを変える
- 比較に数分使う。結果が分かれれば、live takeの迂回と次の点検範囲を同時に選べる。
MicrosoftのWindows Wi-Fi troubleshootingは、別device、default gatewayへのping、可能ならEthernetとの比較で範囲を狭める手順を示している。
同じ公式手順でnetwork resetは最後のstepとされ、adapterとsettingsを削除・再設定する操作だと説明されている。
操作や影響はOSによって異なる。
しかし、広いresetの前に低コストの観測を残すという順序は、今回の選択にも使える。
clockの輪が一つ減った。
イトは一枚目を持ち上げる。
全部を戻せば、考えなくて済む。
だが、再接続が終わらなければ本番へ出られない。
二枚目なら、remote側へもう一度損失を押しつける。
さっき画質を落としても、自分の停止は直らなかった。
イトは二枚を戻し、三枚目を選んだ。
「同じ一台で、道だけを変える。直すのは、結果を見てからだ」
A、B、A、Cで、戻ることも確かめる
イトは、remote qualityを元へ戻した。
比較中にsource条件まで変えないためだ。
最初はA。
ラボ奥のbench、Wi-Fi、同じlaptop、同じpreview。
一分のfixture windowで、停止が二回出た。
次はB。
laptopを持ち、routerの近くへ移動する。
device、application、target、映像、時刻帯は変えない。
変えた中心は、Wi-Fiを使う場所だ。
同じ一分で、停止は出なかった。
ただし、時間も少し進んだ。
偶然かもしれない。
イトは奥のbenchへ戻る。
もう一度A。
同じ停止が現れた。
最後はC。
奥のbenchのまま、床の端へ固定したlong Ethernet cableでrouterへつなぐ。
同じlaptop、同じapp、同じtarget、同じcut。
Wi-Fiの区間だけを外す。
previewは、一分を止まらずに走った。
このラボの一回では、Aで再現し、BとCで消えた。
だから、次に残す範囲はremote service全体より、奥のbenchで使うWi-Fi条件とwireless interface側へ寄る。
だが、原因名はまだ決まらない。
距離や壁。
周囲の電波。
bandやchannel。
同時利用。
adapterやdriver。
その時刻だけの揺れ。
候補は複数残っている。
原因を直す前に、live takeを守る
clockは、残り三分。
イトはCのwired connectionを残した。
cableを人が歩く中央へ通さず、壁際のcoverへ収める。
remote qualityは元のまま。
network settingsも初期化しない。
live takeが始まる。
previewの登場人物が振り向く。
今度は止まらない。
イトは動きに合わせ、次のcue leverを倒した。
application receiptが戻る。
remote screenの青いlampが、deadlineの手前で点いた。
ユイのwired monitorも、イトのpreviewも、同じ新しい表情を映している。
イトは、点検boardのserver札へ付けた赤い印を外した。
Wi-Fi札へ犯人とも書かない。
代わりに、観測cardを挟む。
far Wi-Fiで再現。near Wi-Fiとsame-position wiredでは、このfixture windowに再現なし。
この一行なら、次の人が同じ条件を作り直せる。
四つの比較で、次の範囲を選ぶ
今回と同じ装置がなくても、比較の形は使える。
| 比べるもの | そろえるもの | 結果が分かれたときに次へ残す範囲 |
|---|---|---|
| 同じappを別deviceで試す | target、task、time、connection | 一台だけならdevice / app側を優先して見る |
| 同じdeviceで別app / serviceを試す | device、connection、time | 一つだけならspecific app / service / routeを優先して見る |
| 同じdeviceをWi-Fi / wiredで試す | app、target、task、time | Wi-Fiだけならlocal wireless / adapter側を優先して見る |
| 複数device・複数serviceで試す | time、household connection | 両方で広く出るならrouter / access line / ISP側も残す |
これは、結果だけで原因を確定する表ではない。
一つの比較には、まだ隠れた違いがある。
別deviceならCPUやOSも違う。
別serviceなら配信拠点やprotocolも違う。
wiredならnetwork interfaceも変わる。
だから「次にどこを見るか」を選び、必要なら別の比較を重ねる。
FCCのBroadband Consumer Guideが説明するように、同じWi-Fi networkで複数のwireless deviceが同時に使われればperformanceやlagへ影響することもある。
測定するときは、background download、会議、game、backupなど、その時刻のshared useも一緒に残す。
壊す前に診断し、直せなくても記録を渡す
live takeの後、イトはwired cableをすぐ外さなかった。
まず、成功した条件を保存する。
そのうえで、Wi-Fiを止めずに観測できるdiagnosticを使う。
たとえばAppleのWireless Diagnosticsは、network settingsを変更せずにconnectionを分析し、検出事項とsupportへ渡せるdetailsを生成する。
使えるtoolと操作はOS、router、管理権限で異なる。
自分が管理していない学校、会社、宿泊先のnetworkなら、勝手に設定を変えず、管理者へ渡す。
渡すものは、長い感想より比較cardだ。
- 発生時刻と頻度
- device / OS / app
- targetと守りたいtask
- Wi-Fi / wired、場所、bandなど分かるconnection条件
- ping / loss / Mbpsを測ったなら、そのendpointと条件
- A / Bで変えた一項目と結果
- providerやserviceの公式障害情報を確認した時刻
複数device、Wi-Fiとwired、複数serviceで同じ症状が続くなら、家庭内の一設定を何度も初期化するより、router / access line / provider側を含む記録として相談する。
一台、一つのappだけなら、そのdevice / app側の記録を優先する。
緊急時は、今回のwiredのように、比較で効いた安全な迂回を残して仕事を守る。
根本原因の修理と、いまの目的を守る行動を分けてよい。
読者が次にできる一手
最初の一手は、遅かった瞬間のdevice、app、target、task、connection、timeを一行で残し、同じtaskのまま一条件だけ変えることだ。別device、別service、router近く、wired connectionなど、戻せて損失の小さい比較から選ぶ。結果が分かれても原因名を確定せず、次に残す範囲と、効いた一時迂回を記録する。複数device・Wi-Fi / wired・複数serviceで広く続く、または管理外networkであるなら、広いresetを重ねず、測定条件とA / B結果をproviderや管理者へ渡す。
次の扉
live takeは終わった。
奥のbenchではwiredなら止まらない。
localの比較は、一つの境界を狭めた。
だが、別のremote previewを開くと、wiredでもreplyが少し遅い。
画面の隅に、二つの配信拠点が現れた。
近くの青い棚。
海の向こうの琥珀の棚。
「同じserviceなのに、返事をする場所が違うの？」
ピコが、町、国内、海外、cloudの棚を載せた地図を開いた。
次は、serverがどこにあり、その場所をどう確かめるかを見る。