[system-administrators-guide] Updates to Configuring PTP using ptp4l | Style and formatting Using ch- for chapter id: id="ch-Confi

stephenw stephenw at fedoraproject.org
Mon Oct 14 20:42:40 UTC 2013


commit 9c3841a4ec178fef81f05b575453539946fefa90
Author: Stephen Wadeley <swadeley at redhat.com>
Date:   Mon Oct 14 21:25:59 2013 +0200

    Updates to Configuring PTP using ptp4l | Style and formatting
    Using ch- for chapter id: id="ch-Configuring_PTP_using_ptp4l"

 en-US/Configuring_PTP_using_ptp4l.xml |   63 +++++++++++++++++++--------------
 1 files changed, 36 insertions(+), 27 deletions(-)
---
diff --git a/en-US/Configuring_PTP_using_ptp4l.xml b/en-US/Configuring_PTP_using_ptp4l.xml
index 74dddcc..58e1033 100644
--- a/en-US/Configuring_PTP_using_ptp4l.xml
+++ b/en-US/Configuring_PTP_using_ptp4l.xml
@@ -2,22 +2,23 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 ]>
 <!-- Topics, Concepts -->
-<chapter id="Configuring_PTP_using_ptp4l">
+<chapter id="ch-Configuring_PTP_using_ptp4l">
   <title>Configuring PTP using ptp4l</title>
+
   <section id="Introduction_to_PTP">
     <title>Introduction to PTP</title>
     <para>
-      The <firstterm>Precision Time Protocol</firstterm> (<acronym>PTP</acronym>) is a protocol used to synchronize clocks in a network. When used in conjunction with hardware support, <systemitem class="protocol">PTP</systemitem> is capable of sub-microsecond accuracy, which is far better than is normally obtainable with <systemitem class="protocol">NTP</systemitem>. <systemitem class="protocol">PTP</systemitem> support is divided between the kernel and user space. The kernel in Red Hat Enterprise Linux 6 now includes support for <systemitem class="protocol">PTP</systemitem> clocks, which are provided by network drivers. The actual implementation of the protocol is known as <application>linuxptp</application>, a <systemitem class="protocol">PTPv2</systemitem> implementation according to the IEEE standard 1588 for Linux.
+      The <firstterm>Precision Time Protocol</firstterm> (<acronym>PTP</acronym>) is a protocol used to synchronize clocks in a network. When used in conjunction with hardware support, <systemitem class="protocol">PTP</systemitem> is capable of sub-microsecond accuracy, which is far better than is normally obtainable with <systemitem class="protocol">NTP</systemitem>. <systemitem class="protocol">PTP</systemitem> support is divided between the kernel and user space. The kernel in <application>Fedora</application> now includes support for <systemitem class="protocol">PTP</systemitem> clocks, which are provided by network drivers. The actual implementation of the protocol is known as <application>linuxptp</application>, a <systemitem class="protocol">PTPv2</systemitem> implementation according to the IEEE standard 1588 for Linux.
     </para>
     <para>
-      The <package>linuxptp</package> package includes the <application>ptp4l</application> and <application>phc2sys</application> programs for clock synchronization. The <application>ptp4l</application> program implements the <systemitem class="protocol">PTP</systemitem> boundary clock and ordinary clock. With hardware time stamping, it is used to synchronize the <systemitem class="protocol">PTP</systemitem> hardware clock to the master clock, and with software time stamping it synchronizes the system clock to the master clock. The <application>phc2sys</application> program is needed only with hardware time stamping, for synchronizing the system clock to the <systemitem class="protocol">PTP</systemitem> hardware clock on the NIC.
+      The <package>linuxptp</package> package includes the <application>ptp4l</application> and <application>phc2sys</application> programs for clock synchronization. The <application>ptp4l</application> program implements the <systemitem class="protocol">PTP</systemitem> boundary clock and ordinary clock. With hardware time stamping, it is used to synchronize the <systemitem class="protocol">PTP</systemitem> hardware clock to the master clock, and with software time stamping it synchronizes the system clock to the master clock. The <application>phc2sys</application> program is needed only with hardware time stamping, for synchronizing the system clock to the <systemitem class="protocol">PTP</systemitem> hardware clock on the <firstterm>network interface card</firstterm> (<acronym>NIC</acronym>).
     </para>
     <section id="Understanding_PTP">
       <title>Understanding PTP</title>
    <para>
-      The clocks synchronized by <systemitem class="protocol">PTP</systemitem> are organized in a master-slave hierarchy. The slaves are synchronized to their masters which may be slaves to their own masters. The hierarchy is created and updated automatically by the <firstterm>best master clock</firstterm> (<acronym>BMC</acronym>) algorithm, which runs on every clock. When a clock has only one port, it can be <firstterm>master</firstterm> or <firstterm>slave</firstterm>, such a clock is called an <firstterm>ordinary clock</firstterm> (<acronym>OC</acronym>). A clock with multiple ports can be master on one port and slave on another, such clock is called a <firstterm>boundary</firstterm> clock (<acronym>BC</acronym>). The top- level master is called the grandmaster clock, which can be synchronized by <firstterm>Global Positioning System</firstterm> (<acronym>GPS</acronym>). By using a GPS-based time source, disparate networks can be synchronized with a high-degree of accuracy
 .
+     The clocks synchronized by <systemitem class="protocol">PTP</systemitem> are organized in a master-slave hierarchy. The slaves are synchronized to their masters which may be slaves to their own masters. The hierarchy is created and updated automatically by the <firstterm>best master clock</firstterm> (<acronym>BMC</acronym>) algorithm, which runs on every clock. When a clock has only one port, it can be <firstterm>master</firstterm> or <firstterm>slave</firstterm>, such a clock is called an <firstterm>ordinary clock</firstterm> (<acronym>OC</acronym>). A clock with multiple ports can be master on one port and slave on another, such a clock is called a <firstterm>boundary</firstterm> clock (<acronym>BC</acronym>). The top-level master is called the <firstterm>grandmaster clock</firstterm>, which can be synchronized by using a <firstterm>Global Positioning System</firstterm> (<acronym>GPS</acronym>) time source. By using a GPS-based time source, disparate networks can be 
 synchronized with a high-degree of accuracy.
     </para>
-        <figure id="exam-Understanding_PTP">
+    <figure id="exam-Understanding_PTP">
       <title>PTP grandmaster, boundary, and slave clocks</title>
         <mediaobject
         id="mediaobj-ptp_grandmaster_boundary_and_slaves.png">
@@ -34,7 +35,11 @@
   <section id="Advantages_Of_PTP">
     <title>Advantages Of PTP</title>
   <para>
-    One of the main advantages over the <firstterm>Network Time Protocol</firstterm> (<acronym>NTP</acronym>) is hardware support present in various <firstterm>network interface controllers</firstterm> (<acronym>NIC</acronym>) and network switches. This specialized hardware allows <systemitem class="protocol">PTP</systemitem> to account for delays in message transfer, and greatly improves the accuracy of time synchronization. While it is possible to use non-PTP enabled hardware components within the network, this will often cause an increase in jitter or introduce an asymmetry in the delay resulting in synchronization inaccuracies, which add up with multiple non-PTP aware components used in the communication path. To achieve the best possible accuracy, it is recommended that all networking components between <systemitem class="protocol">PTP</systemitem> clocks are <systemitem class="protocol">PTP</systemitem> hardware enabled. Time synchronization in larger networks where no
 t all of the networking hardware supports <systemitem class="protocol">PTP</systemitem> might be better suited for <systemitem class="protocol">NTP</systemitem>. With hardware <systemitem class="protocol">PTP</systemitem> support, the NIC has its own on-board clock, which is used to time stamp the received and transmitted <systemitem class="protocol">PTP</systemitem> messages. It is this on-board clock that is synchronized to the <systemitem class="protocol">PTP</systemitem> master, and the computer's system clock is synchronized to the <systemitem class="protocol">PTP</systemitem> hardware clock on the NIC. With software <systemitem class="protocol">PTP</systemitem> support, the system clock is used to time stamp the <systemitem class="protocol">PTP</systemitem> messages and it is synchronized to the <systemitem class="protocol">PTP</systemitem> master directly. Hardware <systemitem class="protocol">PTP</systemitem> support provides better accuracy since the NIC can time st
 amp the <systemitem class="protocol">PTP</systemitem> packets at the exact moment they are sent and received while software <systemitem class="protocol">PTP</systemitem> support requires additional processing of the <systemitem class="protocol">PTP</systemitem> packets by the operating system.
+    One of the main advantages that <systemitem class="protocol">PTP</systemitem> has over the <firstterm>Network Time Protocol</firstterm> (<acronym>NTP</acronym>) is hardware support present in various <firstterm>network interface controllers</firstterm> (<acronym>NIC</acronym>) and network switches. This specialized hardware allows <systemitem class="protocol">PTP</systemitem> to account for delays in message transfer, and greatly improves the accuracy of time synchronization. While it is possible to use non-PTP enabled hardware components within the network, this will often cause an increase in jitter or introduce an asymmetry in the delay resulting in synchronization inaccuracies, which add up with multiple non-PTP aware components used in the communication path. To achieve the best possible accuracy, it is recommended that all networking components between <systemitem class="protocol">PTP</systemitem> clocks are <systemitem class="protocol">PTP</systemitem> hardware en
 abled. Time synchronization in larger networks where not all of the networking hardware supports <systemitem class="protocol">PTP</systemitem> might be better suited for <systemitem class="protocol">NTP</systemitem>.
+  </para>
+  <para>
+With hardware <systemitem class="protocol">PTP</systemitem> support, the NIC has its own on-board clock, which is used to time stamp the received and transmitted <systemitem class="protocol">PTP</systemitem> messages. It is this on-board clock that is synchronized to the <systemitem class="protocol">PTP</systemitem> master, and the computer's system clock is
+synchronized to the <systemitem class="protocol">PTP</systemitem> hardware clock on the NIC. With software <systemitem class="protocol">PTP</systemitem> support, the system clock is used to time stamp the <systemitem class="protocol">PTP</systemitem> messages and it is synchronized to the <systemitem class="protocol">PTP</systemitem> master directly. Hardware <systemitem class="protocol">PTP</systemitem> support provides better accuracy since the NIC can time stamp the <systemitem class="protocol">PTP</systemitem> packets at the exact moment they are sent and received while software <systemitem class="protocol">PTP</systemitem> support requires additional processing of the <systemitem class="protocol">PTP</systemitem> packets by the operating system.
   </para>
   </section>
 </section>
@@ -90,7 +95,6 @@ Hardware Receive Filter Modes: none
       </listitem>
     </itemizedlist>
   </para>
-
 <para>
 For hardware time stamping support, the parameters list
 should include:
@@ -119,13 +123,12 @@ should include:
       </listitem>
     </itemizedlist>
 </para>
-
 </section>
 
 <section id="Installing_PTP">
   <title>Installing PTP</title>
   <para>
-    The kernel in Red Hat Enterprise Linux 6 now includes support for <systemitem class="protocol">PTP</systemitem>. User space support is provided by the tools in the <application>linuxptp</application> package. To install <application>linuxptp</application>, issue the following command as root:
+    The kernel in <application>Fedora</application> now includes support for <systemitem class="protocol">PTP</systemitem>. User space support is provided by the tools in the <application>linuxptp</application> package. To install <application>linuxptp</application>, issue the following command as root:
     <screen>~]# <command>yum install linuxptp</command></screen>
     This will install <application>ptp4l</application> and <application>phc2sys</application>.
   </para>
@@ -137,7 +140,9 @@ should include:
 <section id="Starting_ptp4l">
   <title>Starting ptp4l</title>
   <para>
-The <application>ptp4l</application> program tries to use hardware time stamping by default. To use <application>ptp4l</application> with hardware time stamping capable drivers and NICs, you must provide the network interface to use with the <option>-i</option> option. Enter the following command as root: <screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -v</command></screen> Where <replaceable>em3</replaceable> is the interface you wish to configure. Below is example output from <application>ptp4l</application> when the <systemitem class="protocol">PTP</systemitem> clock on the NIC is synchronized to a master:
+The <application>ptp4l</application> program tries to use hardware time stamping by default. To use <application>ptp4l</application> with hardware time stamping capable drivers and NICs, you must provide the network interface to use with the <option>-i</option> option. Enter the following command as root:
+<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -v</command></screen>
+Where <replaceable>em3</replaceable> is the interface you wish to configure. Below is example output from <application>ptp4l</application> when the <systemitem class="protocol">PTP</systemitem> clock on the NIC is synchronized to a master:
 <screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -v</command>
 selected em3 as PTP clock
 port 1: INITIALIZING to LISTENING on INITIALIZE
@@ -161,56 +166,60 @@ The <application>ptp4l</application> program can also be started as a service by
 When running as a service, options are specified in the <filename>/etc/sysconfig/ptp4l</filename> file. More information on the different <application>ptp4l</application> options and the configuration file settings can be found in the <filename>ptp4l(8)</filename> man page.
 </para>
 <para>
-By default, messages are sent to <filename>/var/log/messages</filename>. However, specifying the <option>-v</option> option enables logging to standard
-output (useful for debugging purposes.)
+By default, messages are sent to <filename>/var/log/messages</filename>. However, specifying the <option>-v</option> option enables logging to standard output which can be useful for debugging purposes.
   </para>
   <para>
-    To enable software time stamping, the <option>-S</option> option needs to be
-    used as follows:
+    To enable software time stamping, the <option>-S</option> option needs to be used as follows:
     <screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -v -S</command></screen>
   </para>
 
   <section id="Selecting_a_Delay_Mechanism">
-    <title>Selecting a Delay Mechanism</title>
+    <title>Selecting a Delay Measurement Mechanism</title>
     <para>
     There are two different delay measurement mechanisms and they can be selected by means of an option added to the <command>ptp4l</command> command as follows:
     <variablelist>
       <varlistentry>
-        <term><option>-P</option> - peer-to-peer (<acronym>P2P</acronym>) delay measurement mechanism</term>
-         <listitem>
+        <term><option>-P</option></term>
+        <listitem>
+          <para>
+           The <option>-P</option> selects the <firstterm> peer-to-peer</firstterm> (<acronym>P2P</acronym>) delay measurement mechanism.
+          </para>
     <para>
-      The <acronym>P2P</acronym> mechanism is preferred as it reacts to changes in the network topology faster and may be more accurate in measuring the delay, but it must be supported and used by all hardware, including transparent clocks, on the communication path.
+      The <acronym>P2P</acronym> mechanism is preferred as it reacts to changes in the network topology faster, and may be more accurate in measuring the delay, than other mechanisms. The <acronym>P2P</acronym> mechanism can only be used in topologies where each port exchanges <acronym>PTP</acronym> messages with at most one other <acronym>P2P</acronym> port. It must be supported and used by all hardware, including transparent clocks, on the communication path.
     </para>
   </listitem>
       </varlistentry>
       <varlistentry>
-        <term><option>-E</option> - end-to-end (<acronym>E2E</acronym>) delay measurement mechanism. This is the default.</term>
-         <listitem>
+        <term><option>-E</option></term>
+        <listitem>
+          <para>
+            The <option>-E</option> selects the <firstterm>end-to-end</firstterm> (<acronym>E2E</acronym>) delay measurement mechanism. This is the default.
+          </para>
     <para>
       The <acronym>E2E</acronym> mechanism is also referred to as the delay <quote>request-response</quote> mechanism.
     </para>
         </listitem>
 </varlistentry>
     <varlistentry>
-      <term><option>-A</option> - Automatic selection of the delay measurement mechanism.</term>
+      <term><option>-A</option></term>
        <listitem>
+         <para>
+           The <option>-A</option> enables automatic selection of the delay measurement mechanism.
+         </para>
     <para>
       The automatic option starts <application>ptp4l</application> in <acronym>E2E</acronym> mode. It will change to <acronym>P2P</acronym> mode if a peer delay request is received.
     </para>
   </listitem>
   </varlistentry>
     </variablelist>
-
 <note>
   <para>
     All clocks on a single <systemitem class="protocol">PTP</systemitem> communication path must use the same mechanism to measure the delay. A warning will be printed when a peer delay request is received on a port using the <acronym>E2E</acronym> mechanism. A warning will be printed when a <acronym>E2E</acronym> delay request is received on a port using the <acronym>P2P</acronym> mechanism.
   </para>
 </note>
-
 </para>
 </section>
 
-
   </section>
 </section>
 
@@ -313,7 +322,7 @@ if <literal>gmPresent</literal> is true, the <systemitem class="protocol">PTP</s
     Once the <application>phc2sys</application> servo is in a locked state, the clock will not be stepped. This means that the <application>phc2sys</application> program should be started after the <application>ptp4</application> program has synchronized the <systemitem class="protocol">PTP</systemitem> hardware clock.
   </para>
 <para>
-The <application>phc2sys</application> program can be also started as a service by running:
+The <application>phc2sys</application> program can also be started as a service by running:
 <screen>~]# <command>systemctl start phc2sys</command></screen>
 When running as a service, options are specified in the <filename>/etc/sysconfig/phc2sys</filename> file. More information on the different <application>phc2sys</application> options can be found in the <filename>phc2sys(8)</filename> man page.
   </para>
@@ -349,7 +358,8 @@ master  offset     632 s2 adj -28113 path delay 12443
 <section id="Serving_PTP_time_with_NTP">
   <title>Serving PTP time with NTP</title>
   <para>
-    The <systemitem class="daemon">ntpd</systemitem> daemon can be configured to distribute the time from the system clock synchronized by <application>ptp4</application> or <application>phc2sys</application> by using the LOCAL reference clock driver. To prevent <systemitem class="daemon">ntpd</systemitem> from adjusting the system clock, the <filename>ntp.conf</filename> file must not specify any <systemitem class="protocol">NTP</systemitem> servers. The following is a minimal example of <filename>ntp.conf</filename>:<screen>
+    The <systemitem class="daemon">ntpd</systemitem> daemon can be configured to distribute the time from the system clock synchronized by <application>ptp4</application> or <application>phc2sys</application> by using the LOCAL reference clock driver. To prevent <systemitem class="daemon">ntpd</systemitem> from adjusting the system clock, the <filename>ntp.conf</filename> file must not specify any <systemitem class="protocol">NTP</systemitem> servers. The following is a minimal example of <filename>ntp.conf</filename>:
+<screen>
 ~]# <command>cat /etc/ntp.conf</command>
 server   127.127.1.0
 fudge    127.127.1.0 stratum 0</screen>
@@ -361,7 +371,6 @@ fudge    127.127.1.0 stratum 0</screen>
   </note>
 </section>
 
-
 <section id="Serving_NTP_time_with_PTP">
   <title>Serving NTP time with PTP</title>
   <para>


More information about the docs-commits mailing list