既存のグループ内通信プロトコルでは、steady_clock をタイムスタンプとして使用し、個々のノードの処理時間（レイテンシー）を計算しています。特定の特殊な状況において、メッセージパケット自身のタイムスタンプを使用しましたが、その自身のもつタイムスタンプは他のマシンから取得されており、結果的に計算されたレイテンシーが異常に大きくなってしまいました。

要約：Gemini 2.5 Pro は GPT-4 を完全に凌駕する可能性を秘めている。

問題のトラブルシューティング

開始当初、出力層のタイムスタンプ計算の問題に注意していなかったので、すべてのサービスを停止して、ローカルアクセスし、ログを分析することにした。あるサービスがずっと停止しないことに気づき、継続的に業務データを送信しているため、手段がなく、通信ポートでパケットキャプチャをして機器の位置を特定した。

sudo tcpdump -nni any -B 4096 -s 0 -w tmp.pcap port 13100

内部ネットワークの状況は複雑で、メッセージがプロキシを経由して転送されていたため、まずローカルサービスでポート13100のパケットをtcpdumpでキャプチャした。次にプロキシサーバーに切り替えて、ポート13100のパケットをキャプチャした。

分析の結果、異常に時間がかかるリクエストはすべて深圳オフィスから来ていたため、問題のあるサービスを調査し、そのサービスは上海オフィスにデプロイされていたことがわかった。

steady_clock と system_clock の違い

std::steady_clock と std::system_clock は、C++ で時間を扱うための主なクロックです。主な違いは以下のとおりです。

std::system_clock

• 「壁時計時間」 (Wall Clock Time) を表す: これは、システム全体で現実世界の時間を指します。これはオペレーティングシステムがディスプレイしている時間と一致しています。
• 調整可能: このクロックの時間（時刻）は、ユーザーまたはシステムサービス（例：NTP ネットワークタイムプロトコル）によって前後に調整できます。たとえば、手動でシステム時刻を変更したり、システムをタイムサーバーに同期させたりすると、system_clock の値が跳ね返ります。
• 時間間隔の測定には不向き: 向こう見えになる可能性があるため、2つの時間点間の時間差を計算するには、負の値や不正確な結果が得られる可能性があります。
• 主な用途: 現在の日付と時刻を取得し、現実世界の時間に対応する必要があるシナリオ（例：ログ記録用のタイムスタンプ）で使用されます。

std::steady_clock

• 単調増加クロック (Monotonic Clock): このクロックは、ある開始点から常に安定して前進し、決して減少することはありません。そのレートは固定されている場合もあれば、そうでない場合もあります（ただし通常は固定されています）。
• 調整不可 (Unadjustable): steady_clock はシステム時間の変更の影響を受けません。つまり、ユーザーがシステム時間を変更しても、それは引き続き安定して前進し続けます。
• 時間間隔の測定に最適 (Best for Measuring Time Intervals): その単調性により、コードの実行時間やタイムアウト待ちなどのシナリオにおける最適な選択肢となり、正確性を保証できます。
• 開始点は不確実 (Uncertain Epoch): 周期（epoch）の開始時間は通常システム起動時ですが、これは標準によって保証されているわけではありません。

異なるマシンで steady_clock は同じですか？

違います。 steady_clock の値は、異なるマシン間では比較できません。さらに、同一マシンの異なる起動セッション間でも、その値は一貫しません。 なぜなら、それは単一のプログラム実行中に時間間隔を正確に測定することを目的としており、絶対的な時間点を表すためのものではないからです。その開始点（epoch）は未定義であり、異なるシステムや起動セッションではほぼ常に異なります。

まとめ

まとめ

まとめ

まとめ

まとめ

簡単に言うと：

• 「今、何時ですか？」を知りたい場合は、system_clock を使用します。
• 「このコードは実行されてどれくらい時間がかかりましたか？」を知りたい場合は、steady_clock を使用します。