RFC1589 日本語訳
1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. (Format: TXT=88129 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Mills Request for Comments: 1589 University of Delaware Category: Informational March 1994
工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1589年のデラウエア大学カテゴリ: 情報の1994年3月
A Kernel Model for Precision Timekeeping
精度時間保持のためのカーネルモデル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Overview
概要
This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. It has been implemented in the Unix kernel for several workstations, including those made by Sun Microsystems and Digital Equipment. The model changes the way the system clock is adjusted in time and frequency, as well as provides mechanisms to discipline its frequency to an external precision timing source. The model incorporates a generic system-call interface for use with the Network Time Protocol (NTP) or similar time synchronization protocol. The NTP Version 3 daemon xntpd operates with this model to provide synchronization limited in principle only by the accuracy and stability of the external timing source.
このメモはジェネリックオペレーティングシステムのために精度時刻機能を実装するエンジニアリングモデルについて説明します。 モデルは規律がある振動子と工学文学でしばしば見つけられたフェーズ・ロック輪(PLL)の本質に基づいています。 それはサン・マイクロシステムズとデジタル・イクイップメントによって作られたものを含むいくつかのワークステーションのためにUnixカーネルで実装されました。 モデルは、システムクロックが調整される時間内にの方法と頻度を変えて、外部の精密なタイミングソースに頻度を訓練するためにメカニズムを提供します。 モデルは使用のためにNetwork Timeプロトコル(NTP)か同様の時間同期化プロトコルでジェネリックシステムコールインタフェースを取り入れます。 NTPバージョン3デーモンxntpdは、原則として外部タイミングソースの精度と安定性だけによって制限された同期を提供するためにこのモデルと共に作動します。
This memorandum does not obsolete or update any RFC. It does not propose a standard protocol, specification or algorithm. It is intended to provoke comment, refinement and alternative implementations. While a working knowledge of NTP is not required for an understanding of the design principles or implementation of the model, it may be helpful in understanding how the model behaves in a fully functional timekeeping system. The architecture and design of NTP is described in [1], while the current NTP Version 3 protocol specification is given in RFC-1305 [2] and a subset of the protocol, the Simple Network Time Protocol (SNTP), in RFC-1361 [4].
このメモは、少しのRFCも時代遅れにもしませんし、アップデートもしません。 それは標準プロトコル、仕様またはアルゴリズムを提案しません。 コメント、気品、および代替の実装を引き起こすのは意図しています。 NTPの実用的な知識はモデルの設計原理か実装の理解に必要でない間、モデルが完全に機能的な時間保持システムでどのように振る舞うかを理解する際にそれは役立っているかもしれません。 NTPのアーキテクチャとデザインは[1]で説明されます、プロトコルのRFC-1305[2]と部分集合で現在のNTPバージョン3プロトコル仕様を与えますが、Simple Network Timeプロトコル(SNTP)、RFC-1361[4]で。
The model has been implemented in three Unix kernels for Sun Microsystems and Digital Equipment workstations. In addition, for the Digital machines the model provides improved precision to one microsecond (us). Since these specific implementations involve modifications to licensed code, they cannot be provided directly. Inquiries should be directed to the manufacturer's representatives. However, the engineering model for these implementations, including a
モデルはサン・マイクロシステムズとデジタル・イクイップメントワークステーションのために3つのUnixカーネルで実装されました。 さらに、Digitalマシンのために、モデルは1マイクロセカンド(私たち)まで改良された精度を提供します。 これらの特定の実装が認可されたコードへの変更にかかわるので、直接それらを提供できません。 問い合せはメーカーの代表に向けられるべきです。 しかしながら、工学はaを含むこれらの実装のためにモデル化されます。
Mills [Page 1] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[1ページ]。
simulator with code segments almost identical to the implementations, but not involving licensed code, is available via anonymous FTP from host louie.udel.edu in the directory pub/ntp and compressed tar archive kernel.tar.Z. The NTP Version 3 distribution can be obtained via anonymous ftp from the same host and directory in the compressed tar archive xntp3.3g.tar.Z, where the version number shown as 3.3g may be adjusted for new versions as they occur.
かかわるのではなく、実装とほとんど同じコードセグメントがあるシミュレータは、コードを認可して、ディレクトリパブ/ntpでホストlouie.udel.eduからの公開FTPで利用可能であり、タールアーカイブkernel.tar.Z.NTPバージョンを圧縮しました。同じホストからのアノニマスFTPと圧縮されたタールアーカイブxntp3.3g. tar.Zのディレクトリで3分配を得ることができます。(そこでは、起こるのに応じて、3.3gとして示されたバージョン番号が新しいバージョンのために調整されるかもしれません)。
1. Introduction
1. 序論
This memorandum describes a model and programming interface for generic operating system software that manages the system clock and timer functions. The model provides improved accuracy and stability for most workstations and servers using the Network Time Protocol (NTP) or similar time synchronization protocol. This memorandum describes the principles of design and implementation of the model. Related technical reports discuss the design approach, engineering analysis and performance evaluation of the model as implemented in Unix kernels for Sun Microsystems and Digital Equipment workstations. The NTP Version 3 daemon xntpd operates with these implementations to provide improved accuracy and stability, together with diminished overhead in the operating system and network. In addition, the model supports the use of external timing sources, such as precision pulse-per-second (PPS) signals and the industry standard IRIG timing signals. The NTP daemon automatically detects the presence of the new features and utilizes them when available.
このメモはシステムクロックとタイマ機能を管理するジェネリックオペレーティングシステムソフトウェアのためにモデルとプログラミングインターフェースについて説明します。 モデルは、Network Timeプロトコル(NTP)か同様の時間同期化プロトコルを使用することで改良された精度と安定性をほとんどのワークステーションとサーバに提供します。 このメモはモデルの設計と実装の原則について説明します。 関連技術報告書はサン・マイクロシステムズとデジタル・イクイップメントワークステーションのためにUnixカーネルで実装されるようにモデルの設計手法、技術解析、および業績評価について議論します。 NTPバージョン3デーモンxntpdは、減少しているオーバーヘッドと共に改良された精度と安定性をオペレーティングシステムとネットワークに供給するためにこれらの実装で作動します。 さらに、モデルは外部タイミングソースの使用をサポートします、精度1秒あたりのパルス(PPS)信号や業界基準IRIGタイミング信号のように。 NTPデーモンは、自動的に新機能の存在を検出して、利用可能であるときに、それらを利用します。
There are three prototype implementations of the model presented in this memorandum, one each for the Sun Microsystems SPARCstation with the SunOS 4.1.x kernel, Digital Equipment DECstation 5000 with the Ultrix 4.x kernel and Digital Equipment 3000 AXP Alpha with the OSF/1 V1.x kernel. In addition, for the DECstation 5000/240 and 3000 AXP Alpha machines, a special feature provides improved precision to 1 us (Sun 4.1.x kernels already do provide 1-us precision). Other than improving the system clock accuracy, stability and precision, these implementations do not change the operation of existing Unix system calls which manage the system clock, such as gettimeofday(), settimeofday() and adjtime(); however, if the new features are in use, the operations of gettimeofday() and adjtime() can be controlled instead by new system calls ntp_gettime() and ntp_adjtime() as described below.
このメモに提示されたモデル、SunOS 4.1.xカーネルがあるサン・マイクロシステムズSPARCstation、Ultrix 4.xカーネルがあるデジタル・イクイップメントDECstation5000、およびOSF/1V1.xカーネルをもっているデジタル・イクイップメント3000のAXPアルファーのためのそれぞれものの3つのプロトタイプ実装があります。 アルファーが機械加工するDECstation5000/240と3000AXPのために、さらに、特徴が改良された精度を1に提供する、私たち、(Sun4.1.xカーネルが既に提供される、1、-、私たち、精度) システムクロック精度、安定性、および精度を改良する以外に、これらの実装はシステムクロックを管理する既存のUnixシステムコールの操作を変えません、gettimeofday()や、settimeofday()やadjtime()などのように。 しかしながら、新機能が使用中であるなら、新しいシステムコールのntp_gettime()とntp_adjtime()は代わりに以下で説明されるようにgettimeofday()とadjtime()の操作を制御できます。
A detailed description of the variables and algorithms is given in the hope that similar functionality can be incorporated in Unix kernels for other machines. The algorithms involve only minor changes to the system clock and interval timer routines and include interfaces for application programs to learn the system clock status and certain statistics of the time synchronization process. Detailed
他のマシンのために同様の機能性をUnixカーネルに取り入れることができるという望みで変数とアルゴリズムの詳述を与えます。 アルゴリズムは、システムクロックとインタバルタイマルーチンにマイナーチェンジだけを伴って、アプリケーション・プログラムが時間同期化プロセスのシステムクロック状態とある統計を学ぶように、インタフェースを含んでいます。 詳しく述べられます。
Mills [Page 2] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[2ページ]。
installation instructions are given in a specific README files included in the kernel distributions.
カーネル配にファイルを含んでいて、特定のREADMEでインストールガイドを与えます。
In this memorandum, NTP Version 3 and the Unix implementation xntp3 are used as an example application of the new system calls for use by a synchronization daemon. In principle, the new system calls can be used by other protocols and implementations as well. Even in cases where the local time is maintained by periodic exchanges of messages at relatively long intervals, such as using the NIST Automated Computer Time Service, the ability to precisely adjust the system clock frequency simplifies the synchronization procedures and allows the telephone call frequency to be considerably reduced.
このメモでは、NTPバージョン3とUnix実装xntp3は使用に新しいシステムコールの例の応用として同期デーモンによって使用されます。 原則として、他のプロトコルとまた、実装は新しいシステムコールを使用できます。 現地時間がメッセージの周期的な交換によって比較的長い間隔で、維持されるNIST AutomatedコンピュータTime Serviceを使用などなどの場合ではさえ、正確にシステムクロック周波数を調整する能力は、同期手順を簡素化して、通話頻度がかなり減少するのを許容します。
2. Design Approach
2. 設計手法
While not strictly necessary for an understanding or implementation of the model, it may be helpful to briefly describe how NTP operates to control the system clock in a client workstation. As described in [1], the NTP protocol exchanges timestamps with one or more peers sharing a synchronization subnet to calculate the time offsets between peer clocks and the local clock. These offsets are processed by several algorithms which refine and combine the offsets to produce an ensemble average, which is then used to adjust the local clock time and frequency. The manner in which the local clock is adjusted represents the main topic of this memorandum. The goal in the enterprise is the most accurate and stable system clock possible with the available kernel software and workstation hardware.
厳密にモデルの理解か実装に必要でない間、簡潔にNTPがクライアントワークステーションでシステムクロックを制御するためにどう作動するかを説明するのは役立っているかもしれません。 [1]で説明されるように、NTPプロトコルは時間が同輩時計と地方の時計の間で相殺されると見込むために同期サブネットを共有している1人以上の同輩とタイムスタンプを交換します。 これらのオフセットは次に地方のクロック・タイムと頻度を調整するのに使用されるアンサンブル平均を起こすためにオフセットを洗練して、結合するいくつかのアルゴリズムで処理されます。 地方の時計が調整される方法はこのメモの主な話題を表します。 企業における目標は利用可能なカーネルソフトウェアとワークステーションハードウェアで可能な最も正確で安定したシステムクロックです。
In order to understand how the new software works, it is useful to review how most Unix kernels maintain the system time. In the Unix design a hardware counter interrupts the kernel at a fixed rate: 100 Hz in the SunOS kernel, 256 Hz in the Ultrix kernel and 1024 Hz in the OSF/1 kernel. Since the Ultrix timer interval (reciprocal of the rate) does not evenly divide one second in microseconds, the Ultrix kernel adds 64 microseconds once each second, so the timescale consists of 255 advances of 3906 us plus one of 3970 us. Similarly, the OSF/1 kernel adds 576 us once each second, so its timescale consists of 1023 advances of 976 us plus one of 1552 us.
新しいソフトウェアがどのように働くかを理解するために、ほとんどのUnixカーネルがどうシステム時間を維持するかを見直すのは役に立ちます。 Unixデザインでは、ハードウェアカウンタは定率でカーネルを中断します: SunOSカーネルにおける100Hz、Ultrixカーネルにおける256Hz、およびOSF/1カーネルにおける1024Hz。 以来、Ultrixタイマ間隔(レートの逆数)は均等でなくマイクロセカンドのある2番目、Ultrixカーネルが、スケールが3906年の255の進歩から成って、64マイクロセカンドがそれぞれ一度後援すると言い足す分水嶺に3970年の私たちと1つをします。私たち。 同様に、OSF/1カーネルが576を加える、私たち、したがって、1秒に一度、スケールが976の1023の進歩から成る、1552年の私たちと1つ、私たち。
2.1. Mechanisms to Adjust Time and Frequency
2.1. 時間と頻度を調整するメカニズム
In most Unix kernels it is possible to slew the system clock to a
new offset relative to the current time by using the adjtime()
system call. To do this the clock frequency is changed by adding
or subtracting a fixed amount (tickadj) at each timer interrupt
(tick) for a calculated number of ticks. Since this calculation
involves dividing the requested offset by tickadj, it is possible
to slew to a new offset with a precision only of tickadj, which is
大部分では、それが可能であるUnixカーネルはadjtime()システムコールを使用するのによる現在の時間に比例して新しいオフセットにシステムクロックを殺しました。 これをするために、それぞれのタイマ割込み(カチカチと音を立てる)のときに計算された数のカチカチする音のために、定額(tickadj)を加えるか、または引き算することによって、クロック周波数を変えます。 この計算が、要求されたオフセットをtickadjに割ることを伴うので、それはtickadjだけの精度で新しいオフセットにどっさり可能であり、どれがありますか?
Mills [Page 3] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[3ページ]。
usually in the neighborhood of 5 us, but sometimes much more. This
results in a roundoff error which can accumulate to an
unacceptable degree, so that special provisions must be made in
the clock adjustment procedures of the synchronization daemon.
通常、近所、5 しかし、私たち、はるかに時々多く。 これは容認できない度合いに蓄積できるロンダード誤りをもたらします、同期デーモンのクロック調整手順で特別条項を作らなければならないように。
In order to implement a frequency-discipline function, it is
necessary to provide time offset adjustments to the kernel at
regular adjustment intervals using the adjtime() system call. In
order to reduce the system clock jitter to the regime considered
in this memorandum, it is necessary that the adjustment interval
be relatively small, in the neighborhood of 1 s. However, the Unix
adjtime() implementation requires each offset adjustment to
complete before another one can be begun, which means that large
adjustments must be amortized in possibly many adjustment
intervals. The requirement to implement the adjustment interval
and compensate for roundoff error considerably complicates the
synchronizing daemon implementation.
頻度規律機能を実装するために、一定の調整間隔におけるカーネルに時間オフセット調整を提供するのがadjtime()システムコールを使用することで必要です。 このメモで考えられた政権へのシステムクロックジターを減少させるために、調整間隔が比較的小さいのが必要です、1秒間の近所で。 Unix adjtime()実装は、別の1つを始めることができる前にそれぞれのオフセット調整が完成するのをしかしながら、どれが、ことによると多くの調整間隔で大きい調整を清算しなければならないことを意味するかを必要とします。 調整間隔を実装して、ロンダード誤りを補うという要件は連動しているデーモン実装をかなり複雑にします。
In the new model this scheme is replaced by another that
represents the system clock as a multiple-word, precision-time
variable in order to provide very precise clock adjustments. At
each timer interrupt a precisely calibrated quantity is added to
the kernel time variable and overflows propagated as required. The
quantity is computed as in the NTP local clock model described in
[3], which operates as an adaptive-parameter, first-order, type-II
phase-lock loop (PLL). In principle, this PLL design can provide
precision control of the system clock oscillator within 1 us and
frequency to within parts in 10^11. While precisions of this order
are surely well beyond the capabilities of the CPU clock
oscillator used in typical workstations, they are appropriate
using precision external oscillators as described below.
新しいモデルでは、この体系を非常に正確なクロック調整を提供するために複数の単語、精度時間変数としてシステムクロックを表す別のものに取り替えます。 それぞれのタイマ割込みのときに、正確に較正された量は必要に応じて伝播されたカーネル時間変数とオーバーフローに追加されます。 量は適応型のパラメタ(一次、IIをタイプしているフェーズ・ロック輪(PLL))として作動する[3]で説明されたNTPのローカルの時計モデルのように計算されます。 原則として、このPLLデザインは10^11で1の中のシステムクロック発振器の精度コントロールに部品への私たちと頻度を提供できます。 このオーダーの確度はかなり確実に典型的なワークステーションで使用されるCPUクロック発振器の能力を超えていますが、それらは以下で説明されるように精度外部発振器を使用するのにおいて適切です。
The PLL design is identical to the one originally implemented in
NTP and described in [3]. In this design the software daemon
simulates the PLL using the adjtime() system call; however, the
daemon implementation is considerably complicated by the
considerations described above. The modified kernel routines
implement the PLL in the kernel using precision time and frequency
representions, so that these complications are avoided. A new
system call ntp_adjtime() is called only as each new time update
is determined, which in NTP occurs at intervals of from 16 s to
1024 s. In addition, doing frequency compensation in the kernel
means that the system time runs true even if the daemon were to
cease operation or the network paths to the primary
synchronization source fail.
PLLデザインは元々、NTPで実装されて、[3]で説明されたものと同じです。 このデザインでは、ソフトウェアデーモンはadjtime()システムコールを使用することでPLLをシミュレートします。 しかしながら、デーモン実装は上で説明された問題によってかなり複雑にされます。 変更されたカーネルルーチンはカーネルで精度時間と頻度representionsを費やすことでPLLを実装します、これらの複雑さが避けられるように。 単にそれぞれの新期間アップデート(NTPでは16秒間から1024秒間ごとに起こる)が決定するように新しいシステムコールntp_adjtime()は呼ばれます。 さらに、カーネルにおける頻度補償をするのは、デーモンが操作をやめることになっていた、または主要な同期源へのネットワーク経路が失敗してもシステム時間が本当に稼働することを意味します。
In the new model the new ntp_adjtime() operates in a way similar
to the original adjtime() system call, but does so independently
新しいモデルでは、新しいntp_adjtime()はオリジナルのadjtime()システムコールと同様の方法で作動しますが、それほど独自にします。
Mills [Page 4] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[4ページ]。
of adjtime(), which continues to operate in its traditional
fashion. When used with NTP, it is the design intent that
settimeofday() or adjtime() be used only for system time
adjustments greater than +-128 ms, although the dynamic range of
the new model is much larger at +-512 ms. It has been the Internet
experience that the need to change the system time in increments
greater than +-128 ms is extremely rare and is usually associated
with a hardware or software malfunction or system reboot.
adjtime()では、伝統的なファッションで作動してください。(adjtime()は続けています)。 NTPと共に使用されると、+-128msが非常にまれであり、通常、ハードウェア、ソフトウェア不調またはシステムに関連しているよりすばらしい増分でシステム時間を変える必要性がリブートされるのによるデザインの意図のそのsettimeofday()かadjtime()が+-128msより大きいシステム時間調整にだけ使用されて、新しいモデルのダイナミックレンジが+-512原稿ではるかに大きいのですが、Itがインターネット経験であるということです。
The easiest way to set the time is with the settimeofday() system
call; however, this can under some conditions cause the clock to
jump backward. If this cannot be tolerated, adjtime() can be used
to slew the clock to the new value without running backward or
affecting the frequency discipline process. Once the system clock
has been set within +-128 ms, the ntp_adjtime() system call is
used to provide periodic updates including the time offset,
maximum error, estimated error and PLL time constant. With NTP the
update interval depends on the measured dispersion and time
constant; however, the scheme is quite forgiving and neither
moderate loss of updates nor variations in the update interval are
serious.
時間を決める最も簡単な方法がsettimeofday()システムコールと共にあります。 しかしながら、これで、時計はいくつかの条件のもとで後方までジャンプできます。 これを許容できないなら、背走しないで新しい値に時計を殺したか、または頻度規律プロセスに影響するのにadjtime()を使用できます。 システムクロックが+-128msの中にいったん設定されると、ntp_adjtime()システムコールは、時間オフセット、最大の誤り、およそ誤り、およびPLL時定数を含む周期的なアップデートを提供するのに使用されます。 NTPと共に、アップデート間隔を測定分散と時定数に依存します。 しかしながら、体系はかなり寛大です、そして、アップデートの適度の損失もアップデート間隔での変化も重大ではありません。
2.2 Daemon and Application Interface
2.2のデーモンとアプリケーションは連結します。
Unix application programs can read the system clock using the
gettimeofday() system call, which returns only the system time and
timezone data. For some applications it is useful to know the
maximum error of the reported time due to all causes, including
clock reading errors, oscillator frequency errors and accumulated
latencies on the path to a primary synchronization source.
However, in the new model the PLL adjusts the system clock to
compensate for its intrinsic frequency error, so that the time
errors expected in normal operation will usually be much less than
the maximum error. The programming interface includes a new system
call ntp_gettime(), which returns the system time, as well as the
maximum error and estimated error. This interface is intended to
support applications that need such things, including distributed
file systems, multimedia teleconferencing and other real-time
applications. The programming interface also includes the new
system call ntp_adjtime() mentioned previously, which can be used
to read and write kernel variables for time and frequency
adjustment, PLL time constant, leap-second warning and related
data.
unixアプリケーション・プログラムは、gettimeofday()システムコール(システム時間とタイムゾーンデータだけを返す)を使用することでシステムクロックを読むことができます。 いくつかのアプリケーションに、すべての原因のため報告された現代の最大の誤りを知るのは役に立ちます、経路で誤り、振動子頻度誤り、および蓄積された潜在を主要な同期源に読み込む時計を含んでいて。 しかしながら、新しいモデルでは、PLLは本質的な頻度誤りを補うようにシステムクロックを調整します、通常、通常の操作で予想された時間誤りは最大の誤りよりはるかに少なくなるでしょう。 プログラミングインターフェースは新しいシステムコールntp_gettime()を含んでいます、最大の誤りとおよそ誤りと同様に。(gettime()はシステム時間を返します)。 このインタフェースがそのようなものを必要とするアプリケーションをサポートすることを意図します、分散ファイルシステム、マルチメディア電子会議、および他のリアルタイムのアプリケーションを含んでいて。 また、プログラミングインターフェースは以前に言及された新しいシステムコールntp_adjtime()を含んでいます。(飛躍-第2時間、頻度調整、PLL時定数、警告、および関連するデータのためにカーネル変数を読み書きするのにadjtime()を使用できます)。
In addition, the kernel adjusts the maximum error to grow by an
amount equal to the oscillator frequency tolerance times the
elapsed time since the last update. The default engineering
parameters have been optimized for update intervals in the order
さらに、カーネルは、振動子周波数公差回数と等しい量に従ってアップデート以来の経過時間を育てるように最大の誤りを調整します。 デフォルト技術的パラメータはアップデート間隔の間、オーダーで最適化されています。
Mills [Page 5] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[5ページ]。
of 64 s. For other intervals the PLL time constant can be adjusted
to optimize the dynamic response over intervals of 16-1024 s.
Normally, this is automatically done by NTP. In any case, if
updates are suspended, the PLL coasts at the frequency last
determined, which usually results in errors increasing only to a
few tens of milliseconds over a day using room-temperature quartz
oscillators of typical modern workstations.
64秒間について。 他の間隔の間、-1024秒間の16の間隔の間、ダイナミックな応答を最適化するようにPLL時定数を調整できます。 通常、NTPは自動的にこれを完了しています。 どのような場合でも、頻度でのPLL海岸は、最後にアップデートが吊しているなら通常、どれが1日間ほんのいくつかに典型的な現代のワークステーションの室温水晶振動子を使用することで何十人ものミリセカンドをも増加させる誤りをもたらすかを決定しました。
While any synchronization daemon can in principle be modified to
use the new system calls, the most likely will be users of the NTP
Version 3 daemon xntpd. The xntpd code determines whether the new
system calls are implemented and automatically reconfigures as
required. When implemented, the daemon reads the frequency offset
from a file and provides it and the initial time constant via
ntp_adjtime(). In subsequent calls to ntp_adjtime(), only the time
offset and time constant are affected. The daemon reads the
frequency from the kernel using ntp_adjtime() at intervals of
about one hour and writes it to a system file. This information is
recovered when the daemon is restarted after reboot, for example,
so the sometimes extensive training period to learn the frequency
separately for each system can be avoided.
新しいシステムコールを使用するように原則としてどんな同期デーモンも変更できる間、大部分はおそらくNTPバージョン3デーモンxntpdのユーザになるでしょう。 xntpdコードは、新しいシステムコールが自動的に実行されるかどうか決定します。必要に応じて、再構成します。 実行されると、デーモンは、ファイルから相殺された頻度を読んで、ntp_adjtime()を通してそれと初期の時定数を提供します。 ntp_adjtime()へのその後の呼び出しでは、時間オフセットと時定数だけが影響を受けます。 デーモンは、カーネルからおよそ1時間ごとにntp_adjtime()を使用することで頻度を読み込んで、システムファイルにそれを書きます。 デーモンがリブートの後にいつ再開されるかというこの情報が回復されるので、例えば、各システムのために別々に頻度を学ぶ時々大規模なトレーニングの期間を避けることができます。
2.3. Precision Clocks for DECstation 5000/240 and 3000 AXP Alpha
2.3. DECstation5000/240のための精度時計と3000年のAXPアルファ
The stock microtime() routine in the Ultrix kernel returns system
time to the precision of the timer interrupt interval, which is in
the 1-4 ms range. However, in the DECstation 5000/240 and possibly
other machines of that family, there is an undocumented IOASIC
hardware register that counts system bus cycles at a rate of 25
MHz. The new microtime() routine for the Ultrix kernel uses this
register to interpolate system time between timer interrupts. This
results in a precision of 1 us for all time values obtained via
the gettimeofday() and ntp_gettime() system calls. For the Digital
Equipment 3000 AXP Alpha, the architecture provides a hardware
Process Cycle Counter and a machine instruction rpcc to read it.
This counter operates at the fundamental frequency of the CPU
clock or some submultiple of it, 133.333 MHz for the 3000/400 for
example. The new microtime() routine for the OSF/1 kernel uses
this counter in the same fashion as the Ultrix routine.
Ultrixカーネルにおけるストックmicrotime()ルーチンはタイマ中断間隔の精度にシステム時間を返します。(間隔が1-4ms範囲にあります)。 しかしながら、その家族のDECstation5000/240とことによると他のマシンに、25MHzのレートでシステムバスサイクルを数える正式書類のないIOASICハードウェアレジスタがあります。 Ultrixカーネルのための新しいmicrotime()ルーチンは、タイマ割込みの間でシステム時間を補間するのにこのレジスタを使用します。 これは1の精度をもたらします。gettimeofday()を通して得られたすべての時間的価値とntp_gettime()システムコールのための私たち。 デジタル・イクイップメント3000のAXPアルファーのために、構造はProcess Cycle Counterとそれを読む機械語命令rpccをハードウェアに供給します。 このカウンタはCPU時計の基本的な頻度かそれ(例えば、3000/400のための133.333MHz)の何らかの約数で作動します。 OSF/1カーネルのための新しいmicrotime()ルーチンはUltrixルーチンと同じファッションでこのカウンタを使用します。
In both the Ultrix and OSF/1 kernels the gettimeofday() and
ntp_gettime() system call use the new microtime() routine, which
returns the actual interpolated value, but does not change the
kernel time variable. Therefore, other routines that access the
kernel time variable directly and do not call either
gettimeofday(), ntp_gettime() or microtime() will continue their
present behavior. The microtime() feature is independent of other
features described here and is operative even if the kernel PLL or
UltrixとOSF/1カーネルの両方では、gettimeofday()とntp_gettime()システムコールは新しいmicrotime()ルーチンを使用します。(実際の補間された値を返しますが、それは、カーネル時間変数を変えません)。 したがって、直接カーネル時間変数にアクセスして、どちらもgettimeofday()と呼ばない他のルーチン、ntp_gettime()またはmicrotime()が彼らの現在の振舞いを続けるでしょう。 またはmicrotime()の特徴がここで説明された他の特徴から独立していて、作用している、カーネルPLL。
Mills [Page 6] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[6ページ]。
new system calls have not been implemented.
新しいシステムコールは実行されていません。
The SunOS kernel already includes a system clock with 1-us
resolution; so, in principle, no microtime() routine is necessary.
An existing kernel routine uniqtime() implements this function,
but it is coded in the C language and is rather slow at 42-85 us
per call. A replacement microtime() routine coded in assembler
language is available in the NTP Version 3 distribution and is
much faster at about 3 us per call.
SunOSカーネルが既にシステムクロックを含む、1、-、私たち、解決。 それで、原則として、どんなmicrotime()ルーチンも必要ではありません。 既存のカーネル通常のuniqtime()がこの機能を実行しますが、それは、C言語でコード化されて、42-85 私たちで呼び出し単位でかなり遅いです。 多くが3時頃により速いです。そして、アセンブラ言語でコード化された交換microtime()ルーチンがNTPバージョンで利用可能である、3分配、1呼び出しあたりの私たち。
2.4. External Time and Frequency Discipline
2.4. 外部の時間と頻度規律
The overall accuracy of a time synchronization subnet with respect
to Coordinated Universal Time (UTC) depends on the accuracy and
stability of the primary synchronization source, usually a radio
or satellite receiver, and the system clock oscillator of the
primary server. As discussed in [5], the traditional interface
using an RS232 protocol and serial port precludes the full
accuracy of the radio clock. In addition, the poor stability of
typical CPU clock oscillators limits the accuracy, whether or not
precision time sources are available. There are, however, several
ways in which the system clock accuracy and stability can be
improved to the degree limited only by the accuracy and stability
of the synchronization source and the jitter of the operating
system.
協定世界時(UTC)に関する時間同期化サブネットの精度は通常主要な同期源、ラジオまたは衛星電波受信装置の精度と安定性、および第一のサーバのシステムクロック発振器に依存します。[5]で議論するように、RS232プロトコルとシリアルポートを使用する伝統的なインタフェースはラジオ時計の完全な精度を排除します。 さらに、典型的なCPUクロック発振器の貧しい安定性は精度を制限します、精度時間ソースが手があいているか否かに関係なく。 しかしながら、同期ソースの精度と安定性とオペレーティングシステムのジターだけによって制限された程度にシステムクロック精度と安定性を改良できるいくつかの方法があります。
Many radio clocks produce special signals that can be used by
external equipment to precisely synchronize time and frequency.
Most produce a pulse-per-second (PPS) signal that can be read via
a modem-control lead of a serial port and some produce a special
IRIG signal that can be read directly by a bus peripheral, such as
the KSI/Odetics TPRO IRIG SBus interface, or indirectly via the
audio codec of some workstations, as described in [5]. In the NTP
Version 3 distribution, the PPS signal can be used to augment the
less precise ASCII serial timecode to improve accuracy to the
order of microseconds. Support is also included in the
distribution for the TPRO interface as well as the audio codec;
however, the latter requires a modified kernel audio driver
contained in the bsd_audio.tar.Z distribution in the same host and
directory as the NTP Version 3 distribution mentioned previously.
多くのラジオ時計が外部の設備によって使用される、時間と頻度を正確に同期させることができる特別な信号を作り出します。 大部分はシリアルポートのモデム制御リードで読むことができる1秒あたりのパルス(PPS)信号を作り出します、そして、或るものはKSI/Odetics TPRO IRIG SBusインタフェースなどのバス周辺機器の直接近く、または、間接的にいくつかのワークステーションのオーディオコーデックを通して読むことができる特別なIRIG信号を作り出します、[5]で説明されるように。 マイクロセカンドの注文に精度を改良するためにそれほど正確でないASCII連続のtimecodeを増大させるのに3分配、NTPバージョンにおけるPPS信号を使用できます。 また、サポートはオーディオコーデックと同様にTPROインタフェースのための分配に含まれています。 しかしながら、NTPバージョン3分配が以前に言及したように後者は同じホストにbsd_audio.tar.Z分配に含まれたカーネルの変更されたオーディオドライバーとディレクトリを必要とします。
2.4.1. PPS Signal
2.4.1. PPS信号
The NTP Version 3 distribution includes a special ppsclock
module for the SunOS 4.1.x kernel that captures the PPS signal
presented via a modem-control lead of a serial port. Normally,
the ppsclock module produces a timestamp at each transition of
the PPS signal and provides it to the synchronization daemon
NTPバージョン、3分配はシリアルポートのモデム制御リードで提示されたPPS信号を得るSunOS 4.1.xカーネルのための特別なppsclockモジュールを含んでいます。 通常、ppsclockモジュールは、PPS信号の各変遷のときにタイムスタンプを作り出して、同期デーモンにそれを提供します。
Mills [Page 7] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[7ページ]。
for integration with the serial ASCII timecode, also produced
by the radio clock. With the conventional PLL implementation in
either the daemon or the kernel as described above, the
accuracy of this scheme is limited by the intrinsic stability
of the CPU clock oscillator to a millisecond or two, depending
on environmental temperature variations.
また、ラジオによって生産された連続のASCII timecodeとの統合には、時間を計ってください。 上で説明されるデーモンか中に従来のPLL実現はあるカーネルのどちらか、この計画の精度がCPUクロック発振器の本質的な安定性によって1ミリセカンドか2ミリセカンドに制限されます、環境温度差によって。
The ppsclock module has been modified to in addition call a new
kernel routine hardpps() once each second. The kernel routine
compares the timestamp with a sample of the CPU clock
oscillator to develop a frequency offset estimate. This offset
is used to discipline the oscillator frequency, nominally to
within a few parts in 10^8, which is about two orders of
magnitude better than the undisciplined oscillator. The new
feature is conditionally compiled in the code described below
only if the PPS_SYNC option is used in the kernel configuration
file.
ppsclockモジュールは、さらに、新しいカーネルを1秒に一度通常のhardpps()と呼ぶように変更されました。 カーネルルーチンは、頻度オフセット見積りを発生するようにCPUクロック発振器のサンプルとタイムスタンプを比べます。 このオフセットは、名目上は10^8でいくつかの部品に振動子頻度を訓練するのに使用されます。(8は未熟な振動子よりおよそ2桁良いです)。 新機能はPPS_SYNCオプションがカーネル構成ファイルで使用される場合にだけ以下で説明されたコードで条件付きにコンパイルされます。
When using the PPS signal to adjust the time, there is a
problem with the SunOS implementation which is very delicate to
fix. The Sun serial port interrupt routine operates at
interrupt priority level 12, while the timer interrupt routine
operates at priority 10. Thus, it is possible that the PPS
signal interrupt can occur during the timer interrupt routine,
with result that a tick increment can be missed and the
returned time early by one tick. It may happen that, if the CPU
clock oscillator is within a few ppm of the PPS oscillator,
this condition can persist for two or more successive PPS
interrupts. A useful workaround has been to use a median filter
to process the PPS sample offsets. In this filter the sample
offsets in a window of 20 samples are sorted by offset and the
six highest and six lowest outlyers discarded. The average of
the eight samples remaining becomes the output of the filter.
時間を調整するのにPPS信号を使用するとき、修理するために非常にデリケートなSunOS実現に関する問題があります。 Sunシリアルポート割り込みルーチンは中断優先順位12で作動します、タイマ割り込みルーチンが優先権10で作動しますが。 したがって、中断が早く1時までにタイマ割り込みルーチンの間、カチカチする音増分を逃すことができるという結果と返された時間で発生できるというPPS信号がカチカチするのは、可能です。 PPS振動子の数ppmの中にCPUクロック発振器があるならこの状態が2つ以上の連続したPPS中断のために持続できるのは起こるかもしれません。 役に立つ次善策はPPSサンプルオフセットを処理するのにメジアンフィルターを使用することです。 このフィルタでは、20個のサンプルの窓でのサンプルオフセットはオフセットで分類されました、そして、最も高い、そして、6の6の最も低いoutlyersは捨てられました。 8個のサンプルが残る平均はフィルタの出力になります。
The problem is not nearly so serious when using the PPS signal
to discipline the frequency of the CPU clock oscillator. In
this case the quantity of interest is the contents of the
microseconds counter only, which does not depend on the kernel
time variable.
CPUクロック発振器の頻度を訓練するのにPPS信号を使用するとき、問題はそれほど決して重大ではありません。 この場合、興味がある量はマイクロセカンドカウンタだけのコンテンツです。(それは、カーネル時間変数に依存しません)。
2.4.2. External Clocks
2.4.2. 外部クロック
It is possible to replace the system clock function with an
external bus peripheral. The TPRO device mentioned previously
can be used to provide IRIG-synchronized time with a precision
of 1 us. A driver for this device tprotime.c and header file
tpro.h are included in the kernel.tar.Z distribution mentioned
previously. Using this device the system clock is read directly
システムクロック機能を外部のバス周辺機器に取り替えるのは可能です。 1の精度があるIRIGによって連動させられた時間に私たちを提供するのに以前に言及されたTPRO装置は使用できます。 この装置tprotime.cとヘッダーファイルtpro.hのためのドライバーは以前にkernel.tar.Z分配で言及されていた状態で含まれています。 システムクロックが直接読み込まれるこの装置を使用します。
Mills [Page 8] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[8ページ]。
from the interface; however, the device does not record the
year, so special provisions have to be made to obtain the year
from the kernel time variable and initialize the driver
accordingly. This feature is conditionally compiled in the code
described below only if the EXT_CLOCK option is used in the
kernel configuration file.
インタフェースから。 しかしながら、装置は1年を記録しません、非常に特別であるので、条項はカーネル時間変数から1年を得て、それに従って、ドライバーを初期化するのが作られていなければなりません。 この特徴はEXT_CLOCKオプションがカーネル構成ファイルで使用される場合にだけ以下で説明されたコードで条件付きにコンパイルされます。
While the system clock function is provided directly by the
microtime() routine in the driver, the kernel time variable
must be disciplined as well, since not all system timing
functions use the microtime() routine. This is done by
measuring the difference between the microtime() clock and
kernel time variable and using the difference to adjust the
kernel PLL as if the adjustment were provided by an external
peer and NTP.
直接ドライバーのmicrotime()ルーチンでシステムクロック機能を提供している間、また、カーネル時間変数を訓練しなければなりません、すべてのシステムタイミング機能がmicrotime()ルーチンを使用するというわけではないので。 microtime()時計とカーネル時間変数の違いを測定して、まるで調整が外部の同輩とNTPによって提供されるかのようにカーネルPLLを調整するのに違いを使用することによって、これをします。
A good deal of error checking is done in the TPRO driver, since
the system clock is vulnerable to a misbehaving radio clock,
IRIG signal source, interface cables and TPRO device itself.
Unfortunately, there is no easy way to utilize the extensive
diversity and redundancy capabilities available in the NTP
synchronization daemon. In order to avoid disruptions that
might occur if the TPRO time is far different from the kernel
time variable, the latter is used instead of the former if the
difference between the two exceeds 1000 s; presumably in that
case operator intervention is required.
TPROドライバーで多くの誤りの照合をします、システムクロックがふらちな事をしているラジオ時計、IRIG信号ソース、インタフェース・ケーブル、およびTPRO装置自体に傷つきやすいので。 残念ながら、NTP同期デーモンで利用可能な大規模な多様性と冗長能力を利用するどんな簡単な方法もありません。 TPRO時間がカーネル時間変数からはるかにいろいろであるなら起こるかもしれない分裂を避けるために、2の違いが1000秒間を超えているなら、後者は前者の代わりに使用されます。 おそらくその場合、オペレータ介入が必要です。
2.4.3. External Oscillators
2.4.3. 外部発振器
Even if a source of PPS or IRIG signals is not available, it is
still possible to improve the stability of the system clock
through the use of a specialized bus peripheral. In order to
explore the benefits of such an approach, a special SBus
peripheral caled HIGHBALL has been constructed. The device
includes a pair of 32-bit hardware counters in Unix timeval
format, together with a precision, oven-controlled quartz
oscillator with a stability of a few parts in 10^9. A driver
for this device hightime.c and header file high.h are included
in the kernel.tar.Z distribution mentioned previously. This
feature is conditionally compiled in the code described below
only if the EXT_CLOCK and HIGHBALL options are used in the
kernel configuration file.
PPSかIRIG信号の源が利用可能でなくても、専門化しているバス周辺機器の使用でシステムクロックの安定性を改良するのはまだ可能です。 そのようなアプローチの恩恵について調査するために、特別なSBus周囲のcaled HIGHBALLは組み立てられました。 装置はUnix timeval形式で1組の32ビットのハードウェアカウンタを含んでいます、精度と共に、10^9における、いくつかの部品の安定性があるオーブンで制御された水晶振動子。 この装置hightime.cとヘッダーファイルhigh.hのためのドライバーは以前にkernel.tar.Z分配で言及されていた状態で含まれています。 この特徴はEXT_CLOCKとHIGHBALLオプションがカーネル構成ファイルで使用される場合にだけ以下で説明されたコードで条件付きにコンパイルされます。
Unlike the external clock case, where the system clock function
is provided directly by the microtime() routine in the driver,
the HIGHBALL counter offsets with respect to UTC must be
provided first. This is done using the ordinary kernel PLL,
but controlling the counter offsets directly, rather than the
外部クロックケースと異なって、最初に、UTCに関するHIGHBALLカウンタオフセットを提供しなければなりません。そこでは、システムクロック機能が直接ドライバーのmicrotime()ルーチンで提供されます。 普通のカーネルPLLを使用することでこれをしますが、カウンタを制御するのは直接、むしろ相殺されます。
Mills [Page 9] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[9ページ]。
kernel time variable. At first, this might seem to defeat the
purpose of the design, since the jitter and wander of the
synchronization source will affect the counter offsets and thus
the accuracy of the time. However, the jitter is much reduced
by the PLL and the wander is small, especially if using a radio
clock or another primary server disciplined in the same way.
In practice, the scheme works to reduce the incidental wander
to a few parts in 10^8, or about the same as using the PPS
signal.
カーネル時間変数。 初めに、これは、ジター以来デザインの目的をくつがえして、同期ソースまでさまようのがカウンタオフセットとその結果現代の精度に影響するように思えるかもしれません。 そして、しかしながら、ジターはPLLによって非常に減少させられる、歩き回る、使用して、小さく、そして、特に、aラジオが時間を計るか、そして、同様に、訓練された別の第一のサーバがそうです。 実際には、付帯的を減少させる計画作品は10^8におけるいくつかの部品、またはPPS信号を使用するのとほぼ同じくらいにさまよいます。
As in the previous case, the kernel time variable must be
disciplined as well, since not all system timing functions use
the microtime() routine. However, the kernel PLL cannot be used
for this, since it is already in use providing offsets for the
HIGHBALL counters. Therefore, a special correction is
calculated from the difference between the microtime() clock
and the kernel time variable and used to adjust the kernel time
variable at the next timer interrupt. This somewhat roundabout
approach is necessary in order that the adjustment does not
cause the kernel time variable to jump backwards and possibly
lose or duplicate a timer event.
先の事件のように、また、カーネル時間変数を訓練しなければなりません、すべてのシステムタイミング機能がmicrotime()ルーチンを使用するというわけではないので。 しかしながら、これにカーネルPLLを使用できません、HIGHBALLカウンタのためのオフセットを提供するのが既に使用中であるので。 したがって、特別な修正は、microtime()時計とカーネル時間変数の違いから計算されて、次のタイマ割込みのときにカーネル時間変数を調整するのに使用されます。 調整がことによるとタイマ出来事をカーネル時間変数がジャンプすることを後方に引き起こして、負けるか、またはコピーしないように、このいくらか回りくどいアプローチが必要です。
2.5 Other Features
2.5 他の特徴
It is a design feature of the NTP architecture that the system
clocks in a synchronization subnet are to read the same or nearly
the same values before during and after a leap-second event, as
declared by national standards bodies. The new model is designed
to implement the leap event upon command by an ntp_adjtime()
argument. The intricate and sometimes arcane details of the model
and implementation are discussed in [3] and [5]. Further details
are given in the technical summary later in this memorandum.
それは同期サブネットにおけるシステムクロックが同じように読むことになっている建築学かほとんど同じくらいが出来事と閏秒出来事の後に以前評価するNTPに関する設計上の特徴です、国家標準化機関によって宣言されるように。 新しいモデルは、コマンドのときにntp_adjtime()議論で飛躍出来事を実行するように設計されています。 [3]と[5]でモデルと実現の複雑で時々秘密の詳細について議論します。 後でこのメモで技術概要で詳細を与えます。
3. Technical Summary
3. 技術概要
In order to more fully understand the workings of the model, a stand- alone simulator kern.c and header file timex.h are included in the kernel.tar.Z distribution mentioned previously. In addition, a complete C program kern_ntptime.c which implements the ntp_gettime() and ntp_adjtime() functions is provided, but with the vendor-specific argument-passing code deleted. Since the distribution is somewhat large, due to copious comments and ornamentation, it is impractical to include a listing of these programs in this memorandum. In any case, implementors may choose to snip portions of the simulator for use in new kernel designs, but, due to formatting conventions, this would be difficult if included in this memorandum.
モデルの作業をより完全に理解するために、スタンドの単独のシミュレータkern.cとヘッダーファイルtimex.hは以前に言及されたkernel.tar.Z分配に含まれています。 ntp_gettime()とntp_adjtime()機能を実行するプログラム凝結核_ntptime.cをさらに、そして、完全なCで、提供しますが、業者特有の議論が一時的なコードで削除します。 分配が豊富なコメントと装飾のためにいくらか大きいので、このメモにこれらのプログラムのリストを含んでいるのは非実用的です。 どのような場合でも、作成者は、新しいカーネルデザインにおける使用のためのシミュレータの一部をチョキンと切るのを選ぶかもしれませんが、形式コンベンションのために、このメモに含まれているなら、これは難しいでしょう。
Mills [Page 10] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[10ページ]。
The kern.c program is an implementation of an adaptive-parameter, first-order, type-II phase-lock loop. The system clock is implemented using a set of variables and algorithms defined in the simulator and driven by explicit offsets generated by a driver program also included in the program. The algorithms include code fragments almost identical to those in the machine-specific kernel implementations and operate in the same way, but the operations can be understood separately from any licensed source code into which these fragments may be integrated. The code fragments themselves are not derived from any licensed code. The following discussion assumes that the simulator code is available for inspection.
kern.cプログラムは適応型のパラメタの、そして、一次、IIをタイプしているフェーズ・ロック輪の実現です。 システムクロックは、シミュレータで定義された1セットの変数とアルゴリズムを使用することで実行されて、また、プログラムに含まれていたドライバープログラムで発生する明白なオフセットで動かされます。 アルゴリズムは、マシン特有のカーネル実現にそれらとほとんど同じコード断片を含んで、同様に作動しますが、別々にこれらの断片が統合しているかもしれないどんな認可されたソースコードからも操作を理解できます。 コード断片自体はどんな認可されたコードからも得られません。 以下の議論は、シミュレータコードが点検に利用可能であると仮定します。
3.1. PLL Simulation
3.1. PLLシミュレーション
The simulator operates in conformance with the analytical model
described in [3]. The main() program operates as a driver for the
fragments hardupdate(), hardclock(), second_overflow(), hardpps()
and microtime(), although not all functions implemented in these
fragments are simulated. The program simulates the PLL at each
timer interrupt and prints a summary of critical program variables
at each time update.
分析モデルが[3]で説明されている状態で、シミュレータは順応で作動します。 メイン()プログラムは断片hardupdate()、hardclock()、2番目の_オーバーフロー()、hardpps()、およびmicrotime()のためのドライバーとして作動します、これらの断片で実行されたというわけではないすべての機能がシミュレートされますが。 プログラムは、それぞれのタイマ割込みのときにPLLをシミュレートして、それぞれの時間アップデートのときに重要なプログラム変数の概要を印刷します。
There are three defined options in the kernel configuration file
specific to each implementation. The PPS_SYNC option provides
support for a pulse-per-second (PPS) signal, which is used to
discipline the frequency of the CPU clock oscillator. The
EXT_CLOCK option provides support for an external kernel-readable
clock, such as the KSI/Odetics TPRO IRIG interface or HIGHBALL
precision oscillator, both for the SBus. The TPRO option provides
support for the former, while the HIGHBALL option provides support
for the latter. External clocks are implemented as the microtime()
clock driver, with the specific source code selected by the kernel
configuration file.
各実現に特定のカーネル構成ファイルには3つの定義されたオプションがあります。 PPS_SYNCオプションは1秒あたりのパルス(PPS)信号のサポートを提供します。(信号は、CPUクロック発振器の頻度を訓練するのに使用されます)。 EXT_CLOCKオプションは外部のカーネル読み込み可能な時計のサポートを提供します、KSI/Odetics TPRO IRIGインタフェースやHIGHBALL精度振動子のように、ともにSBusのために。 TPROオプションは前者のサポートを提供しますが、HIGHBALLオプションは後者のサポートを提供します。 特定のソースコードがカーネル構成ファイルによって選択されている状態で、外部クロックはmicrotime()時計ドライバーとして実行されます。
3.1.1. The hardupdate() Fragment
3.1.1. hardupdate()断片
The hardupdate() fragment is called by ntp_adjtime() as each
update is computed to adjust the system clock phase and
frequency. Note that the time constant is in units of powers of
two, so that multiplies can be done by simple shifts. The phase
variable is computed as the offset divided by the time
constant. Then, the time since the last update is computed and
clamped to a maximum (for robustness) and to zero if
initializing. The offset is multiplied (sorry about the ugly
multiply) by the result and divided by the square of the time
constant and then added to the frequency variable. Note that
all shifts are assumed to be positive and that a shift of a
signed quantity to the right requires a little dance.
各アップデートがシステムクロックフェーズと頻度を調整するために計算されるようにhardupdate()断片はntp_adjtime()によって呼ばれます。 それが増えて、2簡単なシフトでユニットの強国には時定数があるというメモができます。 フェーズ変数は時定数が割られたオフセットとして計算されます。 次に、初期設定するなら、アップデート以来の時間は、最大(丈夫さのための)と、そして、ゼロに計算されて、固定されます。 オフセットが掛けられる、(残念である、醜さに関して、増えてください、)、時定数であって次に、頻度変数に追加されていることの正方形による結果と分割で。 すべてのシフトが積極的であると思われて、右へのサインされた量のシフトが小さいダンスを必要とすることに注意してください。
Mills [Page 11] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[11ページ]。
With the defines given, the maximum time offset is determined
by the size in bits of the long type (32 or 64) less the
SHIFT_UPDATE scale factor (12) or at least 20 bits (signed).
The scale factor is chosen so that there is no loss of
significance in later steps, which may involve a right shift up
to SHIFT_UPDATE bits. This results in a time adjustment range
over +-512 ms. Since time_constant must be greater than or
equal to zero, the maximum frequency offset is determined by
the SHIFT_USEC scale factor (16) or at least 16 bits (signed).
This results in a frequency adjustment range over +-31,500 ppm.
SHIFT_UPDATEが要素(12)か少なくとも20ビット(サインされる)スケーリングする長いタイプそれほど(32か64)のビットのサイズに従ってオフセットが決定している最大の時代に考えて、定義します。 位取り因数は、正しいシフトをSHIFT_UPDATEビットまで伴うかもしれない後のステップにおける、意味の損失が全くないように、選ばれています。 SHIFT_USEC位取り因数(16)か少なくとも16ビット(サインされる)に従って、最大の頻度オフセットはこれが_定数がゼロ以上であるに違いない+-512原稿Since時間時間調整範囲をもたらすことを決定しています。 これは+-3万1500ppmの上で頻度調整範囲をもたらします。
In the addition step, the value of offset * mtemp is not
greater than MAXPHASE * MAXSEC = 31 bits (signed), which will
not overflow a long add on a 32-bit machine. There could be a
loss of precision due to the right shift of up to 12 bits,
since time_constant is bounded at 6. This results in a net
worst-case frequency resolution of about .063 ppm, which is not
significant for most quartz oscillators. The worst case could
be realized only if the NTP peer misbehaves according to the
protocol specification.
添加ステップでは、オフセット*mtempの値は31MAXPHASE*MAXSEC=ビット(サインされる)ほどすばらしくなく、またオーバーフローa長さは32ビットのマシンの上でどれを加えないでしょうか? 最大12ビットの正しいシフトによる精度の損失があるかもしれません、時間_定数は6時に境界があるので。 これはおよそ.063ppmのネットの最悪の場合周波数分解能をもたらします。(ほとんどの水晶振動子には、ppmは重要ではありません)。 NTP同輩がプロトコル仕様通りにふらちな事をする場合にだけ、最悪の場合は実現されるかもしれません。
The time_offset value is clamped upon entry. The time_phase
variable is an accumulator, so is clamped to the tolerance on
every call. This helps to damp transients before the oscillator
frequency has been determined, as well as to satisfy the
correctness assertions if the time synchronization protocol or
implementation misbehaves.
時間_オフセット価値はエントリーのときに固定されます。 時間_フェーズ変数は、アキュムレータであるのであらゆる呼び出しの寛容に固定されます。 これは、また、振動子頻度が測定される前の過渡現象を時間同期化プロトコルか実現がふらちな事をするなら正当性主張を満たすほどじめじめとするのを助けます。
3.1.2. The hardclock() Fragment
3.1.2. hardclock()断片
The hardclock() fragment is inserted in the hardware timer
interrupt routine at the point the system clock is to be
incremented. Previous to this fragment the time_update variable
has been initialized to the value computed by the adjtime()
system call in the stock Unix kernel, normally plus/minus the
tickadj value, which is usually in the order of 5 us. The
time_phase variable, which represents the instantaneous phase
of the system clock, is advanced by time_adj, which is
calculated in the second_overflow() fragment described below.
If the value of time_phase exceeds 1 us in scaled units,
time_update is increased by the (signed) excess and time_phase
retains the residue.
hardclock()断片はポイントでのハードウェアタイマ割り込みルーチンに挿入されて、システムクロックが増加されていることになっているということです。 時間_アップデート変数が持っているこの断片に前であるのは、初期化されて、値に、Unixカーネルがストックにおけるadjtime()システムコールで計算されていて、通常プラス/マイナスがtickadj値であるということです、通常、5の注文にあるもの。私たち。 時間_フェーズ変数(システムクロックの瞬時に起こっているフェーズを表す)は時間_adjによって進められます。(adjは以下で説明された2番目の_オーバーフロー()断片で計算されます)。 _フェーズがスケーリングされたユニットの私たち、_アップデートが(サインされます)過剰増加する時、および時間_が位相を合わせる1を超えている時の値が残りを保有するなら。
Except in the case of an external oscillator such as the
HIGHBALL interface, the hardclock() fragment advances the
system clock by the value of tick plus time_update. However, in
the case of an external oscillator, the system clock is
obtained directly from the interface and time_update used to
HIGHBALLインタフェースなどの外部発振器に関するケースを除いて、hardclock()断片はカチカチする音と時間_アップデートの値でシステムクロックを進めます。 しかしながら、外部発振器の場合では、直接インタフェースからシステムクロックを入手しました、そして、時間_アップデートは以前はよく入手していました。
Mills [Page 12] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[12ページ]。
discipline that interface instead. However, the system clock
must still be disciplined as explained previously, so the value
of clock_cpu computed by the second_overflow() fragment is used
instead.
代わりにそのインタフェースを訓練してください。 しかしながら、以前に説明されるようにまだシステムクロックを訓練しなければならないので、2番目の_オーバーフロー()断片によって計算された時計_cpuの値は代わりに使用されます。
3.1.3. The second_overflow() Fragment
3.1.3. 第2_オーバーフロー()断片
The second_overflow() fragment is inserted at the point where
the microseconds field of the system time variable is being
checked for overflow. Upon overflow the maximum error
time_maxerror is increased by time_tolerance to reflect the
maximum time offset due to oscillator frequency error. Then,
the increment time_adj to advance the kernel time variable is
calculated from the (scaled) time_offset and time_freq
variables updated at the last call to the hardclock() fragment.
2番目の_オーバーフロー()断片はシステム時間変数のマイクロセカンド分野がオーバーフローがないかどうかチェックされているポイントで挿入されます。 オーバーフローのときに、最大の誤り時間_maxerrorは時間_寛容によって増加させられて、振動子頻度誤りのため相殺された最大の時間を反映します。 そして、カーネル時間変数を進める増分の時間_adjは_が相殺して、時間_freq変数が最後の呼び出しのときにhardclock()断片にアップデートした(スケーリングされる)の時間から計算されます。
The phase adjustment is calculated as a (signed) fraction of
the time_offset remaining, where the fraction is added to
time_adj, then subtracted from time_offset. This technique
provides a rapid convergence when offsets are high, together
with good resolution when offsets are low. The frequency
adjustment is the sum of the (scaled) time_freq variable, an
adjustment necessary when the tick interval does not evenly
divide one second fixtick and PPS frequency adjustment pps_ybar
(if configured).
次に、断片が時間_adjに加えられるところで時間_から引き算されていたままで残っている時間_オフセットの(サインされます)部分が相殺されたので、相調整は計算されます。 オフセットがオフセットが低く良い解決と共に高いときに、このテクニックは急速な集合を提供します。 頻度調整は(スケーリングされる)の時間_freq変数(カチカチする音間隔が均等に2分の1つのfixtickとPPS頻度調整pps_ybarを分割しないと(構成されるなら)必要な調整)の合計です。
The scheme of approximating exact multiply/divide operations
with shifts produces good results, except when an exact
calculation is required, such as when the PPS signal is being
used to discipling the CPU clock oscillator frequency, as
described below. As long as the actual oscillator frequency is
a power of two in seconds, no correction is required. However,
in the SunOS kernel the clock frequency is 100 Hz, which
results in an error factor of 0.78. In this case the code
increases time_adj by a factor of 1.25, which results in an
overall error less than three percent.
近似の計画が強要する、シフトによる操作が正確な計算が必要である時以外のPPS信号が修業に使用されて、CPUは振動子頻度の時間を計ります、説明されるようにことである時などの良い結果を生む/分水嶺を掛けてください。 実際の振動子頻度が秒の2のパワーである限り、修正は全く必要ではありません。 しかしながら、SunOSカーネルでは、クロック周波数は100Hzです。(そのHzは0.78に関する誤り要因をもたらします)。 この場合、コードは1.25の要素で時間_adjを増加させます。(それは、3パーセント未満の総合誤差をもたらします)。
On rollover of the day, the leap-second state machine described
below determines whether a second is to be inserted or deleted
in the timescale. The microtime() routine insures that the
reported time is always monotonically increasing.
1日のロールオーバーでは、以下で説明された閏秒州のマシンは、1秒がスケールで挿入されるか、または削除されるかことであることを決定します。 microtime()ルーチンは、報告された時間が単調にいつも増加しているのを保障します。
3.1.4. The hardpps() Fragment
3.1.4. hardpps()断片
The hardpps() fragment is operative only if the PPS_SYNC option
is specified in the kernel configuration file. It is called
from the serial port driver or equivalent interface at the on-
time transition of the PPS signal. The fragment operates as a
PPS_SYNCオプションがカーネル構成ファイルで指定される場合にだけ、hardpps()断片は影響を及ぼしています。 それはPPSの時間変遷が示すオンにシリアルポートドライバーか同等なインタフェースから呼ばれます。 断片はaとして作動します。
Mills [Page 13] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[13ページ]。
first-order, type-I frequency-lock loop (FLL) controlled by the
difference between the frequency represented by the pps_ybar
variable and the frequency of the hardware clock oscillator.
一次です、私をタイプしている頻度ロック輪(FLL)はpps_ybar変数によって表された頻度とハードウェアクロック発振器の頻度の違いによって制御されました。
In order to avoid calling the microtime() routine more than
once for each PPS transition, the interface requires the
calling program to capture the system time and hardware counter
contents at the on-time transition of the PPS signal and
provide a pointer to the timestamp (Unix timeval) and counter
contents as arguments to the hardpps() call. The hardware
counter contents can be determined by saving the microseconds
field of the system time, calling the microtime() routine, and
subtracting the saved value. If a counter overflow has occured
during the process, the resulting microseconds value will be
negative, in which case the caller adds 1000000 to normalize
the microseconds field.
それぞれのPPS変遷のためにmicrotime()ルーチンが一度より多いと言うのを避けて、インタフェースは、PPS信号の定刻の変遷のときにシステム時間とハードウェアカウンタコンテンツを得て、hardpps()への議論が呼ぶようにタイムスタンプ(unix timeval)とカウンタコンテンツにポインタを提供するために呼ぶプログラムを必要とします。 ハードウェアカウンタコンテンツはシステム現代のマイクロセカンド分野を節約することによって、決定できます、microtime()ルーチンを呼んで、救われた値を引き算して。 カウンタオーバーフローが過程の間、occuredされているなら、マイクロセカンドが評価する結果になることが否定的になる、その場合、訪問者はマイクロセカンド分野を正常にするために1000000を加えます。
The frequency of the hardware oscillator can be determined from
the difference in hardware counter readings at the beginning
and end of the calibration interval divided by the duration of
the interval. However, the oscillator frequency tolerance, as
much as 100 ppm, may cause the difference to exceed the tick
value, creating an ambiguity. In order to avoid this ambiguity,
the hardware counter value at the beginning of the interval is
increased by the current pps_ybar value once each second, but
computed modulo the tick value. At the end of the interval, the
difference between this value and the value computed from the
hardware counter is used as a control signal sample for the
FLL.
ハードウェアカウンタ読書の違いから間隔の持続時間が割られた較正間隔の首尾でハードウェア振動子の頻度を測定できます。 しかしながら、振動子周波数公差(最大100ppm)で、違いはカチカチする音値を超えるかもしれません、あいまいさを作成して。 このあいまいさを避けるために、間隔の始めにおけるハードウェア対価は現在のpps_ybar値によって1秒に一度増加させられて、計算された唯一の法はカチカチする音値です。 間隔の終わりに、ハードウェアカウンタから計算されたこの値と値の違いはFLLにコントロール信号のサンプルとして使用されます。
Control signal samples which exceed the frequency tolerance are
discarded, as well as samples resulting from excessive interval
duration jitter. Surviving samples are then processed by a
three-stage median filter. The signal which drives the FLL is
derived from the median sample, while the average of
differences between the other two samples is used as a measure
of dispersion. If the dispersion is below the threshold
pps_dispmax, the median is used to correct the pps_ybar value
with a weight expressed as a shift PPS_AVG (2). In addition to
the averaging function, pps_disp is increased by the amount
pps_dispinc once each second. The result is that, should the
dispersion be exceptionally high, or if the PPS signal fails
for some reason, the pps_disp will eventually exceed
pps_dispmax and raise an alarm.
周波数公差を超えているコントロール信号のサンプルが過度の間隔持続時間ジターから生じるサンプルと同様に捨てられます。 そして、生き残っているサンプルは3ステージのメジアンフィルターによって処理されます。 中央のサンプルからFLLを運転する信号を得ます、他の2個のサンプルの違いの平均は分散の基準として使用されますが。 分散が敷居pps_dispmaxの下にあるなら、メディアンは、重りがシフトPPS_AVG(2)として表されている状態でpps_ybar値を修正するのに使用されます。 平均に加えて、量のpps_dispincは機能、pps_dispを1秒に一度増加させます。 結果は分散が例外的に高いはずであるか、またはPPS信号がある理由で失敗すると、pps_dispが結局、pps_dispmaxを超えて、警報を発するということです。
Initially, an approximate value for pps_ybar is not known, so
the duration of the calibration interval must be kept small to
avoid overflowing the tick. The time difference at the end of
初めはpps_ybarのための近似値が知られていないので、カチカチする音からはみ出すのを避けるために小さく較正間隔の持続時間を保たなければなりません。 終わりの時差
Mills [Page 14] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[14ページ]。
the calibration interval is measured. If greater than a
fraction tick/4, the interval is reduced by half. If less than
this fraction for four successive calibration intervals, the
interval is doubled. This design automatically adapts to
nominal jitter in the PPS signal, as well as the value of tick.
The duration of the calibration interval is set by the
pps_shift variable as a shift in powers of two. The minimum
value PPS_SHIFT (2) is chosen so that with the highest CPU
oscillator frequency 1024 Hz and frequency tolerance 100 ppm
the tick will not overflow. The maximum value PPS_SHIFTMAX (8)
is chosen such that the maximum averaging time is about 1000 s
as determined by measurements of Allan variance [5].
較正間隔は測定されます。 断片カチカチする音/4より大きいなら、間隔は半減します。 間隔が4回の連続した較正間隔の間のこの断片ほど倍にされないなら。 このデザインは自動的にPPS信号における名目上のジター、およびカチカチする音の値に順応します。 較正間隔の持続時間はpps_シフトで2人の強国におけるシフトとして可変な状態で設定されます。 最小値PPS_SHIFT(2)が選ばれているので、1024Hzの振動子頻度とカチカチする音がそうする100ppmの周波数公差は最も高いCPUであふれません。 最大値PPS_SHIFTMAX(8)が選ばれているので、時間を平均する最大はアラン変化[5]の測定値で決定するように1000秒間に関するものです。
Should the PPS signal fail, the current frequency estimate
pps_ybar continues to be used, so the nominal frequency remains
correct subject only to the instability of the undisciplined
oscillator. The procedure to save and restore the frequency
estimate works as follows. When setting the frequency from a
file, the time_freq value is set as the file value minus the
pps_ybar value; when retrieving the frequency, the two values
are added before saving in the file. This scheme provides a
seamless interface should the PPS signal fail or the kernel
configuration change. Note that the frequency discipline is
active whether or not the synchronization daemon is active.
Since all Unix systems take some time after reboot to build a
running system, usually by that time the discipline process has
already settled down and the initial transients due to
frequency discipline have damped out.
PPSが合図するなら、失敗してください、公称周波数が未熟な振動子の不安定性だけのままで正しい対象のままで残るpps_ybarが、使用され続けているという現在の頻度見積り。 頻度見積りを保存して、復元する手順は以下の通り利きます。 ファイルから頻度を設定するとき、時間_freq値はファイル値としてpps_ybar値を引いて設定されます。 頻度を検索するとき、2つの値がファイルで節約する前に、加えられます。 PPS信号が失敗するはずであるなら計画が継ぎ目のないインタフェースを提供するこれかカーネル構成変更。 同期デーモンがアクティブであるか否かに関係なく、頻度規律がアクティブであることに注意してください。 すべてのUnixシステムにいつか似ているので、通常過程が既に沈めた規律と頻度規律による初期の過渡現象が弱めたその時までにリブートして、走行システムを構築してください。
3.1.4. External Clock Interface
3.1.4. 外部クロックインタフェース
The external clock driver interface is implemented with two
routines, microtime(), which returns the current clock time,
and clock_set(), which furnishes the apparent system time
derived from the kernel time variable. The latter routine is
called only when the clock is set using the settimeofday()
system call, but can be called from within the driver, such as
when the year rolls over, for example.
外部クロックドライバーインタフェースは2つのルーチンとmicrotime()と時計_セット()で実行されます。(microtime()は現在のクロック・タイムを返します)。(それは、カーネル時間変数から引き出された見かけのシステム時間を提供します)。 例えば、時計が1年がひっくり返る時などのドライバーから呼ぶことができるのを除いて、settimeofday()システムコールを使用するように設定されるときだけ、後者のルーチンは呼ばれます。
In the stock SunOS kernel and modified Ultrix and OSF/1
kernels, the microtime() routine returns the kernel time
variable plus an interpolation between timer interrupts based
on the contents of a hardware counter. In the case of an
external clock, such as described above, the system clock is
read directly from the hardware clock registers. Examples of
external clock drivers are in the tprotime.c and hightime.c
routines included in the kernel.tar.Z distribution.
変更されたストックSunOSカーネル、Ultrix、およびOSF/1カーネルでは、microtime()ルーチンはハードウェアカウンタのコンテンツに基づくタイマ割込みの間にカーネル時間変数と挿入を返します。 上で説明されるような外部クロックの場合では、システムクロックは直接ハードウェア時計レジスタから読まれます。 kernel.tar.Z分配にルーチンを含んでいて、外部クロックドライバーの例がtprotime.cとhightime.cにあります。
Mills [Page 15] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[15ページ]。
The external clock routines return a status code which
indicates whether the clock is operating correctly and the
nature of the problem, if not. The return code is interpreted
by the ntp_gettime() system call, which transitions the status
state machine to the TIME_ERR state if an error code is
returned. This is the only error checking implemented for the
external clock in the present version of the code.
外部クロックルーチンは時計が正しく作動しているかどうかを示すステータスコードと問題の性格を返します、そうでなければ。 復帰コードは解釈されて、ntp_gettime()システムコールで、エラーコードであるならタイム誌_ERR状態への状態州のマシンを返すということです。(システムコールは移行します)。 これはコードの現在のバージョンの外部クロックのために実装された唯一の誤りの照合です。
The simulator has been used to check the PLL operation over the
design envelope of +-512 ms in time error and +-100 ppm in
frequency error. This confirms that no overflows occur and that
the loop initially converges in about 15 minutes for timer
interrupt rates from 50 Hz to 1024 Hz. The loop has a normal
overshoot of a few percent and a final convergence time of several
hours, depending on the initial time and frequency error.
シミュレータは、時間誤りにおける+-512msと頻度誤りにおける+-100ppmのデザイン封筒の上のPLL操作をチェックするのに使用されました。 これはオーバーフローが全く起こらないで、輪がタイマ中断率のためのおよそ15分後に初めは50Hzから1024Hzまで一点に集まると確認します。 標準は輪で数時間の数パーセントと最後の集合時間を飛び越えさせます、初回と頻度誤りによって。
3.2. Leap Seconds
3.2. 飛躍秒
It does not seem generally useful in the user application
interface to provide additional details private to the kernel and
synchronization protocol, such as stratum, reference identifier,
reference timestamp and so forth. It would in principle be
possible for the application to independently evaluate the quality
of time and project into the future how long this time might be
"valid." However, to do that properly would duplicate the
functionality of the synchronization protocol and require
knowledge of many mundane details of the platform architecture,
such as the subnet configuration, reachability status and related
variables. For the curious, the ntp_adjtime() system call can be
used to reveal some of these mysteries.
カーネルと同期プロトコルに個人的な追加詳細を明らかにするのはユーザアプリケーション・インターフェースで一般に、役に立つように思えません、層、参照識別子、参照タイムスタンプなどなどのように。 アプリケーションが独自に時間の品質を評価して、今回どれくらい長い間未来に突出するかが、「有効であること」は、原則として可能でしょう。 しかしながら、そんなに適切にするのは同期プロトコルの機能性をコピーして、プラットホームアーキテクチャの多くの世俗の瑣事に関する知識を必要とするでしょう、サブネット構成や、可到達性状態や関連変数などのように。 好奇心の強さに関しては、これらの神秘のいくつかを明らかにするのにntp_adjtime()システムコールを使用できます。
However, the user application may need to know whether a leap
second is scheduled, since this might affect interval calculations
spanning the event. A leap-warning condition is determined by the
synchronization protocol (if remotely synchronized), by the
timecode receiver (if available), or by the operator (if awake).
This condition is set by the synchronization daemon on the day the
leap second is to occur (30 June or 31 December, as announced) by
specifying in a ntp_adjtime() system call a clock status of either
TIME_DEL, if a second is to be deleted, or TIME_INS, if a second
is to be inserted. Note that, on all occasions since the inception
of the leap-second scheme, there has never been a deletion
occasion, nor is there likely to be one in future. If the value is
TIME_DEL, the kernel adds one second to the system time
immediately following second 23:59:58 and resets the clock status
to TIME_OK. If the value is TIME_INS, the kernel subtracts one
second from the system time immediately following second 23:59:59
and resets the clock status to TIME_OOP, in effect causing system
しかしながら、ユーザアプリケーションは、閏秒が予定されているかどうかを知る必要があるかもしれません、これがイベントにかかる間隔計算に影響するかもしれないので。 飛躍警告状態は、同期プロトコル(離れて連動するなら)、timecode受信機(利用可能であるなら)、またはオペレータで断固としているのと(目覚める。)です。 閏秒がntp_adjtime()システムコールで_タイム誌DEL、1秒が削除されるかどうかことであるまたは_タイム誌INSの時計状態を指定することによって起こることになっている(発表されるとしての6月30日か12月31日)日にこの状態は同期デーモンでオンなセットです、1秒が挿入されることであるなら。 どんな時にも、閏秒体系の始まり以来、削除時が一度もありません、そして、それに注意してください、そして、これから、1つはおそらくないでしょう。 値がタイム誌_DELであるなら、カーネルは、すぐに2番目の23:59:58に続くシステム時間に1つ秒を加えて、タイム誌_OKに時計状態をリセットします。 値がタイム誌_INSであるなら、カーネルは、すぐに2番目の23:59:59に続くシステム時間から1つ秒を引き算して、タイム誌_OOPに時計状態をリセットします、事実上、システムを引き起こして
Mills [Page 16] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[16ページ]。
time to repeat second 59. Immediately following the repeated
second, the kernel resets the clock status to TIME_OK.
2番目の59を繰り返す時間。 すぐに繰り返された2番目に続いて、カーネルはタイム誌_OKに時計状態をリセットします。
Depending upon the system call implementation, the reported time
during a leap second may repeat (with the TIME_OOP return code set
to advertise that fact) or be monotonically adjusted until system
time "catches up" to reported time. With the latter scheme the
reported time will be correct before and shortly after the leap
second (depending on the number of microtime() calls during the
leap second), but freeze or slowly advance during the leap second
itself. However, Most programs will probably use the ctime()
library routine to convert from timeval (seconds, microseconds)
format to tm format (seconds, minutes,...). If this routine is
modified to use the ntp_gettime() system call and inspect the
return code, it could simply report the leap second as second 60.
よって、システムコール実装、閏秒の間の報告された時に、単調にシステムまで調整されて、時間が報告されるのに「追いつく」という時間は、繰り返すか(その事実の広告を出すように設定されたタイム誌_OOP復帰コードで)、またはあるかもしれません。 後者の体系によって、報告された時間は閏秒の前と閏秒のすぐ後に正しいでしょう(microtime()の数に依存するのは閏秒の間、呼びます)、凍るか、または閏秒自体の間、ゆっくり進むのを除いて。 しかしながら、Mostプログラムは、timeval(秒、マイクロセカンド)形式からtm形式(秒、数分、…)まで変換するのにたぶんctime()ライブラリ・ルーチンを使用するでしょう。 このルーチンがntp_gettime()システムコールを使用して、復帰コードを点検するように変更されるなら、それは2番目の60として単に閏秒を報告するかもしれません。
3.3. Clock Status State Machine
3.3. 時計状態州のマシン
The various options possible with the system clock model described
in this memorandum require a careful examination of the state
transitions, status indications and recovery procedures should a
crucial signal or interface fail. In this section is presented a
prototype state machine designed to support leap second insertion
and deletion, as well as reveal various kinds of errors in the
synchronization process. The states of this machine are decoded as
follows:
重要な信号かインタフェースが失敗するなら、可能なこのメモで説明されているシステムクロックモデルで様々なオプションは状態遷移、状態指摘、およびリカバリ手順の慎重な調査を必要とします。 このセクションでは、閏秒が挿入と削除であるとサポートして、同期プロセスで様々な種類の誤りを明らかにするように設計されたプロトタイプ州のマシンは示されます。 このマシンの州は以下の通り解読されます:
TIME_OK If an external clock is present, it is working properly
and the system clock is derived from it. If no external
clock is present, the synchronization daemon is working
properly and the system clock is synchronized to a radio
clock or one or more peers.
タイム誌_はIfを承認します。外部クロックは存在しています、そして、適切に働いています、そして、それからシステムクロックを得ます。 どんな外部クロックも存在していないなら、同期デーモンは適切に働いています、そして、システムクロックはラジオ時計か1人以上の同輩に連動します。
TIME_INS An insertion of one second in the system clock has been
declared following the last second of the current day,
but has not yet been executed.
1秒のシステムクロックへのタイム誌_INS An挿入は、現在の日の最後の秒に次のである宣言されましたが、まだ実行されていません。
TIME_DEL A deletion of the last second of the current day has
been declared, but not yet executed.
現在の日の最後の2番目のタイム誌_DEL A削除は、宣言されますが、まだ実行されていません。
TIME_OOP An insertion of one second in the system clock has been
declared following the last second of the current day.
The second is in progress, but not yet completed.
Library conversion routines should interpret this second
as 23:59:60.
1秒のシステムクロックへのタイム誌_OOP An挿入は現在の日の最後の秒に次のである宣言されました。 2番目は、進行中にはありますが、まだ完成していません。 図書館変換ルーチンはこの秒に23:59:60を解釈するべきです。
Mills [Page 17] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[17ページ]。
TIME_BAD Either (a) the synchronization daemon has declared the
protocol is not working properly, (b) all sources of
outside synchronization have been lost or (c) an
external clock is present and it has just become
operational following a non-operational condition.
外部クロックは存在しています、そして、同期デーモンがプロトコルであると宣言したタイム誌_BAD Either(a)が適切に働いていないか、(b) 外の同期のすべての源がなくされたか、または非稼動状況に続いて、(c) それはちょうど操作上になったところです。
TIME_ERR An external clock is present, but is in a non-
operational condition.
タイム誌_ERR An外部クロックは、存在していますが、非稼動状況にはあります。
In all except the TIME_ERR state the system clock is derived from
either an external clock, if present, or the kernel time variable,
if not. In the TIME_ERR state the external clock is present, but
not working properly, so the system clock may be derived from the
kernel time variable. The following diagram indicates the normal
transitions of the state machine. Not all valid transitions are
shown.
タイム誌_ERR状態を除いて、システムクロックが、全部で、外部クロックから派生していて、存在しているか、またはカーネル時間は可変です、そうでなければ。 したがって、外部クロックが適切に提示しますが、扱っていないタイム誌_ERR状態では、カーネル時間変数からシステムクロックを得るかもしれません。 以下のダイヤグラムは州のマシンの通常の変遷を示します。 すべての有効な変遷が示されるというわけではありません。
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
|TIME_BAD|---->|TIME_OK |<----|TIME_OOP|<----|TIME_INS|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
A A
| |
| |
+--------+ +--------+
| | | |
|TIME_ERR| |TIME_DEL|
| | | |
+--------+ +--------+
+--------+ +--------+ +--------+ +--------+ | | | | | | | | |タイム誌_悪いです。|、-、-、--、>|時間_OK| <、-、-、--、|時間_OOP| <、-、-、--、|時間_インス| | | | | | | | | +--------+ +--------+ +--------+ +--------+ A| | | | +--------+ +--------+ | | | | |時間_は間違えます。| |時間_デル| | | | | +--------+ +--------+
The state machine makes a transition once each second at an
instant where the microseconds field of the kernel time variable
overflows and one second is added to the seconds field. However,
this condition is checked at each timer interrupt, which may not
exactly coincide with the actual instant of overflow. This may
lead to some interesting anomalies, such as a status indication of
a leap second in progress (TIME_OOP) when actually the leap second
had already expired.
州のマシンはカーネルの時間の可変オーバーフローと1秒のマイクロセカンド分野が秒分野に加えられるところで瞬間の秒に一度変遷をします。 しかしながら、この状態はそれぞれのタイマ割込みのときにチェックされます。(まさに、それは、オーバーフローの実際の瞬間と同時に起こらないかもしれません)。 これはいくつかのおもしろい例外に通じるかもしれません、実際に閏秒が既に期限が切れたときの進行中の閏秒(タイム誌_OOP)の状態しるしのように。
The following state transitions are executed automatically by the
kernel:
以下の状態遷移はカーネルによって自動的に実行されます:
any state -> TIME_ERR This transition occurs when an external
clock is present and an attempt is made to
read it when in a non-operational
condition.
非稼動状況にあるとき、外部クロックが存在していて、それを読むのを試みをするとき、どんな州の->タイム誌_ERR This変遷も起こります。
Mills [Page 18] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[18ページ]。
TIME_INS -> TIME_OOP This transition occurs immediately
following second 86,400 of the current day
when an insert-second event has been
declared.
タイム誌_インス->タイム誌_OOP This変遷は差し込み-第2のイベントが宣言された第2すぐに次の現在の8万6400日に起こります。
TIME_OOP -> TIME_OK This transition occurs immediately
following second 86,401 of the current
day; that is, one second after entry to
the TIME_OOP state.
すぐに第2現在の8万6401日に続いて、タイム誌_OOP->タイム誌_OK This変遷は起こります。 すなわち、タイム誌_OOP状態へのエントリーの1秒後に。
TIME_DEL -> TIME_OK This transition occurs immediately
following second 86,399 of the current day
when a delete-second event has been
declared.
タイム誌_デル->タイム誌_OK This変遷は2番目を削除しているイベントが宣言された第2すぐに次の現在の8万6399日に起こります。
The following state transitions are executed by specific
ntp_adjtime() system calls:
以下の状態遷移は特定のntp_adjtime()システムコールで実行されます:
TIME_OK -> TIME_INS This transition occurs as the result of a
ntp_adjtime() system call to declare an
insert-second event.
タイム誌_OK->タイム誌_INS This変遷は、差し込み-第2のイベントを宣言するためにntp_adjtime()システムコールの結果として起こります。
TIME_OK -> TIME_DEL This transition occurs as the result of a
ntp_adjtime() system call to declare a
delete-second event.
タイム誌_OK->タイム誌_DEL This変遷は、2番目を削除しているイベントを宣言するためにntp_adjtime()システムコールの結果として起こります。
any state -> TIME_BAD This transition occurs as the result of a
ntp_adjtime() system call to declare loss
of all sources of synchronization or in
other cases of error.
どんな州の->タイム誌_BAD This変遷も、同期のすべての源の損失を宣言するか、または誤りの他の場合で起こるようにntp_adjtime()システムコールの結果として起こります。
The following table summarizes the actions just before, during and
just after a leap-second event. Each line in the table shows the
UTC and NTP times at the beginning of the second. The left column
shows the behavior when no leap event is to occur. In the middle
column the state machine is in TIME_INS at the end of UTC second
23:59:59 and the NTP time has just reached 400. The NTP time is
set back one second to 399 and the machine enters TIME_OOP. At the
end of the repeated second the machine enters TIME_OK and the UTC
and NTP times are again in correspondence. In the right column the
state machine is in TIME_DEL at the end of UTC second 23:59:58 and
the NTP time has just reached 399. The NTP time is incremented,
the machine enters TIME_OK and both UTC and NTP times are again in
correspondence.
以下のテーブルはすぐイベントの前、およびイベントと閏秒イベントのすぐ後に動作をまとめます。 テーブルの各系列は2番目の始めにUTCとNTPに回を示しています。 左のコラムは、飛躍イベントが全くいつ起こることになっていないかを振舞いに示します。 中くらいのコラムには、州のマシンがUTC2番目の23:59:59の終わりにタイム誌_INSにあります、そして、NTP時間はちょうど400に達したところです。 NTP時間は399に次いでいる2番目の1つに遅らせられます、そして、マシンはタイム誌_OOPを入れます。 繰り返された2番目の終わりに、マシンはタイム誌_OKとUTCに入ります、そして、再び通信にはNTP回があります。 正しいコラムには、州のマシンがUTC2番目の23:59:58の終わりにタイム誌_DELにあります、そして、NTP時間はちょうど399に達したところです。 NTP時間は増加されています、そして、マシンはタイム誌_OKに入ります、そして、再び通信にはUTCとNTP回の両方があります。
Mills [Page 19] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[19ページ]。
No Leap Leap Insert Leap Delete
UTC NTP UTC NTP UTC NTP
---------------------------------------------
23:59:58|398 23:59:58|398 23:59:58|398
| | |
23:59:59|399 23:59:59|399 00:00:00|400
| | |
00:00:00|400 23:59:60|399 00:00:01|401
| | |
00:00:01|401 00:00:00|400 00:00:02|402
| | |
00:00:02|402 00:00:01|401 00:00:03|403
| | |
どんな飛躍飛躍差し込み飛躍もUTC NTP UTC NTP UTC NTPを削除しません。--------------------------------------------- 23:59:58|398 23:59:58|398 23:59:58|398 | | | 23:59:59|399 23:59:59|399 00:00:00|400 | | | 00:00:00|400 23:59:60|399 00:00:01|401 | | | 00:00:01|401 00:00:00|400 00:00:02|402 | | | 00:00:02|402 00:00:01|401 00:00:03|403 | | |
To determine local midnight without fuss, the kernel code simply
finds the residue of the time.tv_sec (or time.tv_sec + 1) value
mod 86,400, but this requires a messy divide. Probably a better
way to do this is to initialize an auxiliary counter in the
settimeofday() routine using an ugly divide and increment the
counter at the same time the time.tv_sec is incremented in the
timer interrupt routine. For future embellishment.
大騒ぎなしで地方の真夜中を決定するために、カーネルコードは単にtime.tv_秒(または、time.tv_秒+1)の価値モッズ風の86,400の残りを見つけますが、これは乱雑な分水嶺を必要とします。 たぶん、これをするより良い方法は、settimeofday()ルーチンで醜い分水嶺を使用することで補助のカウンタを初期化して、time.tv_秒がタイマ割り込みルーチンで増加される同時代にカウンタを増加することです。 今後の潤色のために。
4. Programming Model and Interfaces
4. プログラミングモデルとインタフェース
This section describes the programming model for the synchronization daemon and user application programs. The ideas are based on suggestions from Jeff Mogul and Philip Gladstone and a similar interface designed by the latter. It is important to point out that the functionality of the original Unix adjtime() system call is preserved, so that the modified kernel will work as the unmodified one, should the new features not be in use. In this case the ntp_adjtime() system call can still be used to read and write kernel variables that might be used by a synchronization daemon other than NTP, for example.
このセクションは同期デーモンとユーザアプリケーション・プログラムのためにプログラミングモデルについて説明します。考えは後者によって設計されたジェフ・ムガール人、フィリップGladstone、および同様のインタフェースからの提案に基づいています。 オリジナルのUnix adjtime()システムコールの機能性が保存されると指摘するのは重要です、変更されたカーネルが変更されていないものとして働くように、新機能が使用中でないなら。 この場合、例えば、NTP以外の同期デーモンによって使用されるかもしれないカーネル変数を読み書きするのにまだntp_adjtime()システムコールを使用できます。
4.1. The ntp_gettime() System Call
4.1. ntp_gettime()システムCall
The syntax and semantics of the ntp_gettime() call are given in
the following fragment of the timex.h header file. This file is
identical, except for the SHIFT_HZ define, in the SunOS, Ultrix
and OSF/1 kernel distributions. (The SHIFT_HZ define represents
the logarithm to the base 2 of the clock oscillator frequency
specific to each system type.) Note that the timex.h file calls
the syscall.h system header file, which must be modified to define
the SYS_ntp_gettime system call specific to each system type. The
kernel distributions include directions on how to do this.
timex.hヘッダーファイルの以下の断片でntp_gettime()呼び出しの構文と意味論を与えます。 このファイルが同じである、SHIFT_を除いて、HZはSunOS、Ultrix、およびOSF/1カーネルで配を定義します。 (HZが定義するSHIFT_はそれぞれのシステムタイプに、特定の2つのクロック発振器頻度のベースに対数を表します。) timex.hファイルがsyscall.hシステムヘッダーファイルを呼ぶことに注意してください。(それぞれのシステムタイプに、特定のSYS_ntp_gettimeシステムコールを定義するようにファイルを変更しなければなりません)。 カーネル配はどうこれをするかに関する方向を含んでいます。
Mills [Page 20] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[20ページ]。
/*
* This header file defines the Network Time Protocol (NTP)
* interfaces for user and daemon application programs. These are
* implemented using private system calls and data structures and
* require specific kernel support.
*
* NAME
* ntp_gettime - NTP user application interface
*
* SYNOPSIS
* #include <sys/timex.h>
*
* int system call(SYS_ntp_gettime, tptr)
*
* int SYS_ntp_gettime defined in syscall.h header file
* struct ntptimeval *tptr pointer to ntptimeval structure
*
* NTP user interface - used to read kernel clock values
* Note: maximum error = NTP synch distance = dispersion + delay /
* 2
* estimated error = NTP dispersion.
*/
struct ntptimeval {
struct timeval time; /* current time */
long maxerror; /* maximum error (us) */
long esterror; /* estimated error (us) */
};
このヘッダーがファイルする/**はユーザとデーモンアプリケーション・プログラムのためにNetwork Timeプロトコル(NTP)*インタフェースを定義します。これらは個人的なシステムコールを使用することで実装された*です、そして、データ構造と*は特定のカーネルサポートを必要とします。 * * NTPユーザアプリケーション・インターフェース**SYNOPSIS*#がntp_gettimeがsyscall.hヘッダーファイル*struct ntptimeval*tptr指針でntptimeval構造**NTPユーザーインタフェースと定義した<sys/timex.h>**intシステムコール(SYS_ntp_gettime、tptr)**int SYS_を含んでいるというNAME*ntp_gettimeは以前はよくカーネル時計値*注意を読んでいました: 誤りであると見積もられていた分散+遅れ/*2NTP同時性最大の誤り=距離=*はNTP分散と等しいです。 */struct ntptimeval*struct timeval時間; /*現在の時間*/長いmaxerror; /*最大の誤り(私たち)の*/長いesterror;/およその誤り(私たち)*/。
The ntp_gettime() system call returns three values in the
ntptimeval structure: the current time in unix timeval format plus
the maximum and estimated errors in microseconds. While the 32-bit
long data type limits the error quantities to something more than
an hour, in practice this is not significant, since the protocol
itself will declare an unsynchronized condition well below that
limit. In the NTP Version 3 specification, if the protocol
computes either of these values in excess of 16 seconds, they are
clamped to that value and the system clock declared
unsynchronized.
ntp_gettime()システムコールはntptimeval構造で3つの値を返します: unix timeval形式における現在の時間とマイクロセカンドの最大の、そして、およその誤り。 32ビットの長いデータ型は1時間以上誤り量を何かに制限しますが、実際には、これは重要ではありません、プロトコル自体がその限界の下で非連動している状態をよく宣言するので。 NTPバージョン3仕様では、プロトコルが16秒を超えてこれらの値のどちらかを計算するなら、それらは非連動していると申告されたその値とシステムクロックに固定されます。
Following is a detailed description of the ntptimeval structure
members.
以下に、ntptimeval構造メンバーの詳述があります。
Mills [Page 21] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[21ページ]。
struct timeval time; /* current time */
struct timeval時間。 /*現在の時間*/
This member returns the current system time, expressed as a
Unix timeval structure. The timeval structure consists of two
32-bit words; the first returns the number of seconds past 1
January 1970, while the second returns the number of
microseconds.
このメンバーはUnix timeval構造として言い表された現在のシステム時間を返します。 timeval構造は2つの32ビットの単語から成ります。 1番目は1970年1月1日を過ぎて秒数を返しますが、秒はマイクロセカンドの数を返します。
long maxerror; /* maximum error (us) */
長いmaxerror。 /*最大の誤り(私たち)*/
This member returns the time_maxerror kernel variable in
microseconds. See the entry for this variable in section 5 for
additional information.
このメンバーはマイクロセカンドのときに時間_maxerrorカーネル変数を返します。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long esterror; /* estimated error (us) */
長いesterror。 誤り(私たち)*/であると見積もられていた/*
This member returns the time_esterror kernel variable in
microseconds. See the entry for this variable in section 5 for
additional information.
このメンバーはマイクロセカンドのときに時間_esterrorカーネル変数を返します。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
Mills [Page 22] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[22ページ]。
4.2. The ntp_adjtime() System Call
4.2. ntp_adjtime()システムCall
The syntax and semantics of the ntp_adjtime() call are given in
the following fragment of the timex.h header file. Note that, as
in the ntp_gettime() system call, the syscall.h system header file
must be modified to define the SYS_ntp_adjtime system call
specific to each system type.
timex.hヘッダーファイルの以下の断片でntp_adjtime()呼び出しの構文と意味論を与えます。 それぞれのシステムタイプに、特定のSYS_ntp_adjtimeシステムコールを定義するようにntp_gettime()システムコールのようにsyscall.hシステムヘッダーファイルを変更しなければならないことに注意してください。
/*
* NAME
* ntp_adjtime - NTP daemon application interface
*
* SYNOPSIS
* #include <sys/timex.h>
*
* int system call(SYS_ntp_adjtime, mode, tptr)
*
* int SYS_ntp_adjtime defined in syscall.h header file
* struct timex *tptr pointer to timex structure
*
* NTP daemon interface - used to discipline kernel clock
* oscillator
*/
struct timex {
int mode; /* mode selector */
long offset; /* time offset (us) */
long frequency; /* frequency offset (scaled ppm) */
long maxerror; /* maximum error (us) */
long esterror; /* estimated error (us) */
int status; /* clock command/status */
long time_constant; /* pll time constant */
long precision; /* clock precision (us) (read only)
*/
long tolerance; /* clock frequency tolerance (scaled
* ppm) (read only) */
/*
* The following read-only structure members are implemented
* only if the PPS signal discipline is configured in the
* kernel.
*/
long ybar; /* frequency estimate (scaled ppm) */
long disp; /* dispersion estimate (scaled ppm)
*/
int shift; /* interval duration (s) (shift) */
long calcnt; /* calibration intervals */
long jitcnt; /* jitter limit exceeded */
long discnt; /* dispersion limit exceeded */
};
NTPデーモンアプリケーション・インターフェース**SYNOPSIS*#がntp_adjtimeがsyscall.hヘッダーファイル*struct timex*tptr指針でtimex構造**NTPデーモンインタフェースと定義した<sys/timex.h>**intシステムコール(SYS_ntp_adjtime、モード、tptr)**int SYS_を含んでいるという/**NAME*ntp_adjtimeは以前はよくカーネル時計*振動子*/struct timexを訓練していました。{ intモード。 /*モード選択器*/長いオフセット。 /*時間は*/長い頻度を相殺しました(私たち)。 /*頻度は*/長いmaxerrorを相殺しました(ppmをスケーリングします)。 /*最大の誤り(私たち)*/長いesterror。 誤り(私たち)*/int状態であると見積もられていた/*。 /*はコマンド/状態*/長い時間_定数の時間を計ります。 /*位相ロックループ時定数*/長い精度。 /*時計精度(私たち)(書き込み禁止)*/長い寛容。 *PPSが規律に合図する場合にだけ、以下の書き込み禁止構造メンバーが実装される/*クロック周波数寛容(スケーリングされた*ppm)(書き込み禁止)*//**は*カーネルで構成されます。 */長いybar。 /*頻度は、(スケーリングされたppm)が*/長いdispであると見積もっています。 /*分散は、(スケーリングされたppm)が*/intシフトであると見積もっています。 /*間隔持続時間(シフト)*/長いcalcnt。 /*較正間隔*/長いjitcnt。 /*ジター限界は*/長いdiscntを超えていました。 /*分散限界は*/を超えていました。};
Mills [Page 23] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[23ページ]。
The ntp_adjtime() system call is used to read and write certain
time-related kernel variables summarized in this and subsequent
sections. Writing these variables can only be done in superuser
mode. To write a variable, the mode structure member is set with
one or more bits, one of which is assigned each of the following
variables in turn. The current values for all variables are
returned in any case; therefore, a mode argument of zero means to
return these values without changing anything.
ntp_adjtime()システムコールは、これにまとめられたある時間関連のカーネル変数とその後のセクションを読み書きするのに使用されます。 「スーパー-ユーザ」モードでこれらの変数を書くことができるだけです。 変数を書くために、モード構造メンバーは1ビット以上で用意ができています。それぞれの以下の変数は順番にその1つに割り当てられます。 どのような場合でも、すべての変数のための現行価値は返されます。 したがって、ゼロのモード議論は、何も変えないでこれらの値を返すことを意味します。
Following is a description of the timex structure members.
以下に、timex構造メンバーの記述があります。
int mode; /* mode selector */
intモード。 /*モード選択器*/
This is a bit-coded variable selecting one or more structure
members, with one bit assigned each member. If a bit is set,
the value of the associated member variable is copied to the
corresponding kernel variable; if not, the member is ignored.
The bits are assigned as given in the following fragment of the
timex.h header file. Note that the precision and tolerance are
determined by the kernel and cannot be changed by
ntp_adjtime().
これは1ビットが各メンバーに割り当てられている1人以上の構造メンバーを選ぶ少しコード化された変数です。 しばらくが決められるなら、関連メンバー変数の値は対応するカーネル変数にコピーされます。 そうでなければ、メンバーは無視されます。 ビットはtimex.hヘッダーファイルの以下の断片で与えるように割り当てられます。 精度と寛容をカーネルで測定して、ntp_adjtime()が変えることができないことに注意してください。
/*
* Mode codes (timex.mode)
*/
#define ADJ_OFFSET 0x0001 /* time offset */
#define ADJ_FREQUENCY 0x0002 /* frequency offset */
#define ADJ_MAXERROR 0x0004 /* maximum time error */
#define ADJ_ESTERROR 0x0008 /* estimated time error */
#define ADJ_STATUS 0x0010 /* clock status */
#define ADJ_TIMECONST 0x0020 /* pll time constant */
/**モードが*/#、が定義する(timex.mode)をコード化する、オフセット*/#がADJ_FREQUENCY0×0002/*頻度オフセット*/#を定義するADJ_OFFSET0×0001/*時間が時間誤り*/#、が定義する誤り*/#、がADJ_ESTERROR0×0008/*を定義する最大の時が、見積もっていたADJ_MAXERROR0x0004/*を定義する、ADJ_STATUS0×0010/*時計状態*/#はADJ_TIMECONST0×0020/*位相ロックループ時定数*/を定義します。
long offset; /* time offset (us) */
長い間、相殺してください。 /*時間は*/を相殺しました(私たち)。
If selected, this member replaces the value of the time_offset
kernel variable in microseconds. The absolute value must be
less than MAXPHASE microseconds defined in the timex.h header
file. See the entry for this variable in section 5 for
additional information.
選択されるなら、このメンバーはマイクロセカンドの時間_オフセットカーネル変数の値を取り替えます。 絶対値はtimex.hヘッダーファイルで定義されたMAXPHASEマイクロセカンドより少ないに違いありません。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
If within range and the PPS signal and/or external oscillator
are configured and operating properly, the clock status is
automatically set to TIME_OK.
中で及んでください。そうすれば、PPSが合図するか、そして、そして/または、外部発振器は構成されています、そして、適切に作動して、時計状態は自動的にタイム誌_OKへのセットです。
Mills [Page 24] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[24ページ]。
long time_constant; /* pll time constant */
長い時間_定数。 /*位相ロックループ時定数*/
If selected, this member replaces the value of the
time_constant kernel variable. The value must be between zero
and MAXTC defined in the timex.h header file. See the entry for
this variable in section 5 for additional information.
選択されるなら、このメンバーは時間の_の一定のカーネル変数の値を取り替えます。 timex.hヘッダーファイルで定義されたゼロとMAXTCの間には、値があるに違いありません。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long frequency; /* frequency offset (scaled ppm) */
長い頻度。 /*頻度は*/を相殺しました(ppmをスケーリングします)。
If selected, this member replaces the value of the
time_frequency kernel variable. The value is in ppm, with the
integer part in the high order 16 bits and fraction in the low
order 16 bits. The absolute value must be in the range less
than MAXFREQ ppm defined in the timex.h header file. See the
entry for this variable in section 5 for additional
information.
選択されるなら、このメンバーは時間_頻度カーネル変数の値を取り替えます。 値がppmにあります、16ビットと安値における断片が16ビット命令する高位における整数部で。 絶対値がtimex.hヘッダーファイルで定義されたMAXFREQ ppmほど範囲にないに違いありません。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long maxerror; /* maximum error (us) */
長いmaxerror。 /*最大の誤り(私たち)*/
If selected, this member replaces the value of the
time_maxerror kernel variable in microseconds. See the entry
for this variable in section 5 for additional information.
選択されるなら、このメンバーはマイクロセカンドの時間_maxerrorカーネル変数の値を取り替えます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long esterror; /* estimated error (us) */
長いesterror。 誤り(私たち)*/であると見積もられていた/*
If selected, this member replaces the value of the
time_esterror kernel variable in microseconds. See the entry
for this variable in section 5 for additional information.
選択されるなら、このメンバーはマイクロセカンドの時間_esterrorカーネル変数の値を取り替えます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
int status; /* clock command/status */
int状態。 /*時計コマンド/状態*/
If selected, this member replaces the value of the time_status
kernel variable. See the entry for this variable in section 5
for additional information.
選択されるなら、このメンバーは時間_状態カーネル変数の値を取り替えます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
In order to set this variable by ntp_adjtime(), either (a) the
current clock status must be TIME_OK or (b) the member value is
TIME_BAD; that is, the ntp_adjtime() call can always set the
clock to the unsynchronized state or, if the clock is running
correctly, can set it to any state. In any case, the
ntp_adjtime() call always returns the current state in this
member, so the caller can determine whether or not the request
succeeded.
(b) ntp_adjtime()でこの変数を設定するために、(a) 現在の時計状態は_OKにタイム誌でなければなりませんかメンバー値はタイム誌_BADです。 すなわち、ntp_adjtime()呼び出しは、いつも非連動している状態に時計を設定できるか、または時計が正しく動いているなら、どんな状態にもそれを設定できます。 どのような場合でも、ntp_adjtime()呼び出しがこのメンバーでいつも現状を返すので、訪問者は、要求が成功したかどうかと決心できます。
Mills [Page 25] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[25ページ]。
long time_constant; /* pll time constant */
長い時間_定数。 /*位相ロックループ時定数*/
If selected, this member replaces the value of the
time_constant kernel variable. The value must be between zero
and MAXTC defined in the timex.h header file. See the entry for
this variable in section 5 for additional information.
選択されるなら、このメンバーは時間の_の一定のカーネル変数の値を取り替えます。 timex.hヘッダーファイルで定義されたゼロとMAXTCの間には、値があるに違いありません。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long precision; /* clock precision (us) (read only) */
長い精度。 /*時計精度(私たち)(書き込み禁止)*/
This member returns the time_precision kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときに時間_精度カーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long tolerance; /* clock frequency tolerance (scaled ppm)
*/
長い寛容。 /*クロック周波数寛容(スケーリングされたppm)*/
This member returns the time_tolerance kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときに時間_寛容カーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long ybar; /* frequency estimate (scaled ppm) */
長いybar。 /*頻度は、(スケーリングされたppm)が*/であると見積もっています。
This member returns the pps_ybar kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_ybarカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long disp; /* dispersion estimate (scaled ppm) */
長いdisp。 /*分散は、(スケーリングされたppm)が*/であると見積もっています。
This member returns the pps_disp kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_dispカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
int shift; /* interval duration (s) (shift) */
intシフト。 /*間隔持続時間(シフト)*/
This member returns the pps_shift kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_シフトカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
Mills [Page 26] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[26ページ]。
long calcnt; /* calibration intervals */
長いcalcnt。 /*較正間隔*/
This member returns the pps_calcnt kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_calcntカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long jitcnt; /* jitter limit exceeded */
長いjitcnt。 /*ジター限界は*/を超えていました。
This member returns the pps_jittcnt kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_jittcntカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
long discnt; /* dispersion limit exceeded */
長いdiscnt。 /*分散限界は*/を超えていました。
This member returns the pps_discnt kernel variable in
microseconds. The variable can be written only by the kernel.
See the entry for this variable in section 5 for additional
information.
このメンバーはマイクロセカンドのときにpps_discntカーネル変数を返します。 カーネルだけで変数を書くことができます。 追加情報に関してこの変数のためのセクション5のエントリーを見てください。
Mills [Page 27] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[27ページ]。
4.3. Command/Status Codes
4.3. コマンド/ステータスコード
The kernel routines use the system clock status variable
time_status, which records whether the clock is synchronized,
waiting for a leap second, etc. The value of this variable is
returned as the result code by both the ntp_gettime() and
ntp_adjtime() system calls. In addition, it can be explicitly read
and written using the ntp_adjtime() system call, but can be
written only in superuser mode. Values presently defined in the
timex.h header file are as follows:
カーネルルーチンはシステムクロックの状態の可変時間_状態を使用します、閏秒などを待っていて。(その状態は、時計が連動するかどうか記録します)。 結果コードとしてntp_gettime()とntp_adjtime()システムコールの両方でこの変数の値を返します。 さらに、それをntp_adjtime()システムコールを使用することで明らかに読み書きできますが、単に「スーパー-ユーザ」モードで書くことができます。 現在timex.hヘッダーファイルで定義されている値は以下の通りです:
/*
* Clock command/status codes (timex.status)
*/
#define TIME_OK 0 /* clock synchronized */
#define TIME_INS 1 /* insert leap second */
#define TIME_DEL 2 /* delete leap second */
#define TIME_OOP 3 /* leap second in progress */
#define TIME_BAD 4 /* kernel clock not synchronized */
#define TIME_ERR 5 /* external oscillator not
synchronized */
時計..コマンド..ステータスコード..定義..タイム誌..OK..時計..連動..定義..タイム誌..差し込み..飛躍..定義..タイム誌..削除..跳ねる..定義..タイム誌..閏秒..進歩..定義..タイム誌..カーネル..時計..連動..定義..タイム誌..外部..振動子..連動
A detailed description of these codes as used by the leap-second
state machine is given later in this memorandum. In case of a
negative result code, the kernel has intercepted an invalid
address or (in case of the ntp_adjtime() system call), a superuser
violation.
後でこのメモで閏秒状態のそばで同じくらい中古のこれらのコードの詳述マシンを与えます。 または、否定的結果コードの場合にカーネルが無効のアドレスを傍受した、(ntp_adjtime()システムコールの場合の)、「スーパー-ユーザ」違反。
5. Kernel Variables
5. カーネル変数
This section contains a list of kernel variables and a detailed description of their function, initial value, scaling and limits.
このセクションはカーネル変数のリストとそれらの機能、初期の値、スケーリング、および限界の詳述を含みます。
5.1. Interface Variables
5.1. インタフェース変数
The following variables are read and set by the ntp_adjtime()
system call. Additional automatic variables are used as
temporaries as described in the code fragments.
以下の変数は、ntp_adjtime()システムコールで読まれて、設定されます。 コードで説明されるtemporariesが断片化するとき、追加自動的変数は使用されています。
int time_status = TIME_BAD;
int時間_状態はタイム誌_BADと等しいです。
This variable controls the state machine used to insert or
delete leap seconds and show the status of the timekeeping
system, PPS signal and external oscillator, if configured.
この変数は飛躍秒を挿入するか、または削除して、時間保持システムの状態、PPS信号を見せているのにおいて中古の州のマシンと外部発振器を制御します、構成されるなら。
Mills [Page 28] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[28ページ]。
long time_offset = 0;
長い時間_は=0を相殺しました。
This variable is used by the PLL to adjust the system time in
small increments. It is scaled by (1 << SHIFT_UPDATE) (12) in
microseconds. The maximum value that can be represented is
about +-512 ms and the minimum value or precision is a few
parts in 10^10 s.
この変数はPLLによって使用されて、わずかな増分でシステム時間を調整します。 それはマイクロセカンドのときに(1<<SHIFT_UPDATE)(12)によってスケーリングされます。 表すことができる最大値は+-512msに関するものです、そして、10^10秒間で最小値か精度がいくつかの部品です。
long time_constant = 0; /* pll time constant */
長い時間_一定の=0。 /*位相ロックループ時定数*/
This variable determines the bandwidth or "stiffness" of the
PLL. The value is used as a shift between zero and MAXTC (6),
with the effective PLL time constant equal to a multiple of (1
<< time_constant) in seconds. For room-temperature quartz
oscillator the recommended default value is 2, which
corresponds to a PLL time constant of about 900 s and a maximum
update interval of about 64 s. The maximum update interval
scales directly with the time constant, so that at the maximum
time constant of 6, the update interval can be as large as 1024
s.
この変数はPLLの帯域幅か「堅さ」を決定します。 値はゼロとMAXTC(6)の間のシフトとして使用されます、秒の(1つの<<時間_定数)の倍数と等しい有効なPLL時定数で。 室温水晶振動子に関して、お勧めのデフォルト値が2である、(PLL時定数に対応しています)900秒間と最大のアップデート間隔、64秒間に関して。 最大のアップデート間隔は直接時定数で比例します、6の最大の時定数では、アップデート間隔が1024秒間と同じくらい大きいように。
Values of time_constant between zero and 2 can be used if quick
convergence is necessary; values between 2 and 6 can be used to
reduce network load, but at a modest cost in accuracy. Values
above 6 are appropriate only if an external oscillator is
present.
迅速な集合が必要であるなら、ゼロと2の間の時間_定数の値を使用できます。 値は、ネットワーク負荷を減少させるのに2と6の間使用できますが、精度における穏やかな費用に使用できます。 外部発振器が存在している場合にだけ、6を超えた値は適切です。
long time_tolerance = MAXFREQ; /* frequency tolerance (ppm) */
長い時間_寛容はMAXFREQと等しいです。 /*周波数公差(ppm)*/
This variable represents the maximum frequency error or
tolerance in ppm of the particular CPU clock oscillator and is
a property of the architecture; however, in principle it could
change as result of the presence of external discipline
signals, for instance. It is expressed as a positive number
greater than zero in parts-per-million (ppm).
この変数は、特定のCPUクロック発振器のppmに最大の頻度誤りか寛容を表して、構造の特性です。 しかしながら、原則として、例えば、外部の規律の存在の結果が合図するようにそれは変化できました。 それはゼロ以上の正の数として100万あたりの部品(ppm)で言い表されます。
The recommended value of MAXFREQ is 200 ppm is appropriate for
room-temperature quartz oscillators used in typical
workstations. However, it can change due to the operating
condition of the PPS signal and/or external oscillator. With
either the PPS signal or external oscillator, the recommended
value for MAXFREQ is 100 ppm.
MAXFREQの推奨値は典型的なワークステーションで使用される室温水晶振動子に、200ppmが適切であるということです。 しかしながら、それはPPS信号、そして/または、外部発振器に関する運転条件のため変化できます。 PPS信号か外部発振器で、MAXFREQのための推奨値は100ppmです。
Mills [Page 29] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[29ページ]。
long time_precision = 1000000 / HZ; /* clock precision (us) */
長い時間_精度は1000000 / HZと等しいです。 /*時計精度(私たち)*/
This variable represents the maximum error in reading the
system clock in microseconds. It is usually based on the number
of microseconds between timer interrupts, 10000 us for the
SunOS kernel, 3906 us for the Ultrix kernel, 976 us for the
OSF/1 kernel. However, in cases where the time can be
interpolated between timer interrupts with microsecond
resolution, such as in the unmodified SunOS kernel and modified
Ultrix and OSF/1 kernels, the precision is specified as 1 us.
In cases where a PPS signal or external oscillator is
available, the precision can depend on the operating condition
of the signal or oscillator. This variable is determined by the
kernel for use by the synchronization daemon, but is otherwise
not used by the kernel.
この変数はマイクロセカンドのときにシステムクロックを読む際に最大の誤りを表します。 それがそうである、SunOSカーネル、3906年の通常タイマ割込み、10000の間のマイクロセカンドの数に基づいている私たち、Ultrixカーネルのための私たち、976 OSF/1カーネルのための私たち。 しかしながら、タイマ割込みの間でマイクロセカンド解決で時間を補間できる場合では、変更されていないSunOSカーネルや、変更されたUltrixやOSF/1つのカーネルなどのような精度は1として指定されます。私たち。 PPS信号か外部発振器が利用可能である場合では、精度は信号か振動子に関する運転条件に依存できます。 この変数は、同期デーモンによる使用のためにカーネルで決定しますが、別の方法でカーネルによって使用されません。
long time_maxerror = MAXPHASE; /* maximum error */
長い時間_maxerrorはMAXPHASEと等しいです。 /*最大の誤り*/
This variable establishes the maximum error of the indicated
time relative to the primary synchronization source in
microseconds. For NTP, the value is initialized by a
ntp_adjtime() call to the synchronization distance, which is
equal to the root dispersion plus one-half the root delay. It
is increased by a small amount (time_tolerance) each second to
reflect the clock frequency tolerance. This variable is
computed by the synchronization daemon and the kernel, but is
otherwise not used by the kernel.
この変数はマイクロセカンドの主要な同期源に比例して示された現代の最大の誤りを確立します。 NTPに関しては、値は同期距離へのntp_adjtime()呼び出しで初期化されます。(それは、根の遅れが根の分散と半分と等しいことです)。 それは、それぞれの秒にクロック周波数寛容を反映するために少量(時間_寛容)で増加します。 この変数は、同期デーモンとカーネルによって計算されますが、別の方法でカーネルによって使用されません。
long time_esterror = MAXPHASE; /* estimated error */
長い時間_esterrorはMAXPHASEと等しいです。 誤り*/であると見積もられていた/*
This variable establishes the expected error of the indicated
time relative to the primary synchronization source in
microseconds. For NTP, the value is determined as the root
dispersion, which represents the best estimate of the actual
error of the system clock based on its past behavior, together
with observations of multiple clocks within the peer group.
This variable is computed by the synchronization daemon and
returned in system calls, but is otherwise not used by the
kernel.
この変数はマイクロセカンドの主要な同期源に比例して示された現代の期待誤差を確立します。 NTPに関しては、値は根の分散として決定しています、ピアグループの中の複数クロックの観測と共に。(分散は過去の振舞いに基づくシステムクロックの実際の誤りの最高の見積もりを表します)。 この変数を同期デーモンが計算して、システムコールで返しますが、別の方法でカーネルで使用しません。
Mills [Page 30] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[30ページ]。
5.2. Phase-Lock Loop Variables
5.2. フェーズ・ロックループ変数
The following variables establish the state of the PLL and the
residual time and frequency offset of the system clock. Additional
automatic variables are used as temporaries as described in the
code fragments.
以下の変数はシステムクロックのPLLの状態、残りの時間、および頻度オフセットを確立します。 コードで説明されるtemporariesが断片化するとき、追加自動的変数は使用されています。
long time_phase = 0; /* phase offset (scaled us) */
長い時間_フェーズ=0。 /*フェーズオフセット(私たちをスケーリングする)*/
The time_phase variable represents the phase of the kernel time
variable at each tick of the clock. This variable is scaled by
(1 << SHIFT_SCALE) (23) in microseconds, giving a maximum
adjustment of about +-256 us/tick and a resolution less than
one part in 10^12.
時間_フェーズ変数は時計の各カチカチする音にカーネル時間変数のフェーズを表します。 この変数がおよそ-+256の最大の調整に私たちを与えるマイクロセカンドの(1<<SHIFT_SCALE)(23)によってスケーリングされるか、またはカチカチすることであり、解決は一部10^12で以下です。
long time_offset = 0; /* time offset (scaled us) */
長い時間_は=0を相殺しました。 /*時間は*/を相殺しました(私たちをスケーリングします)。
The time_offset variable represents the time offset of the CPU
clock oscillator. It is recalculated as each update to the
system clock is received via the hardupdate() routine and at
each second in the seconds_overflow routine. This variable is
scaled by (1 << SHIFT_UPDATE) (12) in microseconds, giving a
maximum adjustment of about +-512 ms and a resolution of a few
parts in 10^10 s.
時間_オフセット変数はCPUクロック発振器の時間オフセットを表します。 それはhardupdate()ルーチンを通して各2番目でシステムクロックへの各アップデートを受けるように秒_オーバーフロールーチンで再計算されます。 この変数はマイクロセカンドのときに(1<<SHIFT_UPDATE)(12)によってスケーリングされます、10^10秒間でいくつかの部品のmsと解決をおよそ-+512の最大の調整に与えて。
long time_freq = 0; /* frequency offset (scaled ppm) */
長い時間_freq=0。 /*頻度は*/を相殺しました(ppmをスケーリングします)。
The time_freq variable represents the frequency offset of the
CPU clock oscillator. It is recalculated as each update to the
system clock is received via the hardupdate() routine. It can
also be set via ntp_adjtime() from a value stored in a file
when the synchronization daemon is first started. It can be
retrieved via ntp_adjtime() and written to the file about once
per hour by the daemon. The time_freq variable is scaled by (1
<< SHIFT_KF) (16) ppm, giving it a maximum value well in excess
of the limit of +-256 ppm imposed by other constraints. The
precision of this representation (frequency resolution) is
parts in 10^11, which is adequate for all but the best external
oscillators.
時間_freq変数はCPUクロック発振器の頻度オフセットを表します。 それはhardupdate()ルーチンでシステムクロックへの各アップデートを受けるように再計算されます。 また、同期デーモンが最初に始められるときファイルに格納された値からのntp_adjtime()を通してそれを設定できます。 デーモンはそれをntp_adjtime()を通して検索して、1時間単位でファイルにおよそ一度書くことができます。 時間_freq変数は(1<<SHIFT_KF)(16)ppmスケーリングされます、他の規制で課された+-256ppmの限界を超えて最大値をそれによく与えて。 この表現(周波数分解能)の精度は10^11で部品です。(最も良い外部発振器以外のすべてに、11は適切です)。
time_adj = 0; /* tick adjust (scaled 1 / HZ) */
時間_adj=0。 /*ダニは*/を調整します(1/HZをスケーリングします)。
The time_adj variable is the adjustment added to the value of
tick at each timer interrupt. It is computed once each second
from the time_offset, time_freq and, if the PPS signal is
present, the ps_ybar variable once each second.
時間_adj変数はそれぞれのタイマ割込みのときにカチカチする音の値に加えられた調整です。 それはそれぞれの秒の時間_オフセットと時間_freqと1秒に一度可変なps_ybarからのPPS信号が存在しているなら一度計算されます。
Mills [Page 31] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[31ページ]。
long time_reftime = 0; /* time at last adjustment (s) */
長い時間_reftime=0。 最後の調整*/の/*時間
This variable is the seconds portion of the system time on the
last update received by the hardupdate() routine. It is used to
compute the time_freq variable as the time since the last
update increases.
この変数はアップデートのシステム現代の部分がhardupdate()ルーチンで得た秒です。 それは、アップデートが増加するので時間として時間_freq変数を計算するのに使用されます。
int fixtick = 1000000 % HZ; /* amortization factor */
int fixtickは1000000%のHZと等しいです。 /*配賦率*/
In the Ultrix and OSF/1 kernels, the interval between timer
interrupts does not evenly divide the number of microseconds in
the second. In order that the clock runs at a precise rate, it
is necessary to introduce an amortization factor into the local
timescale. In the original Unix code, the value of fixtick is
amortized once each second, introducing an additional source of
jitter; in the new model the value is amortized at each tick of
the system clock, reducing the jitter by the reciprocal of the
clock oscillator frequency. This is not a new kernel variable,
but a new use of an existing kernel variable.
UltrixとOSF/1カーネルでは、タイマ割込みの間隔は均等に2番目のマイクロセカンドの数を割りません。 時計が正確なレートで動くように、地方のスケールに配賦率を取り入れるのが必要です。 元のUnixコードでは、ジターの追加源を紹介して、fixtickの値は1秒に一度清算されます。 新しいモデルでは、値はシステムクロックの各カチカチする音で清算されます、クロック発振器頻度の逆数でジターを減少させて。 これは新しいカーネル変数ではなく、既存のカーネル変数が新用途です。
5.3. Pulse-per-second (PPS) Frequency-Lock Loop Variables
5.3. 1秒あたりのパルス(PPS)頻度ロックループ変数
The following variables are used only if a pulse-per-second (PPS)
signal is available and connected via a modem-control lead, such
as produced by the optional ppsclock feature incorporated in the
serial port driver. They establish the design parameters of the
PPS frequency-lock loop used to discipline the CPU clock
oscillator to an external PPS signal. Additional automatic
variables are used as temporaries as described in the code
fragments.
1秒あたりのパルス(PPS)信号がモデム制御リードで利用可能であって、接続されている場合にだけ、以下の変数は使用されています、シリアルポートドライバーに組み込んでいる任意のppsclockの特徴によって生産されるように。彼らは外部のPPS信号にCPUクロック発振器を訓練するのに使用されるPPS頻度ロック輪のデザインパラメタを確立します。 コードで説明されるtemporariesが断片化するとき、追加自動的変数は使用されています。
long pps_usec; /* microseconds at last pps */
長いpps_usec。 最後のpps*/の/*マイクロセカンド
The pps_usec variable is latched from a high resolution counter
or external oscillator at each PPS interrupt. In determining
this value, only the hardware counter contents are used, not
the contents plus the kernel time variable, as returned by the
microtime() routine.
pps_usec変数はそれぞれのPPS中断のときに高画質カウンタか外部発振器から掛け金をおろされます。 この値を決定する際に、ハードウェアカウンタ内容だけがコンテンツにカーネル時間変数的ではなく使用されます、microtime()ルーチンで返すように。
long pps_ybar = 0; /* pps frequency offset estimate */
長いpps_ybar=0。 /*pps頻度は見積り*/を相殺しました。
The pps_ybar variable is the average CPU clock oscillator
frequency offset relative to the PPS disciplining signal. It is
scaled in the same units as the time_freq variable.
pps_ybar変数は信号を訓練するPPSに比例して相殺された平均したCPUクロック発振器頻度です。 それは時間_freq変数と同じユニットでスケーリングされます。
Mills [Page 32] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[32ページ]。
pps_disp = MAXFREQ; /* dispersion estimate (scaled ppm) */
pps_dispはMAXFREQと等しいです。 /*分散は、(スケーリングされたppm)が*/であると見積もっています。
The pps_disp variable represents the average sample dispersion
measured over the last three samples. It is scaled in the same
units as the time_freq variable.
pps_disp変数は最後の3個のサンプルの上に測定された標準見本分散を表します。 それは時間_freq変数と同じユニットでスケーリングされます。
pps_dispmax = MAXFREQ / 2; /* dispersion threshold */
pps_dispmaxはMAXFREQ / 2と等しいです。 /*分散敷居*/
The pps_dispmax variable is used as a dispersion threshold. If
pps_disp is less than this threshold, the median sample is used
to update the pps_ybar estimate; if not, the sample is
discarded.
pps_dispmax変数は分散敷居として使用されます。 pps_dispがこの敷居以下であるなら、中央のサンプルはpps_ybar見積りをアップデートするのに使用されます。 そうでなければ、サンプルは捨てられます。
pps_dispinc = MAXFREQ >> (PPS_SHIFT + 4); /* pps dispersion
increment/sec */
pps_dispincはMAXFREQ>>(PPS_SHIFT+4)と等しいです。 /*pps分散増分/秒の*/
The pps_dispinc variable is the increment to add to pps_disp
once each second. It is computed such that, if no PPS samples
have arrived for several calibration intervals, the value of
pps_disp will exceed the pps_dispmax threshold and raise an
alarm.
pps_dispinc変数は1秒に一度pps_dispに加える増分です。 それは、PPSのサンプルが全くいくつかの較正間隔の間、届いていないと、pps_dispの値がpps_dispmax敷居を超えて、警報を発するように、計算されます。
int pps_mf[] = {0, 0, 0}; /* pps median filter */
0、0、int pps_mf[]=0。 /*ppsメジアンフィルター*/
The pps-mf[] array is used as a median filter to detect and
discard jitter in the PPS signal.
pps mf[]アレイは、PPS信号におけるジターを検出して、捨てるのにメジアンフィルターとして使用されます。
int pps_count = 0; /* pps calibrate interval counter */
int pps_カウント=0。 /*ppsは間隔カウンタ*/を較正します。
The pps_count variable measures the length of the calibration
interval used to calculate the frequency. It normally counts
from zero to the value 1 << pps_shift.
pps_カウント変数は頻度について計算するために費やされた較正間隔の長さを測定します。 通常、それはゼロ〜値まで1つの<<pps_シフトを数えます。
pps_shift = PPS_SHIFT; /* interval duration (s) (shift) */
pps_シフトはPPS_SHIFTと等しいです。 /*間隔持続時間(シフト)*/
The pps_shift variable determines the duration of the
calibration interval, 1 << pps_shift s.
pps_シフト変数は較正間隔の持続時間、1つの<<pps_シフトsを決定します。
pps_intcnt = 0; /* intervals at current duration */
pps_intcnt=0。 現在の持続時間*/の/*間隔
The pps_intcnt variable counts the number of calibration
intervals at the current interval duration. It is reset to zero
after four intervals and when the interval duration is changed.
pps_intcnt変数は現在の間隔持続時間で較正間隔の数を数えます。 それは4回の間隔といつ間隔持続時間を変えたかの後のゼロにリセットされます。
long pps_calcnt = 0; /* calibration intervals */
長いpps_calcnt=0。 /*較正間隔*/
The pps_calcnt variable counts the number of calibration
intervals.
pps_calcnt変数は較正間隔の数を数えます。
Mills [Page 33] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[33ページ]。
long pps_jitcnt = 0; /* jitter limit exceeded */
長いpps_jitcnt=0。 /*ジター限界は*/を超えていました。
The pps_jitcnt variable counts the number of resets due to
excessive jitter or frequency offset. These resets are
usually due to excessive noise in the PPS signal or
interface.
pps_jitcnt変数は過度のジターか頻度オフセットによるリセットの数を数えます。 これらのリセットは通常、PPS信号かインタフェースの過度の雑音のためです。
long pps_discnt = 0; /* dispersion limit exceeded */
長いpps_discnt=0。 /*分散限界は*/を超えていました。
The pps_discnt variable counts the number of calibration
intervals where the dispersion is above the pps_dispmax
limit. These resets are usually due to excessive frequency
wander in the PPS signal source.
pps_discnt変数は分散がpps_dispmax限界を超えている較正間隔の数を数えます。 これらのリセットは通常過度の頻度のためにです。PPS信号ソースを歩き回ってください。
Mills [Page 34] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[34ページ]。
5.4. External Oscillator Variables
5.4. 外部発振器変数
The following variables are used only if an external oscillator
(HIGHBALL or TPRO) is present. Additional automatic variables are
used as temporaries as described in the code fragments.
外部発振器(HIGHBALLかTPRO)が存在している場合にだけ、以下の変数は使用されています。 コードで説明されるtemporariesが断片化するとき、追加自動的変数は使用されています。
int clock_count = 0; /* CPU clock counter */
int時計_カウント=0。 /*CPU時計カウンタ*/
The clock_count variable counts the seconds between adjustments
to the kernel time variable to discipline it to the external
clock.
時計_カウント変数は、外部クロックにそれを訓練するためにカーネル時間変数まで調整の間の秒を数えます。
struct timeval clock_offset; /* HIGHBALL clock offset */
struct timeval時計_は相殺されました。 /*HIGHBALL時計オフセット*/
The clock_offset variable defines the offset between system
time and the HIGHBALL counters.
時計_オフセット変数はシステム時間とHIGHBALLカウンタの間のオフセットを定義します。
long clock_cpu = 0; /* CPU clock adjust */
長い間、_cpu=0の時間を計ってください。 /*CPU時計は*/を調整します。
The clock_cpu variable contains the offset between the system
clock and the HIGHBALL clock for use in disciplining the kernel
time variable.
時計_cpu変数はカーネル時間変数を訓練することにおける使用のためのシステムクロックとHIGHBALL時計の間にオフセットを含んでいます。
6. Architecture Constants
6. 構造定数
Following is a list of the important architecture constants that establish the response and stability of the PLL and provide maximum bounds on behavior in order to satisfy correctness assertions made in the protocol specification. Additional definitions are given in the timex.h header file.
以下に、PLLの応答と安定性を確立して、振舞いのときにプロトコル仕様でされた正当性主張を満たすために最大の領域を提供する重要な構造定数のリストがあります。 timex.hヘッダーファイルで追加定義を与えます。
6.1. Phase-lock loop (PLL) definitions
6.1. フェーズ・ロック輪の(PLL)定義
The following defines establish the performance envelope of the
PLL. They establish the maximum phase error (MAXPHASE), maximum
frequency error (MAXFREQ), minimum interval between updates
(MINSEC) and maximum interval between updates (MAXSEC). The intent
of these bounds is to force the PLL to operate within predefined
limits in order to satisfy correctness assertions of the
synchronization protocol. An excursion which exceeds these bounds
is clamped to the bound and operation proceeds normally. In
practice, this can occur only if something has failed or is
operating out of tolerance, but otherwise the PLL continues to
operate in a stable mode.
以下が定義する、PLLの性能封筒を設立してください。 彼らは最大のフェーズ誤り(MAXPHASE)、最大の頻度誤り(MAXFREQ)、アップデートのアップデート(MINSEC)と最大の間隔の最小間隔(MAXSEC)を確立します。 これらの領域の意図はPLLに同期プロトコルの正当性主張を満たすために中で事前に定義された限界を操作させることです。 これらの領域を超えている遠足はバウンドに固定されます、そして、通常、操作は続きます。 実際には、これは、失敗されて、何かが起こった場合にだけ起こることができるか、または寛容から作動していますが、PLLは、さもなければ、安定したモードで作動し続けています。
MAXPHASE must be set greater than or equal to CLOCK.MAX (128 ms),
as defined in the NTP specification. CLOCK.MAX establishes the
maximum time offset allowed before the system time is reset,
MAXPHASEはNTP仕様に基づき定義されるようにCLOCK.MAX(128ms)をより設定することであるに違いありません。 CLOCK.MAXはシステム時間がリセットされる前に許された最大の時間オフセットを確立します。
Mills [Page 35] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[35ページ]。
rather than incrementally adjusted. Here, the maximum offset is
clamped to MAXPHASE only in order to prevent overflow errors due
to defective programming.
増加して調整されているよりむしろ。 ここで、最大のオフセットは、欠陥があるプログラミングによるオーバーフロー誤りを防ぐためにMAXPHASEだけに固定されます。
MAXFREQ reflects the manufacturing frequency tolerance of the CPU
oscillator plus the maximum slew rate allowed by the protocol. It
should be set to at least the intrinsic frequency tolerance of the
oscillator plus 100 ppm for vernier frequency adjustments. If the
kernel frequency discipline code is installed (PPS_SYNC), the CPU
oscillator frequency is disciplined to an external source,
presumably with negligible frequency error.
MAXFREQはCPU振動子の製造周波数公差とプロトコルによって許容された最大のスルー・レートを反映します。 それはバーニヤ頻度調整のために振動子と100ppmの本質的な周波数公差に設定されるべきです。 カーネル頻度規律コードがインストールされるなら(PPS_SYNC)、CPU振動子頻度は外部電源に訓練されます、おそらく取るにたらない頻度誤りで。
#define MAXPHASE 512000 /* max phase error (us) */
#ifdef PPS_SYNC
#define MAXFREQ 100 /* max frequency error (ppm) */
#else
#define MAXFREQ 200 /* max frequency error (ppm) */
#endif /* PPS_SYNC */
#define MINSEC 16 /* min interval between updates (s)
*/
#define MAXSEC 1200 /* max interval between updates (s)
*/
#*/#ifdef PPS_SYNC#が定義するMAXPHASE512000/*最大フェーズ誤り(私たち)を定義してください、MAXFREQ100/*最大頻度誤り(ppm)*/#ほかの#、が(ppm)*/#endif/*PPS_SYNC*/#がMINSECの16/*分の間隔を定義するアップデート*/#が定義する間のMAXSEC1200/*最大間隔がアップデートするMAXFREQ200/*最大頻度誤りを定義する、(s) */
6.2. Pulse-per-second (PPS) Frequency-lock Loop (FLL) Definitions
6.2. 1秒あたりのパルス(PPS)頻度ロック輪(FLL)の定義
The following defines and declarations are used only if a pulse-
per-second (PPS) signal is available and connected via a modem-
control lead, such as produced by the optional ppsclock feature
incorporated in the serial port driver. They establish the design
parameters of the frequency-lock loop (FLL) used to discipline the
CPU clock oscillator to the PPS oscillator.
パルス2(PPS)番目の信号が利用可能である場合にだけ使用されていて、モデム制御装置で接続されて、導いてください、シリアルポートドライバーに組み込んでいる任意のppsclock特徴によって生産されるように。以下が定義する、そして、彼らがPPS振動子にCPUクロック発振器を訓練するのに使用される頻度ロック輪(FLL)のデザインパラメタを確立するという宣言。
PPS_AVG is the averaging constant used to update the FLL from
frequency samples measured for each calibration interval.
PPS_SHIFT and PPS_SHIFTMAX are the minimum and maximem,
respectively, of the calibration interval represented as a power
of two. The PPS_DISPINC is the initial increment to pps_disp at
each second.
PPS_AVGはそれぞれの較正間隔の間に測定された頻度のサンプルからFLLをアップデートするのに使用される平均した定数です。 PPS_SHIFTとPPS_SHIFTMAXはそれぞれ2のパワーとして表された較正間隔の最小限とmaximemです。 PPS_DISPINCは各2番目のpps_dispへの初期の増分です。
#define PPS_AVG 2 /* pps averaging constant (shift) */
#define PPS_SHIFT 2 /* min interval duration (s) (shift)
*/
#define PPS_SHIFTMAX 6 /* max interval duration (s) (shift)
*/
#define PPS_DISPINC 0 /* dispersion increment (us/s) */
#定義、ppsに一定の(シフト)*/#、を平均するPPS_AVG2/*が持続時間(シフト)*/#、が持続時間(シフト)*/#、がPPS_DISPINC0/*分散増分を定義するPPS_SHIFTMAX6/*最大間隔を定義するPPS_SHIFTの2/*分の間隔を定義する、(私たち、/s)*/
Mills [Page 36] RFC 1589 Kernel Model for Precision Timekeeping March 1994
1994年の時間保持行進のときに精度のためにRFC1589カーネルモデルを製粉します[36ページ]。
6.3. External Oscillator Definitions
6.3. 外部発振器定義
The following definitions and declarations are used only if an
external oscillator (HIGHBALL or TPRO) is configured on the
system.
外部発振器(HIGHBALLかTPRO)がシステムの上で構成される場合にだけ、以下の定義と宣言は使用されています。
#define CLOCK_INTERVAL 30 /* CPU clock update interval (s) */
#CLOCK_INTERVAL30/*CPU時計アップデート間隔*/を定義してください。
7. References
7. 参照
[1] Mills, D., "Internet time synchronization: the Network Time
Protocol", IEEE Trans. Communications COM-39, 10 (October 1991),
1482- 1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global
States and Time in Distributed Systems, IEEE Press, Los Alamitos,
CA, 91-102.
[1] 工場、D.、「インターネット時間同期化:」 「ネットワーク時間プロトコル」、IEEE、移- コミュニケーションCOM-39、10(1991年10月)、1482- 1493。 以下でも 陽、Z.、およびT.A.Marsland(Eds)。 グローバルな州と分散システムにおける時間、IEEEは押して、ロスアラミトス(カリフォルニア)は91-102です。
[2] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, University of Delaware,
March 1992, 113 pp.
[2] 工場(D.)は「Timeプロトコル(バージョン3)仕様、実現、および分析をネットワークでつなぎます」、RFC1305、デラウエア大学、1992年3月、113ページ
[3] Mills, D., "Modelling and analysis of computer network clocks",
Electrical Engineering Department Report 92-5-2, University of
Delaware, May 1992, 29 pp.
[3] 工場、D.、「コンピュータネットワークのモデル化と分析は時間を計ります」、Electrical技術部Report92-5-2、デラウエア大学、1992年5月、29ページ
[4] Mills, D., "Simple Network Time Protocol (SNTP)", RFC 1361,
University of Delaware, August 1992, 10 pp.
[4] 工場、D.、「簡単なネットワーク時間プロトコル(SNTP)」、RFC1361、デラウエア大学、1992年8月、10ページ
[5] Mills, D., "Precision synchronizatin of computer network clocks",
Electrical Engineering Department Report 93-11-1, University of
Delaware, November 1993, 66 pp.
[5] 工場、D.、「コンピュータネットワークの精度synchronizatinは時間を計ります」、Electrical技術部Report93-11-1、デラウエア大学、1993年11月、66ページ
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716
デヴィッドL.はデラウエア大学ニューアーク、電気工学部のDE 19716を製粉します。
Phone: (302) 831-8247 EMail: mills@udel.edu
以下に電話をしてください。 (302) 831-8247 メールしてください: mills@udel.edu
Mills [Page 37]
工場[37ページ]
一覧
スポンサーリンク
