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

Re: [802.3_10SPE] Fast Link Recovery



Geoff – you may be right.  If we assume that the real issue is to provide links with a certain uptime reliability in a certain environment,  how would you state this?

 

From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Thursday, October 13, 2016 10:49 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Fast Link Recovery

 

Oisin-

 

I would assert that your "argument":

"the requirement to keep up with channel variations is already implicitly covered in the existing objective:
'Support 10 Mb/s operation in industrial environments'

 

...is too subtle and insufficiently explicit to achieve the goals you are seeking.

 

Regards,

 

Geoff Thompson
 

On Oct 13, 2016, at 6:25 AMPDT, Cuanachain, Oisin <Oisin.Ocuanachain@xxxxxxxxxx> wrote:

 

Hi all, 

 

'Fast Link Recovery' was discussed at the ad hoc meeting but I'm not sure I understand what this proposed objective is intended to achieve ?

My own background is in PHY design (10/100/1000BaseT) but I have very little prior experience of Ethernet used in industrial environments.

There was some discussion of the objective but I am not sure I understand what is driving the proposal.

Specifically, does the proposal 

(i) hope to use the 'Fast Recovery' to remedy packet reception problems (within 40ms) to prevent message loss (here I use 'message' to mean the information which, in the

    industrial protocol, is repeated multiple times in successive Ethernet packets to make the communication more robust)

Or

(ii) is it simply that industrial end-users are aware that retraining is behaviour that PHYs can exhibit when packets are being lost and the proposed

     objective hopes to ensure that should such a retrain occur it would have completed within 40ms ? (In this scenario, from the application point of

     view, the retrain manifests itself as the 'outage' depicted on slide 8 of http://www.ieee802.org/3/10SPE/public/adhoc/brandt_101016_10SPE_01a_adhoc.pdf)

 

If the intent is (i) above, then I don’t think this will achieve the desired effect. If some property of the channel changes sufficiently to cause a

drop in SNR and a retrain, then in general I expect the new link that will be established will ultimately have the same SNR as if the retrain had not

been initiated. ie. the PHY should be continuously adapting its receiver at a fast enough rate to keep up with channel variation over time. I appreciate

that this may not be the case with existing PHYs which may not have been designed with industrial environments in mind, but for a new standard they

should be in which case I would argue that the requirement to keep up with channel variations is already implicitly covered in the existing objective:

'Support 10 Mb/s operation in industrial environments'

 

If (ii) is the intent then would it not simply be better to disable retraining when using PHYs in industrial applications ? (Equivalent to setting the retrain

duration to 0ms). 

 

Perhaps someone can clarify ?

 

Thanks, 

 

Oisín.