Commit 304ec276 authored by Maciej Lipinski's avatar Maciej Lipinski

[doc] Updates/corrections to the PPSi documentation

parent 82c24fc9
......@@ -58,8 +58,11 @@
@top Introduction
PPSi (@sc{ptp} Ported to Silicon) is an application which, in
its basic operation, implements @sc{ieee} 1588-2020 specification in a way
its basic operation, implements @sc{ieee} 1588 specification in a way
that is portable to several architectures, including OS-less ones.
The current version of PPSi is compatible with @sc{ieee} 1588-2008
(@sc{ptp} version 2) and includes a number of optional features specified
in @sc{ieee} 1588-2019 (@sc{ptp} version 2.1).
This manual is mainly aimed at developers: people who are working with
@sc{ptp} and/or White Rabbit and need to use the protocol in their own
......@@ -76,8 +79,9 @@ shortened to @i{WR} in this manual.
WR is a multi-lab research project that aims at synchronizing
thousands of I/O devices distributed in a network several kilometers
wide; its software protocol is an extension of @sc{ptp}. A WR network is
made up of two devices: the @i{WR Switch} and the @i{WR Node}. White
wide; its software protocol is an extension of @sc{ptp}, @sc{wr-ptp}.
A WR network is
made up of two types of devices: the @i{WR Switch} and the @i{WR Node}. White
Rabbit is developed at ohwr.org:
@url{http://www.ohwr.org/project/white-rabbit}.
......@@ -96,7 +100,7 @@ are derived from the @i{PTPd} project, v.2.1.0 (see AUTHORS for details
about copyright); but as of March 2013 very little remains of the original
code base. In addition to the basic feature set we inherited from @i{PTPd},
we support raw Ethernet frames (@t{ETH_P_1588}), according to Annex F of the
specification and support for protocol extensions.
@sc{ieee} 1588 and support for protocol extensions.
We thank Danilo Sabato for fixing the @i{bare} architectures
(see @ref{Architectures}).
......@@ -105,7 +109,7 @@ The home page of the PPSi project and the source repository are:
@indentedblock
@itemize @bullet
@item @url{http://www.ohwr.org/project/ppsi}
@item ssh://git@@ohwr.org:7999/project/ppsi.git;
@item @url{https://ohwr.org/project/ppsi.git};
@end itemize
@end indentedblock
......@@ -170,7 +174,8 @@ The package currently supports the following architectures:
separate architecture, even if the switch itself is a Linux
system running on an ARM processor. The switch is a complex
system, with several daemons cooperating through an IPC
mechanism: the standard main loop for a standalone Unix daemon
and share memory mechanisms: the standard main loop for a
standalone Unix daemon
doesn't apply to the WR switch, and modelling it as a
separate architecture is the simplest and cleanest approach,
in our opinion (even if it leads to some code duplication).
......@@ -179,7 +184,8 @@ The package currently supports the following architectures:
@item wrpc
The @i{White Rabbit PTP Core} architecture is a port of PPSi to
run on our I/O devices. The @i{wrpc} is a ``@i{core}'', i.e. a
run on our I/O devices inside a Field Programmable Gate Array
(FPGA) chip. The @i{wrpc} is a ``@i{core}'', i.e. a
logic block, that runs in WR-capable I/O cards. Most such cards
are developed as open hardware on @i{ohwr.org}; examples are
the @sc{spec} (a PCIe carrier for FMC devices) and the @sc{svec}
......@@ -229,20 +235,30 @@ be tested on the WR switch).
At build time, the user can select the standard protocol (selected by
default by most architectures) or an extension.
The code base only includes one extension, White Rabbit, which is the
default choice when building for one of the WR architectures.
Nothing in PPSi
The code base includes two extensions:
@indentedblock
@itemize @bullet
@item White Rabbit (WR) - specified in "White Rabbit Specification", v2.0:
@url{http://white-rabbit.web.cern.ch/documents/WhiteRabbitSpec.v2.0.pdf},
@item Layer 1 Syntonization (L1Sync) - specified in Annex O of @sc{ieee} 1588-2019.
@end itemize
@end indentedblock
White Rabbit extension is the default choice when building for one of the
WR architectures. Nothing in PPSi
prevents our fellow developers to support their own @i{ptp} extension
using PPSi.
Each extension lives in a subdirectory called @t{proto-ext-}@i{name}.
Source files in that directory may override the implementation for the
standard protocol (which lives in @t{proto-standard}) to provide their
own functionalities. To simplify writing extensions, the @i{proto-standard}
own functionalities. There is also a subdirectory @t{proto-ext-common}
which holds common code for all available extensions.
To simplify writing extensions, the @i{proto-standard}
functions already provide @i{hooks} so the extension itself can provide
callbacks while still using the basic @sc{ptp} engine.
The set of callbacks is currently based on the needs of
WR, but we are willing to accept patches to provide more hooks as
WR and L1Sync, but we are willing to accept patches to provide more hooks as
needed.
If you plan to write your own protocol extension within PPSi, please
......@@ -258,7 +274,7 @@ easily port the daemon to your own timing primitives.
The subdirectories named @i{time-xxxx} are used to implement timing
functions; timing includes the methods that are part of two data
structures: @i{pp_time_operations} and @i{pp_network_operations}. The
former structure deals with getting and setting system time, while the
former structure deals with getting and setting system/WR time, while the
latter deals with frame tx and rx. Network operations are concerned
with timestamping the actual I/O, and that's why they are considered
part of the ``timing'' of PPSi.
......@@ -286,7 +302,7 @@ not include your own hardware support.
@section Features
This is a summary of current and planned features for the PPSi
package. As said, we are still working on it, so the following
package. As said, we are continuously improving it, so the following
list may be not up to date with software developments by the time you
read it.
......@@ -311,18 +327,19 @@ unfair to hide them.
implementation, and our only freestanding environment is @i{wrpc},
running on an LM32 processor.
@item Support multi-link operation.
@item Support multi-PTP link operation.
The daemon manages several links at the same time, being master
slave or auto-detect independently on each link.
The @i{best master clock} algorithm is run globally,
The daemon manages several PTP links at the same time, being configured
as master/slave or auto-detecting its role on each link using
@i{best master clock algorithm} (BMCA).
The @i{BMCA} is run globally,
but communication and timeouts are managed per-link.
@item Support both @sc{udp} and raw Ethernet.
We already do that. We use the multi-link operation to
We already do that. We use the multi-PTP link operation to
support both @sc{udp} and raw Ethernet on the same network
interface. Also, we support @sc{udp} in the WR switch,
interface (physical port). We added support of @sc{udp} in the WR switch
to allow progressive and seamless migration to WR if you already
support @sc{ptp} in your network with a @sc{udp}-only implementation.
......@@ -335,6 +352,7 @@ unfair to hide them.
@item Support hardware timestamping where available.
Hardware timestamping is supported in WR devices.
This is not yet implemented for the generic protocol, but we
plan to add at least @i{time-linux-tstamp} soon.
......@@ -365,6 +383,17 @@ unfair to hide them.
when you run more than a pair of interfaces and have problems
on some of the links but not all of them.
@item Runtime re-configuratin
Currently, the configuration of PPSi is provided at startup and
it cannot be changed. It would be very useful to be able to
change some of the @sc{ptp} and extensions configuration without
the need of restarting PPSi (and resynchronizing). Such runtime
re-configuration could include ClockClass priority, packet rate
or enable/allowed extensions. Implementing runtime reconfiguration
ins on our todo list.
@end table
......@@ -389,7 +418,7 @@ As of 2013-05 the project suffers from these known bugs:
@node Configuration
@chapter Configuration
PPSi support configuration files and individual configuration items
PPSi supports configuration files and individual configuration items
passed on the command line. Such support is currently not available
for freestanding architectures (the @i{bare} ones and @i{wrpc-sw}).
......@@ -401,7 +430,7 @@ semicolon as a separator.
If no configuration file is specified, the program reads the default
one, which is architecture-specific (thus, the default configuration
file is processed after all the command line configuration items. The
file is processed after all the command line configuration items). The
default file name is @t{/etc/ppsi.conf}. The source tree of PPSi includes
two example configuration files in its own @t{/etc} subdirectory.
......@@ -445,8 +474,8 @@ following 'port-specific' keywords will be associated to this port until
a new keyword 'port' or 'link' appears.
@anchor{arg-types}
An option is a key/value(s) pair separated by at least a space character '@t{key value(s)}'. The '@t{value{s}}' entry
depends on the option type. Few types are supported by PPSi:
An option is a key/value(s) pair separated by at least a space character, e.g.: '@t{key value(s)}'. The '@t{value{s}}' entry
depends on the option type. The following value types are supported by PPSi:
@table @code
......@@ -460,7 +489,7 @@ This is a 64 bits integer value in the range from -9 223 372 036 854 775 808 to
This is an array of 2 Int16.
@item Double
This is a 64 bit floating point in the range 1.7E +/- 308 (15 digits).
A value can be expressed using this two available notations:
A value can be expressed using two available notations:
- E notation: 1.6E-1
- Decimal notation: 0.16
@item Boolean
......@@ -469,36 +498,38 @@ and '@t{f/false/0/off/n/no}' for 'False'.
@item String
This is free text.
@item TextList
The option value has to be select in a list of predefined text. For each choice we can also use different way
to refer to the same choice.
For example, the selection of the delay mechanism allows 2 choices (peer-to-peer or end-to-end) but for each choice
we are free to use a different text for the selection :
This is a list of predefined choices specified with predefined text.
For each choice, we can use more than one predefined text.
For example, the selection of the delay mechanism allows 2 predefined choices (peer-to-peer or end-to-end) but for each choice we are free to use a number of different texts for the selection:
@example
. end-to_end: "request-response","delay","e2e"
. peer-to-peer: "peer-delay","pdelay","p2p"
end-to_end: "request-response","delay","e2e"
peer-to-peer: "peer-delay","pdelay","p2p"
@end example
@end table
For some options, multiple keyword names can be used ( e.g. "mechanism", "dm"). New keyword names have been added
to be more explicit but at the same time old key names have not been suppressed just to keep the backward compatibility.
For some options, multiple keyword names (@t{key}) can be used, e.g. "mechanism", "dm". New keyword names have been added
to be more explicit but at the same time old keyword names have not been suppressed just to keep the backward compatibility.
Some old keywords will be marked '@i{(deprecated)}', and will be removed in the future.
@heading List of global options
@heading List of global options (i.e. keywords)
@table @code
@item @b{clock-class} @i{[Int32]}
An attribute defining the TAI traceability, synchronization state and
expected performance of the time or frequency distributed by a
Boundary Clock or Ordinary Clock.
For more details please refer to the IEEE 1588 standard
@item @b{clock-accuracy} @i{[Int32]}
An attribute defining the accuracy of the Local Clock (e.g. local
oscillator) of a Boundary Clock or Ordinary Clock.
For more details please refer to the IEEE 1588 standard.
@item @b{clock-allan-variance} @i{[Int32]}
An attribute defining the stability of the Local Clock of a
Boundary Clock or Ordinary Clock.
For more details please refer to the IEEE 1588 standard
@item @b{time-source} @i{[Int32]}
The source of time used by the grandmaster (or free-running master).
......@@ -508,27 +539,31 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
other as defined by the PTP protocol. A domain defines the scope of
PTP message communication, state, operations, data sets, and
timescale. PTP devices may participate in multiple domains.
For more details please refer to the IEEE 1588-2020 standard.
For more details please refer to the IEEE 1588 standard.
@item @b{priority1} @i{[Int32]}
A user configurable designation that a clock belongs to an ordered
set of PTP devices from which a PTP Master is selected.
For more details please refer to the IEEE 1588-2020 standard.
For more details please refer to the IEEE 1588 standard.
@item @b{priority2} @i{[Int32]}
A user configurable designation that provides finer grained ordering
among otherwise equivalent PTP devices.
For more details please refer to the IEEE 1588-2020 standard.
For more details please refer to the IEEE 1588 standard.
@item @b{forcePpsGen} @i{[Boolean]}
Configuration of the PPS output. By default, the PPS is generated
only when the clock class is set to 6(Grand master) or to 193(Free Running master.
Configuration of the PPS output. By default, the PPS is generated
only when the clock class is set to 6 (Grandmaster), or to 193
(Free-running master), or when the PTP device is a PTP Slave, i.e.
it is synchronized via port in Slave state to a PTP Master.
When this option is set, the PPS is always generated.
@item @b{ptpFallbackPpsGen} @i{[Boolean]}
if activated, enables the PPS generation if a slave instance
programmed to use an extension protocol (WR, L1Sync, ...) is falling back
to PTP communication only.
If set, PPS is generated even if a PTP Device with enabled
protocol extension (WR, L1Sync, ...) is synchronized using standard
PTP communication only. Note: by default, a PTP device that is a
a PTP slave and has protocol extension enabled will generate PPS
only if the protocol extension is active on the Slave port.
@item @b{ptpPpsThresholdMs} @i{[Int32]}
This option defines the threshold corresponding to the offset from the
......@@ -540,22 +575,23 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
than the threshold value + 20%.
@item @b{gmDelayToGenPpsSec} @i{[Int32]}
If this option is set to a value greater than 0, it allows the PPS generation
when the device becomes Grand-Master by BMCA. The value represent a delay in seconds to respect before
to start the PPS generation.
If this option is set to a value greater than 0, it allows PPS generation
when the PTP device becomes Grandmaster by BMCA (i.e. it is configured to be
a Boundary Clock). The value represent a delay in seconds between the
moment the PTP Device becomes Grandmaster and the start of PPS generation.
@item @b{externalPortConfigurationEnabled} @i{[Boolean]}
This option is used to force the state of all port instances. The BMCA is then disabled
in PPSi.
When enabled, the port-specific option @t{desiredState} must be defined for each port instance
For more details please refer to the IEEE 1588-2020 (clause 17.6.2)
When enabled, the port-specific option @t{desiredState} must be defined for each port instance.
For more details please refer to the IEEE 1588-2019 (clause 17.6.2)
@item @b{slaveOnly} @i{[Boolean]}
A @t{slaveOnly} Ordinary Clock utilizes the slaveOnly state machine
which does not enable transition to MASTER state.
This option must not be used when @i{externalPortConfigurationEnabled} is
enabled.
For more details please refer to the IEEE 1588-2020 (clause 9.2.2.1)
For more details please refer to the IEEE 1588-2019 (clause 9.2.2.1)
@end table
......@@ -565,13 +601,13 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
@table @code
@item @b{port} @i{[String]}
@itemx @b{link} @i{[String]}
Defines a named port instance. The argument correspond to the instance name.
Defines a named PTP port instance. The argument correspond to the instance name.
@item @b{iface} @i{[String]}
Defines the physical port interface name to use (e.g. "eth0", "wri1", ...)
@item @b{proto} @i{[TextList]}
Defines the network transport protocol to use :
Defines the network transport protocol (mapping) to use :
@example
. "raw" : Raw Ethernet
. "udp" : User Datagram Protocol
......@@ -594,52 +630,59 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
@end example
@item @b{masterOnly} @i{[Boolean]}
If enabled , activates the optional '@i{masterOnly}' feature
(refer to the IEEE 1588-2020 - clause 9.2.2.2).
If enabled , it enables the optional '@i{masterOnly}' feature
(refer to the IEEE 1588-2019 - clause 9.2.2.2).
This option cannot be used if the global option '@i{externalPortConfiguration}' is
enabled.
If this option is not set, then the standard BMCA algorithm will be used.
If this option is not set, then the standard BMCA algorithm is used.
@item @b{sync-interval} @i{[Int32,Unit=logarithm to the base 2]} @i{(deprecated)}
@itemx @b{logSyncInterval} @i{[Int32,Unit=logarithm to the base 2]}
The mean time interval between transmission of successive
Sync messages.
Sync messages. For more details please refer to the IEEE 1588 standard.
@item @b{announce-interval} @i{[Int32,Unit=logarithm to the base 2]} @i{(deprecated)}
@itemx @b{logAnnounceInterval} @i{[Int32,Unit=logarithm to the base 2]}
The mean time interval between transmissions of successive
Announce messages.
Announce messages. For more details please refer to the IEEE 1588 standard.
@item @b{in-delay-req-interval} @i{[Int32,Unit=logarithm to the base 2]} @i{(deprecated)}
@itemx @b{logMinDelayReqInterval} @i{[Int32,Unit=logarithm to the base 2]}
The minDelayRequestInterval specifies the minimum permitted
mean time interval between successive Delay_Req messages.
This option as a meaning only when 'end-to-end' delay mechanism is selected.
This option is effective only when 'end-to-end' delay mechanism is selected.
For more details please refer to the IEEE 1588 standard.
@item @b{min-pdelay-req-interval} @i{[Int32,Unit=logarithm to the base 2]} @i{(deprecated)}
@itemx @b{logMinPDelayReqInterval} @i{[Int32,Unit=logarithm to the base 2]}
The minPDelayRequestInterval specifies the minimum permitted
mean time interval between successive Pdelay_Req messages.
This option as a meaning only when 'peer-to-peer' delay mechanism is selected.
This option is effective only when 'peer-to-peer' delay mechanism is selected.
For more details please refer to the IEEE 1588 standard.
@item @b{announce-receipt-timeout} @i{[Int32]} @i{(deprecated)}
@itemx @b{announceReceiptTimeout} @i{[Int32]}
The announceReceiptTimeout specifies the number of announceIntervals
that must pass without receipt of an Announce message before the
occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.
For more details please refer to the IEEE 1588 standard.
@item @b{asymmetryCorrectionEnable} @i{[Boolean]}
When enabled, it tells the servo to calculate and take the delay asymmetry into account.
This option can be forced enabled by the profile in use (white rabbit,..). The PTP
profile does not use by default this feature.
When enabled, this feature calculates delay asymmetry which is then used in the
computation of offset from master in the PTP servo.
This feature is obligatorily enabled in some profiles when used (e.g. White Rabbit,..).
In the Default PTP Profile, this feature is not used by default.
For more details please refer to the IEEE 15882-2019 standard.
@item @b{constantAsymmetry} @i{[Int64,Unit=picoseconds]}
When '@i{asymmetryCorrectionEnable}' feature is used, this option leave the possibility to define
a constant value that will be added to the calculation of the delay asymmetry.
When '@i{asymmetryCorrectionEnable}' feature is used, this parameter allows fine-adjustment
of the calculated delay asymmetry. The provided value of @i{constantAsymmetry}
will be added to the calculation of the delay asymmetry.
For more details please refer to the IEEE 15882-2019 standard.
@item @b{desiredState} @i{[TextList]}
When the option '@i{externalPortConfigurationEnabled}' is enabled, this option indicates
the PTP port state to apply :
When the option '@i{externalPortConfigurationEnabled}' is enabled, this parameter indicates
the PTP state to apply on a PTP Port :
@example
. "initializing": Initializing state
. "faulty" : Faulty state
......@@ -655,23 +698,30 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
@end example
@item @b{egressLatency} @i{[Int64,Unit=picoseconds]}
Defines the transmission constant delays.
Defines the transmission constant delays (tx fixed delta).
For more details please refer to the IEEE 15882-2019 standard.
@item @b{ingressLatency} @i{[Int64,Unit=picoseconds]}
Defines the reception constant delays.
Defines the reception constant delays (rx fixed delata).
For more details please refer to the IEEE 15882-2019 standard.
@item @b{delayCoefficient} @i{[Double]}
When the option '@i{asymmetryCorrectionEnable}' is enabled, it defines
the asymmetry alpha delay coefficient.
Defines the relative delay coefficient (alpha parameter). When the feature
'@i{asymmetryCorrectionEnable}' is enabled, this value is used in
calculation of the delay asymmetry.
For more details please refer to the IEEE 15882-2019 standard.
@item @b{scaledDelayCoefficient} @i{[Int64,Unit=RelativeDifference]]}
When the option '@i{asymmetryCorrectionEnable}' is enabled, it defines
the asymmetry alpha delay coefficient. It overwrites the option
Defines the relative delay coefficient (alpha parameter). When the feature
'@i{asymmetryCorrectionEnable}' is enabled, this value is used in
calculation of the delay asymmetry. It overwrites the parameter
'@i{delayCoefficient}' if set by providing a value expressed with a
better resolution.
better resolution.
For more details please refer to the IEEE 15882-2019 standard.
@item @b{servo-pi} @i{[Int16[2]]}
Change the default PTP servo parameters. The first argument correspond to the
If set, it overrides the default PTP servo parameters.
The first argument correspond to the
proportionnal coefficient and the second to the integral one.
......@@ -680,7 +730,7 @@ Some old keywords will be marked '@i{(deprecated)}', and will be removed in the
@end table
@c ==========================================================================
@node Extension specific configuration
@node Extension-specific configuration
@section Extension specific configuration
@subsection White Rabbit extension
......@@ -693,21 +743,20 @@ No specific options are needed when the White Rabbit profile is selected.
Configuration, for @t{arch-unix} and @t{arch-wrs}, allows to provide
some fault injection.
In particular, the program allows dropping frames, in both the TX and RX
paths. The configuration values state how many frames are dropped every
1000. Dropping is randomized, but the user can set the seed to ensure
a repeatable dropping sequence.
Dropping transmitted frames is performed by reporting success (and the
Dropping of transmitted frames is performed by reporting success (and the
timestamp), while no frame is actually sent. A diagnostic message
is generated at @t{frames} level 1, but other than that nothing
happens. Actually, @t{arch-wrs} needs to actually send a frame in
happens. In fact, @t{arch-wrs} needs to actually send a frame in
order to get a timestamp back; in this case the program modifies the
frame, to use a wrong Ethernet type or a wrong UDP port.
Dropping received frames is performed by actually receiving (and
timestamping), but returning a special error code to the caller.
Dropping of received frames is performed by actually receiving (and
timestamping) the frames, but returning a special error code to the caller.
Again, PPSi creates a diagnostic message at @t{frames} level 1.
The following configuration lines are supported:
......@@ -722,7 +771,7 @@ The following configuration lines are supported:
@end table
The randomization see can be passed by pre-setting the environment
The randomization seed can be passed by pre-setting the environment
variable @t{PPSI_DROP_SEED} to a decimal numeric value. For example:
@smallexample
......@@ -759,8 +808,8 @@ fraction of a second of running time), and the initial offset from
master to slave is 0.9 seconds.
To pass configuration options, you can use the @t{-C} command line option.
so, for example, to start with 0.1 seconds of offset and 1000 ns of
transmission jitter, you can run like this:
So, for example, to start with 0.1 seconds of offset and 1000 ns of
transmission jitter, you can run PPSi as follows:
@smallexample
./ppsi -d 0002 -C "sim_init_master_time .1; sim_jit_ns 1000"
......@@ -771,7 +820,7 @@ transmission jitter, you can run like this:
@node VLAN Support
@chapter VLAN Support
PPSi can support vlans, or use support the Operating System offers.
PPSi can support vlans, or use the support offered by the Operating System.
@c ==========================================================================
@node OS VLAN
......@@ -800,14 +849,14 @@ this is only supported for @i{mandated} masters, at this point in
time. A mandated master is a port configured either as '@t{master}'
(externalPortConfiguration enabled) or as '@t{masterOnly}'
in the configuration file. If you want to run multiple vlans on the
same physical ports, without forcing the port to be a mandated master,
same physical port, without forcing the port to be a mandated master,
you can create multiple PTP interfaces, one per vlan, all relying on
the same physical port (or different OS-specific vlan ports).
When running a fully-PTP network in end-to-end mode, you won't usually
need to configure multiple vlans on a single port. In particular, this
never happens in a White Rabbit network, because each link connects
two clocks, without any non-compliant switches in the middle.
two WR-PTP devices, without any non-compliant switches in the middle.
However, if you have
transparent clocks or normal switches, you may want to behave
as a master for the whole network connected to your port, which may
......@@ -826,27 +875,28 @@ code, in the following way.
comma-separated.
@item Configuration fails (and PPSi refuses to start) if the architecture
has no vlan support, or of multiple vlans are specified for an
architecture that supports one vlan only.
has no vlan support and vlan is specified, or multiple vlans are specified
for an architecture that supports one vlan only.
@item Configuration fails also if several vlans are specified for
a port that is not a mandated master.
a port that is not a @i{mandated} master.
@end itemize
When only one vlan is specified, the network operations for the
architecture are responsible: they must do the right thing. Currently,
@t{wrpc} builds and decodes Ethernet frames (FIXME: NOT YET), ignoring
any received frame not belonging to the proper vlan. Code for @t{wrs} and
@t{unix} handles a single vlan like multiple ones; I thought
about automatically creating the vlan-specific interface, but that
would be very Linux-specific and I see no real need for it.
@t{unix} handles a single vlan like multiple ones (NOTE:
automatically creating the vlan-specific interface was considered, but that
would be very Linux-specific and there was no real need for it).
When multiple vlans are specified for a master port, current code
(i.e. @t{arch-wrs} and @t{arch-unix}) binds to @t{ETH_P_ALL}, in order
to receive all frames from that interface, and thus be able to tell
which vlan they belong to. A multiple-vlan master sends announce and
sync (plus follow-up) to all vlans at the same time, and will reply to
delay requests using the same vlan it receives it from. Frames from
delay requests using the same vlan it receives it from, limited to the
list of configured vlans. Frames from
other vlans, as well as non-PTP frames, are ignored.
Because of the @t{ETH_P_ALL} binding, a multiple-vlan master port will
......@@ -871,7 +921,7 @@ like @t{eth0}, it receives all frames for that @i{ethertype}, whether
or not they are tagged on the wire. To our knowledge there is no way,
in this situation, to tell whether the frame was tagged, and which tag
were there if any. Only traffic to vlan-specific ports, like
@t{eth0.20}, si guaranteed to belong to vlan 20 (or a double-tagged
@t{eth0.20}, is guaranteed to belong to vlan 20 (i.e. a double-tagged
frame, whose external tag is 20).
Only a socket bound to all @i{ethertypes} (i.e. @t{ETH_P_ALL}) is able
......@@ -892,8 +942,8 @@ CPU overhead, but more administrative work.
@chapter PTP Clock Class
The clock class value (@t{clockClass}), a field of the `clock quality'
structure, can be specified in the configuration file for the architectures
that support such a file.
structure defined by the IEEE1588 standad, can be specified in the
configuration file for the architectures that support such a file.
@c ==========================================================================
@node Default device attributes
......@@ -998,13 +1048,13 @@ timePropertiesDS.timeTraceable = FALSE
@node Clock class degradation
@section Clock class degradation
PPSi manage clock class degradation for a set of clock classes and update accordently
clock and time property field.
As certain clock and time properties may be set in the PPSi configuration, so when a clock class
PPSi manages clock class degradation for a set of clock classes and updates accordingly
clock & time property field.
As certain clock & time properties may be set in the PPSi configuration, so when a clock class
is degraded, all updated clock and time fields are changed in a way to never set them to a better
value than their configured one. In such a case, they will remain unchanged.
The following table show how a clock class is degraded when the PLL is in holdhover or unlocked:
The following table show how a clock class is degraded when the PLL is in holdover or unlocked:
@table @code
@item @b{PTP_GM_LOCKED(6)} - PLL holdover detected
......@@ -1139,7 +1189,7 @@ diagnostics on either a single link or globally.
The diagnostic flags are split into topics (called @i{things}). For
each diagnostic thing the header defines a few bits; so we can have
diagnostic levels for each of them, but we suggest only using level 1
diagnostic levels for each of them, but we suggest using only level 1
and 2 -- the rationale is in the header itself.
The @i{things} currently defined are:
......@@ -1162,7 +1212,7 @@ addition of new masters as well.
@item Extensions: extension-specific information.
@item Configuration: at level 1 PPSi reports errors, at level 2 all
configuration items being parsed (from either files or command line).
configuration items being parsed (from either file or command line).
@end itemize
......@@ -1389,7 +1439,7 @@ positives that are simply due to process latencies induced by the
system workload.
By running this program you can see the effect of @i{tools/jmptime},
or the insertion of a leap second (which is why I wrote this program
or the insertion of a leap second (which is why this program was written
in June 2012).
For example, this is what @i{chktime} reports when running
......@@ -1460,7 +1510,7 @@ The following are example uses of the program on an ntp-driven host:
@node mtp
@section mtp
The directory @i{tools/mtp} includes a few example programs I wrote for
The directory @i{tools/mtp} includes a few example programs written for
an article about time synchronization. MTP means ``mini time protocol'';
it uses the T1, T2, T3, T4 idea to report the time difference between
two hosts. The program comes in two flavors: UDP and raw Ethernet.
......@@ -1500,9 +1550,7 @@ The @i{MAKEALL} script, in the top-level directory of PPSi builds the
program for all known configurations, picking them from @t{configs/}.
Developers are urged to run it
before committing each patch, to ensure they are not breaking the
program for configurations they are not using -- but sometimes I
forgot to do that myself and committed trivially-incomplete changes.
program for configurations they are not using.
It may happen, however, that some developers experience errors or
warnings that others didn't notice, because of differences in compiler
version or library versions.
......@@ -1548,8 +1596,8 @@ Additionally, "@t{CONFIG_PRINTF_XINT}" or one of the other @i{pp_printf}
configurations can be set to override the default. By default PPSi
builds the ``full'' implementation.
This state-machine source refers to a specific state machine by the
name @i{pp_state_table}. The table is picked from a
The state-machine source (i.e.@i{./fsm.c}) refers to a specific state machine
by the name @i{pp_state_table}. The table is picked from a
library: either from the extension being selected or the @i{proto-standard} one.
The table includes pointers to functions, and such names
will select which other object files are picked up from the libraries.
......@@ -1562,13 +1610,13 @@ leaving the final link to the chosen architecture, so for example
@i{arch-unix} adds @t{ppsi} to the @t{all} target.
Since code and data space is a problem in the freestanding world (for
example, the whole ptp may need to fit in 64kB RAM including data and
example, the whole PPSi may need to fit in 64kB RAM including data and
stack), each state in the state machine of the standard protocol must
be implemented as a separate file. This allows an extension not using
that particular function to save the overhead of binary size.
Clearly an extension may implement several functions in the same file,
if they are known to be all used in the final binary or of it uses
@t{-ffunction-sections} and @t{-fdata-sections}).
@t{-ffunction-sections} and @t{-fdata-sections}.
@c ##########################################################################
......@@ -1613,7 +1661,7 @@ linked as a library.
The coding style is the one inherited from Linux kernel project (see
@i{Documentation/CodingStyle} in the kernel sources). However,
structures, constants and field names defined by @sc{ieee} 1588 are kept in
the suggested "CamelCase" form. Similarly, the typedefs are left, even
the suggested "camelCase" form. Similarly, the typedefs are left, even
if they are really a pain to deal with. Most of this stuff is in
include/ppsi/ieee1588_types.h file.
......@@ -1625,7 +1673,7 @@ Some prefixes to the @sc{ieee} naming are added, in order to improve
readability:
@t{EN} means "enumeration type". For instance, Enumeration Time Source
(defined in the spec at table 7, page 57) becomes @t{ENTimeSource}.
(defined in IEEE 1588-2008 at table 7, page 57) becomes @t{ENTimeSource}.
@t{PPM_} means "ppsi message", and is used for message types.
......@@ -1636,7 +1684,7 @@ definition.
@t{DS} means "data set", and is used for the standard Data Sets (e.g.
@i{DSCurrent} is the "Current Data Set"). The concept of data sets is
defined in the specification at chapter 8, page 63.
defined in IEEE 1588-2008 in chapter 8, page 63.
@c ##########################################################################
@node Command Line
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment