期待のネット新技術

LAN内機器での時間同期の標準規格「PTPv1」こと「IEEE 1588-2002」

 今回からは「PTP(Precision Time Protocol)」を紹介していこう。

 LAN内のネットワークにつながった機器同士の時間の同期を取るのが目的なのだが、もっともPTPといえば、以下3つの「IEEE 1588」しかなく、基本的には相互の互換性はない。

標準化名名称
IEEE 1588-2002初代PTP。PTPv1などとも
IEEE 1588-20082代目PTP。PTPv2
IEEE 1588-20193代目PTP。PTPv3

 今回はまず、基本となるPTPv1というか「IEEE 1588-2002」について。3世代のPTPは相互に互換性がないと書いたが、LAN内の機器同士で時間同期を取るという大きな目的そのものは変わっていない。実際、IEEE 1588-2002冒頭のScopeやPurposeは以下のような具合だ。

IEEE 1588-2002」の冒頭より抜粋。何というか、分かりやすい

 あくまでも、LAN内の機器に対してSub msオーダーでの精度で同期を取るための仕組みである。

 ただし、この同期の精度、1.1のScopeでは"The protocol will support systemwide synchronization accuracy in the submicrosecond range with minimal network and local clock computing resources."とある。

 要するに、0.1μsオーダーでの精度同期が可能、と読めるようにしつつ、1.2のPurposeでは"For example, Network Time Protocol(NTP) targets large distributed computing systems with millisecond synchronization requirements."と書いてあって、精度の実装がmsオーダーなのかμsオーダーなのかは、よく分からない。後々出てくるが、最初のPTPだと思えば仕方のないところか。

 なお、Scopeにも"but not limited to, Ethernet."とあるように、LAN機器は必ずしもEthernet機器である必要はなく(Ethernet以外での実装を筆者は見たことがない)、逆に、LANを超える範疇での時間同期は対象外である。

 これに関しては既に「NTP(Network Time Protocol)」が存在しており、これを利用する格好だ。NTPは、以下がそれぞれ規定されているほか、まだ採択されていないが、NTPv4が2010年に「RFC5905」として、NTPv4の拡張案が2016年に「RFC7822」として提案されている。

名称標準化名
NTPv0 RFC958
NTPv1 RFC1059
NTPv2 RFC1119
NTPv3 RFC1305
NTPv4 RFC5905
NTPv4拡張案 RFC7822

 それぞれの詳細はともかく、WANを含んだ広範なネットワークにおける時間同期は、このNTPで取るかたちとなる。では、LAN内の同期もNTPでいいのでは? というと、これで足りる場合も存在するが、不足する場合もある。

 例えば、自宅にある複数台のPCやスマートフォンで、秒単位で同期を取りたいという程度のニーズならNTPでも十分だ。NTPの目的は、「UTC(Coordinated Universal Time:協定世界時)」に対して数ms以内の精度で機器内部の時刻を同期させることであり、複数台のPCやスマートフォンを、その時計を利用して何か同期させている、といった用途でない限り精度としてはこれで十分だろう。

 PTPは全く発想が異なる。PTPはそのネットワーク(というかLAN)内に所属する、PTPを利用可能な機器の時間を1msオーダーで同期させるのが目的であるが、その時刻がUTCと同期しているかどうかには関与しない(というか、PTPにはUTCと同期する仕組みは入っていない)。

 だから、PTPを利用した際のMaster Clock Device(PTPを利用する際の基準となるデバイスの内部の時刻)がUTCから5秒ずれていると、PTPを使って同期したデバイスも全て、UTCから5秒ずれることになる。

 ただ、これはPTPの利用においては問題はない。PTPが当初想定したターゲットは、FA(Factory Automation)やテスト/計測といった用途向けに、装置を同期させることだ。

 例えば、ある事象を複数の測定器を使って計測し、後で突き合わせるといった場合、それぞれの測定器に対して同時に測定の開始と終了を制御でき、また、測定の頻度も一定で突き合わせが容易ということなら、それほど問題はない。

 ところが、同時に開始と終了をさせられなかったり、測定器ごとにデータ取得頻度がまちまちだったりすれば、後で突き合わせる際に時刻を頼りにするしかない。例えば「13:05:00から測定開始し、10分後に終了」ということにして、その10分間のデータを突き合わせるといった具合だ。

 このとき、測定器ごとに時刻がバラバラだと、突き合わせができないこととなる。そこで測定直前に全ての時間を合わせてやる必要があるわけだ。

 戦争映画などで、部隊が出動する直前に隊長の時計に部隊員の時計を合わせる、なんてシーンがあるのを見たことがある方もいるだろうが、あれと同じだ。そうした際に問題となるのは、隊長の時計がどこまでUTCに一致しているかではなく、隊長と隊員の時計が一致しているかどうかだけだ。もちろん、絶対的な時刻が問題になることもある。その場合は、隊長に電波時計なり何なりを装着して頂くわけだ。

 そしてPTPで絶対的な時間が問題になる場合、Master Clock DeviceにNTPを使ったり、例えばMicrochipの「CSAC(Chip Scale Atomic Clock)」のように原子時計を搭載したりするなどの方法でMaster Clock Deviceの時計を正確に合わせておけば、これに同期するそのほかの機器の時計も、msオーダーの精度で正しく合わされることになる。

 話が横に逸れたが、そんなわけでPTPは、ネットワーク内の機器の時計をMaster Clock Deviceの時計に正確に合わせるためのプロトコルというわけだ。そして具体的な同期が以下の手順で行われる。

IEEE 1588-2002に収録されているものよりも図が分かりやすい"17.6.4. IEEE 1588-2002 Timestamps"(Intel Agilex Hard Processor System Technical Reference Manual)より
  1. PTP Master(つまりPTPのMaster Clock Device)は、全てのPTP Slave(そのMaster Clock Deviceから時刻を受け取るクライアント)に対してSync Messageを送信する(この時のMaster Clock Deviceの時刻が「t1」)
  2. それぞれのPTP SlaveはそのSync Messageを受けたら、それぞれ自分の時刻「t2」を記録しておく
  3. PTP Masterは、次いでFollow_up Messageを送信するが、その際に最初に送った時刻「t1」を付加する
  4. PTP Slaveは、PTP MasterにDelay_Req Messageを送信する。その際に、まさに送信した自分の時間「t3」を記録しておく
  5. PTP MasterはDelay_Req Messageを受信した際に、その時間「t4」を記録しておく
  6. PTP MasterはPTP Clientに対し、そのt4を含むDelay_Resp Messageを送信する

 さて、ここでPTP MasterとPTP Slaveの通信の遅延時間をDelay、PTP MasterとPTP Slaveの時計の差をOffsetとすると、以下のように計算されることになる。

Delay =((t2-t1)+(t4-t3))÷2

Offset=((t2-t1)-(t4-t3))÷2

 少し分かりにくいかもしれないが、もし仮にPTP MasterとPTP Slaveの時計が完全に一致していれば、「t2-t1」や「t4-t3」というのは純粋に通信の遅延(Delay)となるので、2つの平均を取れば、ちょうど片方向のDelayが算出できる。

 一方で、そのDelayの分を「t1」なり「t4」から引けば、PTP MasterとPTP Slaveの差を算出できることになる。あとはPTP Slaveは自らの時計に対し、そのOffset分を補正すれば、PTP Masterと時計を合わせられるというわけだ。

 さて、そうなったときにどこで精度が決まるのかと言えば、どれだけ厳密に時刻を記録できるかにかかっている。PTPは時刻をTimeRepresentation形のデータ構造で保持し、その値はUNIXと同じく1970年1月1日 0:00:00(これをUNIX Epochと呼ぶ)からの経過時間で示される。

 UNIXとは異なり、6Bytes(48bit)の秒数と4Bytes(32bit)のnanosecondsから構成されるが、ただし、nanosecondsは1秒(=10億ns)以上の値を採らず、10億になったら0クリアし、その分1秒加算するようになっている。

 このため、精度の面からは、nsオーダーの格納が可能である。もっとも、この精度が常に得られるかはまた別の問題で、そもそもnsオーダーで正確に時刻を測定して記録するのは、そうしたハードウェアが必要になる。例えばI2Cに接続されたReal Time Clockから現在のTimestampをCPU経由で読み込んで時間を判断するなら、それだけで数百μsほどがかかりかねないし、nsオーダーで正確なReal Time Clockそのものも、ほとんど存在しない。

 こうしたこともあって、「PTP MasterとSlaveのハードウェアが対応していれば、nsオーダーの時間合わせが可能」としつつ、実際にはμs~msの精度になることが珍しくない。

 とは言え、まずは順調に標準化が完了したPTPv1であるが、使っている中でさまざまな不満というか改善点が出てきた。このあたりを踏まえ、PTPv2が登場することとなる。

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/