Hi,
Please elaborate regarding kernel API. I understood from the submission
that you plan to start off with some vendor specific sysfs declared in
the config file.
But I believe this is not the final goal, correct?
Do you have kernel patches for review?
Thanks,
Aya
On 6/9/2022 10:12 PM, Kubalewski, Arkadiusz wrote:
-----Original Message-----
From: Aya Levin via Linuxptp-devel <linuxptp-devel@lists.sourceforge.net>
Sent: Wednesday, June 8, 2022 10:31 AM
On 5/30/2022 10:34 PM, Arkadiusz Kubalewski wrote:
synce4l is a software implementation of Synchronous Ethernet (Sync-E)
according to ITU-T Recommendation G.8264. The design goal is to provide
logic to supported hardware by processing Ethernet Synchronization
Messaging Channel (ESMC) and control Digital Phase Locked Loop (DPLL)
We should use EEC rather than DPLL (more abstract less HW related)
Sure, graet idea. Will fix it.
clock on Network Card Interface (NIC).
Application can operate in two mutually exclusive modes. If both modes
are configured simultaneously, the external input takes precedence over
internal one (internal is disabled implicitly).
AFAIU there is one selection process which regards all the sources and
select according to the quality/priority.
What is the benefit of two mutually exclusive modes?
Yes that is true, but SyncE chain has to start somewhere, currently:
- internal mode - the NIC is monitoring its ports and selects one to
recover the clock from
- external mode - ports are not monitored at all, user provides
external signal which drives the EEC, once EEC-DPLL is in locked state
synce4l starts broadcasting its QL to the neighbour configured ports.
(QL value also user-configured, as only user knows QL of external signal used
to drive the EEC),
Basically, external mode here was similar to Grandmaster in PTP,
at least that was our understanding of A.2 from Annex A of G.8264
I think this needs to be renamed to make it clear for everyone.
Annex A also says:
"Synchronous Ethernet equipment shall support a selection mechanism that allows
synchronization to be derived from the line (i.e., traffic-carrying
interfaces), from external synchronization interfaces (i.e., provided by
co-located equipment) or internally from the EEC."
So in fact, we shall have 3 mutually exclusive modes for a device.
We will change this config item to a name "input_mode", with possible string
values:
- "line"
- "external"
- "internal"
Altough new modes: "internal" and "external", will not differ in implementation
from current "external_mode", as this requires preconfiguring device and
explicitly defining the QL by the user (at least before proper in-kernel
interface for controlling EEC-alike integrated circuits is introduced).
Does it make sense?
External input mode
If synce4l is configured to run in "external input" mode, then DPLL
needs to have external 1PPS source attached (GPS or another generator).
In this scenario synce4l always broadcasts clock quality level (QL)
defined in configuration file. Additionally, for this mode
incoming Sync-E frames do not participate in best source selection
algorithm for DPLL.
Internal input mode
Lets use the standard (G.8264 - Annex A) naming of traffic reference
source. Internal may refer internal oscillator.
Sure, above answer is sufficient?
In "internal input" mode incoming Sync-E frames are processed and best
clock source is extracted from the link having the best quality level.
synce4l configures such "best quality" port as a source to recover
clock for DPLL. The recovered QL is broadcasted to all other interfaces
then. An external clock cannot be used in this mode.
Hardware
synce4l is not bound to any specific NIC hardware.
In this level HW should be hidden totally - please see my comment in
patch #5
I understand you are refering to the name of "DPLL", will change it to EEC.
Theoretically any NIC could be used for enabling Sync-E device in
Lets use SyncE and not Sync-E
Sure, can do that.
External input mode - the NIC in this mode is in leader role (similar
to Grand Master role in PTP), providing its Quality Level information
in ESMC frames to its neighbors.
How do we monitor the quality and validity of an external source?
Right now (we already know that DPLL naming all over the code and documentation
shall change in future patches), validity is checked as a state of dpll (user
configures a shell command "get_dpll_state_cmd" and its possible return
values). If it is not "locked", the DNU QL is broadcasted through the
configured ports, once "locked" the user-configured QL starts to be
broadcasted.
The quality itself depends on "external" sources, so this is user-configurable.
Thank you,
Arkadiusz
It will not syntonize to any of its neighbor ports, since RX frames
are not monitored. Only other Sync-E enabled neighbor ports could
recover clock from that peer and syntonize to it.
Practically this mode shall be used only if the NIC PHY ports are fed
with stable and reliable frequency clock, Quality Level values that are
sent to the peers are configured by the user. This is user
responsibility to decide and set proper Quality-Level value for the
device, corresponding to the quality of frequency clock generator of
used hardware.
When enabling Internal input mode, the NIC must be a device that
actually, supports Synchronous Ethernet, which means it is able to
syntonize frequency of all configured ports within the device
to one chosen port - clock is recovered from its RX path, then is fed
to other ports with Phase-Locked Loop (PLL) circuit powering clock of
other ports.
The NIC driver or dedicated software must provide a user with ability
to:
obtain current state of a DPLL used to syntonize the ports
select one of the ports as a candidate for clock recovery.
Both abilities are configurable in config file - the user must provide
a shell commands - as explained in manual and descriptions inside of
example config file.
Arkadiusz Kubalewski (11):
synce4l: add config knobs for SyncE
synce4l: add synce in interface and util code
synce4l: add esmc_socket interface
synce4l: add synce_clock interface
synce4l: add synce_dev interface
synce4l: add synce_dev_ctrl interface
synce4l: add synce_port interface
synce4l: add synce_port_ctrl interface
synce4l: add synce_msg interface
synce4l: add synce_transport interface
synce4l: add synce4l application
.gitignore | 1 +
README.org | 2 +
config.c | 197 +++++--
config.h | 8 +
configs/synce.cfg | 194 +++++++
esmc_socket.c | 99 ++++
esmc_socket.h | 42 ++
interface.c | 29 +-
interface.h | 24 +
makefile | 9 +-
synce4l.8 | 239 ++++++++
synce4l.c | 132 +++++
synce4l_README.md | 194 +++++++
synce_clock.c | 284 +++++++++
synce_clock.h | 40 ++
synce_dev.c | 622 ++++++++++++++++++++
synce_dev.h | 64 ++
synce_dev_ctrl.c | 153 +++++
synce_dev_ctrl.h | 64 ++
synce_msg.c | 259 +++++++++
synce_msg.h | 174 ++++++
synce_msg_private.h | 87 +++
synce_port.c | 491 ++++++++++++++++
synce_port.h | 184 ++++++
synce_port_ctrl.c | 1161 +++++++++++++++++++++++++++++++++++++
synce_port_ctrl.h | 165 ++++++
synce_transport.c | 102 ++++
synce_transport.h | 55 ++
synce_transport_private.h | 18 +
util.c | 22 +
util.h | 8 +
31 files changed, 5077 insertions(+), 46 deletions(-)
create mode 100644 configs/synce.cfg
create mode 100644 esmc_socket.c
create mode 100644 esmc_socket.h
create mode 100644 synce4l.8
create mode 100644 synce4l.c
create mode 100644 synce4l_README.md
create mode 100644 synce_clock.c
create mode 100644 synce_clock.h
create mode 100644 synce_dev.c
create mode 100644 synce_dev.h
create mode 100644 synce_dev_ctrl.c
create mode 100644 synce_dev_ctrl.h
create mode 100644 synce_msg.c
create mode 100644 synce_msg.h
create mode 100644 synce_msg_private.h
create mode 100644 synce_port.c
create mode 100644 synce_port.h
create mode 100644 synce_port_ctrl.c
create mode 100644 synce_port_ctrl.h
create mode 100644 synce_transport.c
create mode 100644 synce_transport.h
create mode 100644 synce_transport_private.h
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
