Hi all,
Am 2020-03-25 23:26, schrieb Rodney Cummings:
- the SYNCs are forwarded upon reception of a SYNC packet; then
the correction field is updated.
- there is no concept of syncLocked in the current standards. Only
the new 802.1AS-REV (and I guess that will be the 802.1AS-2020?!
introduces that. But even in that case, the correction field is
updated based on the last received sync. So it is more a TC with
some artificial update.
802.1AS-2011 supports changing portDS.logSyncInterval with a Signaling
message. Linuxptp doesn't support that, which is totally fine, but we
might want to support it someday.
1588-2008 supports changing portDS.logSyncInterval via 1588 Management,
using SET of LOG_SYNC_INTERVAL TLV. Linuxptp doesn't support that
(see port.c, port_manage), which is totally fine, but we might want
to support it someday.
If we are confident that we'll never support changes to
portDS.logSyncInterval, the proposal to implement as TC
is reasonable.
If we do end up supporting a change to portDS.logSyncInterval
(as I suspect), then we are faced with a question:
What happens when the received sync interval is different than
the configured portDS.logSyncInterval for transmit?
According to 802.1AS-2011, The implementation shall transmit
using portDS.logSyncInterval, not the received interval.
That requirement wasn't explicitly clear in 802.1AS-2011...
I agree that standard text can be a mess sometimes. In an attempt
to clean it up, 802.1AS-2020 added the "syncLocked" boolean. That
boolean isn't really a new feature. It clarifies something that was
true in both 2011 and 2020: an implementation must handle
sync receive/transmit at the same rate (boolean true, TC-like),
and sync receive/transmit at a different rate (boolean false, BC-like).
What entity in the 802.1AS-2011 will generate a PortSyncSync which is
necessary in PortSyncSyncSend state machine to actually generate an
outgoing SYNC message. Given that the ClockMaster is optional, it can
only be the PortSyncSyncRecveive. But the latter only generate one when
it receives a SYNC on a port. And all transitions going into the
SEND_MD_SYNC state requires "rcvdPSSync == TRUE".
And for the other way. If the downstream syncInterval is larger than
the upstream one. Which intance (in the standard) drops the sync?
That's why I tend to think of BC as the correct long-term
implementation
for 802.1AS. That being said, if Linuxptp experts prefer TC for now,
that sounds fine... we can always defer these issues to later.
Citing the new REV standard:
NOTE—The sending of time-synchronization information by the master
ports of a PTP Instance might or might not be tightly synchronized
with the receipt of time-synchronization information by the slave
port. If a master port has the same logMessageInterval as the slave
port, it will transmit timing event messages as soon as possible after
the slave port has received the corresponding timing event
messages,
and the master port is operating in “syncLocked” mode
(see 10.2.5.15). If a master port and slave port have different
logMessageInterval values, then the master port can send timing event
messages without any synchronization with the slave port.
How should this be interpreted? "might or might not", depending on what?
Sounds to me, that in syncLocked mode that slave ports should (shall?)
transmit the SYNC as soon as possible after receiving it on the master
port, ie forwarding. In !syncLocked mode, it is up to the implementation
when to actually send the SYNCs.
I'm by far no expert in linuxptp, so I might be wrong, but all this "we
modify the correction field", "we forward the SYNC message instead of
generating a new one" sounds more like TC.
What about the free running clock feature? Would that be supported in
the BC mode?
-michael
Rodney
-----Original Message-----
From: Michael Walle <mich...@walle.cc>
Sent: Tuesday, March 24, 2020 3:38 AM
To: Richard Cochran <richardcoch...@gmail.com>
Cc: Rodney Cummings <rodney.cummi...@ni.com>; Erik Hons
<erik.h...@ni.com>; linuxptp-devel@lists.sourceforge.net
Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE
802.1AS-2011
time-aware bridge support
Am 2020-03-20 18:32, schrieb Richard Cochran:
> On Tue, Mar 17, 2020 at 04:41:14PM +0000, Rodney Cummings wrote:
>> Recommendation: Keep to 802.1AS-2011 bridge for the upcoming patches.
>
> Okay.
>
>> Recommendation: After 802.1AS-2011 bridge is in the Linuxptp master,
>> NI runs the UNH-IOL Conformance bridge tests, and submits category A)
>> and B) failures to Linuxptp.
>
> I really appreciate NI's offer of help in testing. Could you run the
> Conformance test on the patches before I merge them to master?
I don't think hacking the 802.1AS stuff into BC is a good fit:
- the SYNCs are forwarded upon reception of a SYNC packet; then
the correction field is updated.
- there is no concept of syncLocked in the current standards. Only
the new 802.1AS-REV (and I guess that will be the 802.1AS-2020?!
introduces that. But even in that case, the correction field is
updated based on the last received sync. So it is more a TC with
some artificial update.
- as far as I understand the standard, the source port ID is the one
from the grandmaster. Strange enough most implementations get this
wrong. Maybe I'm wrong, it is very hard to follow that standard.
There is also this patch
[RFC V3, 3/4] port: drop erroneous neighbor rate ratio
which I don't know why it is there. In my experience, this patch make
things just worse. It won't sync anymore if the rate ratio is too
high.
While this might be mandatory to be compliant, I really question
whether
it is actually useful. So generic question, do we want to follow the
standard no matter what, or do we want to be on the safe side and try
to
actually sync the clocks?
-michael
> If it helps your workflow, I can surely put those patches on a branch
> on Github for you.
>
> Thanks,
> Richard
>
>
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listin
> fo/linuxptp-devel__;!!FbZ0ZwI3Qg!832O5vPvHyh_bdJuQJ2MUFpe66PcaA8zGa8Gk
> 6djEA8klY2Depb33MK-NtLhWg7kbA$
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
