Conversation
Introduces an option to enable drift tracking support for IEEE Std 802.1ASdm. Signed-off-by: Goh, Wei Sheng <wei.sheng.goh@intel.com>
Introduce a dedicated TLV structure to support drift tracking in time synchronization protocols. This new TLV will enables precise encapsulation and communication of drift tracking data between protocol entities, facilitating improved synchronization diagnostics and interoperability. Signed-off-by: Goh, Wei Sheng <wei.sheng.goh@intel.com>
Enable the drift_tracking feature for P2P network. This feature enables comprehensive monitoring and reporting of clock drift for P2P network, enhancing synchronization accuracy and system diagnostics. Signed-off-by: Goh, Wei Sheng <wei.sheng.goh@intel.com>
This patch introduce the nrrSync which utilizing the information in drift_tracking TLV to calculate the neigbor rate ratio. Now user have the alternative to choose between using the nrrPdelay or nrrSync based on nrrCompMethodfor clock rate adjustment. The nrrSync is expected to be more accurate as it is based on the sync message which is more frequent than pdelay, but it also might be more noisy as it is more sensitive to timestamping error. The nrrPdelay is expected to be more stable but might be less accurate as it is based on the pdelay message which is less frequent than sync. Signed-off-by: Goh, Wei Sheng <wei.sheng.goh@intel.com>
Signed-off-by: Goh, Wei Sheng <wei.sheng.goh@intel.com>
|
Help needed to review the NRR calculation and implementation. Thanks. |
| /* Calculate nrrSync */ | ||
| tmv_t t1, t1c; | ||
| t1 = extended_to_tmv(&dt->syncEgressTimestamp); | ||
| t1c = tmv_add(t1, correction_to_tmv(p->asymmetry)); // do we need to add asymmetry here? |
There was a problem hiding this comment.
Q: nrrSync need to add asymmetry/correction or not?
| n->ratio_valid = 1; | ||
| } | ||
|
|
||
| void port_nrate_sync_calculate(struct port *p, tmv_t origin, tmv_t ingress) |
There was a problem hiding this comment.
All: Help needed to evaluate the nrrSync calculation, the flow where nrrSync is calculate at the right place? and does it implemented correctly?
There was a problem hiding this comment.
AR to Peter - check the nrrSync calc and flow implement correct or not?
| if (clock_drift_tracking(p->clock)) { | ||
| struct drift_tracking_tlv *dt = drift_tracking_extract(m); | ||
| clock_drift_tracking_update(p->clock, dt); | ||
| /* Calculate nrrSync */ |
There was a problem hiding this comment.
Same doubt. How can you determine the last hwts is timestamp of the corresponding sync msg of this FUP msg? Please rethink whether the nrrSync calculation should be done in process_follow_up().
There was a problem hiding this comment.
AR to WS - consider to move to port_syfufsm
| /* Calculate nrrSync */ | ||
| tmv_t t1, t1c; | ||
| t1 = extended_to_tmv(&dt->syncEgressTimestamp); | ||
| t1c = tmv_add(t1, correction_to_tmv(p->asymmetry)); // Q: do we need to add asymmetry/correction? |
There was a problem hiding this comment.
is the nrrSync asymmetry used the same value p->asymmetry?
| t1c = tmv_add(t1, correction_to_tmv(p->asymmetry)); // Q: do we need to add asymmetry/correction? | ||
| pr_debug("%s: t1=%" PRId64 ", asymmetry=%" PRId64 ", t1c=%" PRId64, p->log_name, | ||
| tmv_to_nanoseconds(t1), tmv_to_nanoseconds(correction_to_tmv(p->asymmetry)), tmv_to_nanoseconds(t1c)); | ||
| if (dt && p->nrrCompMethod == SYNC) // Q: if no dt tlv do we still calculate nrrSync? |
There was a problem hiding this comment.
If dt tlv is not available, there will be missing info needed for nrrSync calculation, example syncEgressTimestamp.
There was a problem hiding this comment.
AR to WS - reconfirm the missing info
|
|
||
| tsproc_set_clock_rate_ratio(p->tsproc, p->nrate.ratio * | ||
| clock_rate_ratio(p->clock)); | ||
| double nrr = (p->nrrCompMethod == SYNC && clock_drift_tracking(p->clock)) ? |
There was a problem hiding this comment.
According to AS2025, "11.2 State machines for MD entity specific to full-duplex point-to-point links", the nrrCompMethod should be handle in the syncReceive state machine (MDSyncReceiveSM). This make sense as sync msg is sending more frequent compare to Pdelay msg. if nrrSync is selected, do not update the clock_rate_ratio here.
| int inhibit_delay_req; | ||
| /* portDS */ | ||
| struct PortIdentity portIdentity; | ||
| Enumeration8 nrrCompMethod; |
| if (clock_drift_tracking(p->clock)) { | ||
| struct drift_tracking_tlv *dt = drift_tracking_extract(m); | ||
| clock_drift_tracking_update(p->clock, dt); | ||
| // Q: Do we want to direct return when no dt? or change the nrrcompmethod to nrrpdelay? else nrr will be some invalid value to adjust the tsproc? |
There was a problem hiding this comment.
open discussion: if driftTrackingTlvSupport is TRUE and nrrCompMethod is Sync, but no drift_tracking_tlv is received, do we still need calculate nrrSync and nrrSync will be used?
| tmv_t origin, corrected_origin; | ||
|
|
||
| origin = extended_to_tmv(&dt->syncEgressTimestamp); | ||
| corrected_origin = tmv_add(origin, correction_to_tmv(p->asymmetry)); // Q: do we need to add asymmetry/correction? |
There was a problem hiding this comment.
imo yes, as mentioned, "(C) CMLDS delayAsymmetry (i.e., cmldsLinkPort.delayAsymmetry, see 10.2.5.9) if CMLDS is provided, otherwise instance-specific delayAsymmetry (i.e., portDS.delayAsymmetry, see 14.10.11) divided by rateRatio (see 10.2.8.1.4)."
so p->asymmetry here i assume is from CMLDS? how about if without CMLDS, do we need to handle?
3 participants
Introduce new drift tracking feature based on IEEE Std 802.1AS™‐2025