Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_ISAAC] Discussion on comment #500

All,

 

I like to suggest that to move forward, we just define timing_lock_OK along the lines that

George suggested without putting any timing constraints for now.  

 

In the next cycle this text remains in scope and we can think about this some more and pursue one of 3 options:

  1. Do nothing
  2. Add some timing constraints to it.
  3. Delete the bit

 

Thanks,

William

From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Tuesday, July 14, 2026 2:31 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

All,

 

I am not sure that this bit is useful for ACT, due to the extreme simplicity of the camera PHY. However, I have no problem including it as long as we do not put anything in there that may break or degrade the system.

 

Regarding Hossein's question about why 2ms, I have no problem with the 5ms value.

 

BTW, there should not be anything in there that would prevent the PHY implementation to always set timing_lock_OK to 1. This effectively makes this bit "redundant".

 

Ragnar

 

On Tue, Jul 14, 2026 at 11:07 AM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

I’ve seen this bit useful.  If timing is being lost at one end you may still be able to track the the transmitted signal at the link partner.  I would not support any attempt to make the bit prescient of a loss of lock – it just narrows the window for recovering timing.

Again – do not constrain the bit.  Constrain behavior that you need constrained.  Constraining the bit does nothing more than censor information.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Hossein Sedarat <hossein.sedarat@xxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2026 1:39 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] Discussion on comment #500

 

Alireza, Ragnar, George,

 

A couple of comments:

 

  1. This bit,  as defined, is not very useful. This is not specific to 802.3dm but true for other specs that define it this way. If the timing is lost on the Follower, this bit is not guaranteed to be detected by Leader. In principle, the Follower should ideally set this bit in anticipation of an event that may cause a loss of timing lock. In this case, the Leader can detect this bit properly and prepare for that. We should define a minimum time from resetting this bit to the moment that timing is lost so that Leader have enough time to detect and react to this event.
  2. It would be good to put a maximum total time that this bit can be zero for the duration of a training cycle. But where did you get the 2 ms from? I have a feeling that this number may be ok but perhaps on the lower side. I haven’t done my homework to be sure. I have a better feeling if we start with a total time of 5 ms and refine it in future.

 

I am ok if we keep the text without any time limits. But if we are revisiting the definition of this bit, I would suggest the following:

 

The follower sets timing_lock_OK to 1 when to indicate stable transmit clock, and set timing_lock_OK to 0 in anticipation of an event which may result in loss of timing. This bit should be ser to 0 at least T1 ms (T1=1ms?) before the timing is lost so that the Leader can detect and react to loss fo timing. The setting of timing_lock_OK value is implementation specific. The transmit clock should be such that timing_lock_OK is not set to 0 for more than T 2ms (T2=5 ms?) during each training session.

 

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2026 10:26 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

Caution -- External Email, please handle with due care. Please DO NOT click links or open attachments unless you recognize the sender's email. Please report suspicious emails to the Helpdesk.

 

Ragnar – I feel strongly that we should not put requirements on the setting of an indicator bit.  If you need a requirement, put it on some identifiable behavior, rather than on the indication of a state.  I would change the text as follows:

The follower sets timing_lock_OK to 1 when it has stable transmit clock, and otherwise timing_lock_OK is set to 0. The setting of timing_lock_OK value is implementation specific.  The transmit clock should be such that timing_lock_OK is not set to 0 for more than 2ms during each training session.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Tuesday, July 14, 2026 1:14 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

All,

 

I am not sure that we need the timing_lock_OK, but if we keep it, then I propose the following text:

The follower sets timing_lock_OK to 1 when it has stable transmit clock, and otherwize timing_lock_OK is set to 0. The setting of timing_lock_OK value is implementation specific, but is not set to 0 for more than 2ms during each training session.

 

The idea behind the proposed text is that timing_lock_OK should be set to 1 most of the training time, but may be set to 0 for a limited time. I would expect it to be most likely that we set timing_lock_OK to 0 just after the follower starts transmitting its training signal, but this assumption is not explicitly stated in the text above. The text does not have any shall statements, since the idea is that it is implementation specific, but we might consider "shall" for the maximum duration of timing_lock_OK set to 0.

 

Ragnar

 

On Mon, Jul 13, 2026 at 12:03 PM alireza razavi <alirezamajoomard@xxxxxxxxx> wrote:

Going this path opens the door for unnecessary complications because the timing is supposed to be locked in the half duplex and stay locked.is there any reason that we think phy may loose timing lock after half duplex?

 The original comment was about removing this bit from the info-field exchange. Based on the definition, whenever this part of info-field is changed, phy has to transmit the bit so many times. This is an unnecessary extra delay. I don’t see any value while we already have a bit (loc_rcvr_status) that indicates the health of the leader receiver. loc_rcvr_status is well-integrated into our physical state machine. 

Alireza

 

 

 

 

On Jul 13, 2026, at 2:40 PM, Peter vanDyck <00005eed8bd3e774-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:



Sure the definition by itself is fine.

 

Peter

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 11:31 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

 

I hear you – and see the issues you’re pointing out.  The constraining of the messages though sounds like a different comment – something to make on a future draft.  The nature of the information is what it is….  Not sure why you’d want to falsely represent timing lock is ok…

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Peter.vanDyck@xxxxxxxxxxxx <Peter.vanDyck@xxxxxxxxxxxx>
Sent: Monday, July 13, 2026 2:15 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] Discussion on comment #500

 

My concern is e.g. 191.5.2.4.4 Message Field:

All possible Message Field settings are listed in Table 191–5 for the LEADER and Table 191–6 for the

FOLLOWER. Any other value shall not be transmitted and shall be ignored at the receiver. The Message

Field setting for the first transmitted PMA frame shall be the first row of Table 191–5 for the LEADER and

the first or second row of Table 191–6 for the FOLLOWER. Moreover, for a given Message Field setting,

the next Message Field setting shall be the same Message Field setting or the Message Field setting

corresponding to a row below the current setting. When loc_rcvr_status = OK the Infofield variable is set to

loc_rcvr_status<5> = 1 and set to 0 otherwise.

 

To me that reads like any other Message Field (to me it is the whole row), is not permitted. That means a row where timing_lock_OK or loc_rcvr_status goes back to 0 is not possible.
Although I understand that loc_rcvr_status field is defined the same as your proposal for timint_lock_OK.

 

Thanks,

Peter

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 10:56 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

 

Yes, it isn’t an assumption – it is behavior.  Timing lock can be lost after it has been required, and if it is, the bit flips from 1 to 0 (and hopefully back to 1 when it is reacquired again).

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Peter vanDyck <00005eed8bd3e774-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 1:49 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

Hi George,

 

is the assumption that timing_lock_OK could be lost after a “1” has already been transmitted to the link partner, and that loss would be transmitted again through the infofield? It’s not clear to me from the “is set to zero otherwise”.


Thanks,

Peter

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 10:34 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

 

Ragnar – I was struggling with precise words for the implementation-specific nature of determining whether the follower was tracking...  If you can provide some, I would be grateful.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Monday, July 13, 2026 1:17 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Discussion on comment #500

 

I agree with George's comment. I would expect the initial condition to be 0 (FALSE), and then transition to 1 (TRUE) when the follower has acquired the timing lock. Therefore it is more appropriate to talk about setting timing_lock_OK=1 when timing lock has been acquired and set to 0 otherwize. There should also be a statement about the implementation of the timing_lock_OK condition is implementation specific.

 

Ragnar

 

On Mon, Jul 13, 2026 at 8:18 AM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

William – I would rather suggest that we define the bit in the positive sense.  Otherwise, if the FOLLOWER never acquires the timing reference, under your definition, timing_lock_OK would be set to 1, because you can’t lose what you never have.  This is, however, not what I think we want.  Also, style manual says you spell out zero & one, and I believe we have another comment to not put LEADER and FOLLOWER in all caps…

 

 

Insert text in 191.5.2.6 (page 116) after line 28.

The timing_lock_OK bit transmitted by the Follower in the infofield to indicate whether the Follower is currently tracking the Leader’s timing reference. This indicator bit is set to one to indicate that a Follower is tracking the Leader’s timing reference and is set to zero otherwise.

 

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: William Lo <00005d57449a68e9-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 13, 2026 11:05 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Discussion on comment #500

 

All,

 

I took an action to get some wording to define timing_lock_OK. 

 

Insert text in 191.5.2.6 (page 116) after line 28.

Whenever a FOLLOWER loses the LEADER's timing reference it sets timing_lock_OK=0, which is communicated to the link partner via the InfoField.  Otherwise, timing_lock_OK is set to 1.

 

Thanks,

William

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1