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

Hi Adam, George,

I was wrong, wherein my proposal of edge-detect does not address the underlying issue.

My original thinking was that if the optimum sampling phase landed on the edge of the local search window, the optimizer could detect the condition and either:

A. Temporarily expand the search window (edge-detect approach), or

B. Dynamically increase the Local Search radius for itick pruning (adaptive-radius approach).

The optimizer is not tracking a slowly varying phase in time. Instead, it is moving between different equalization configurations, where the optimal sampling phase can potentially change significantly from one configuration to the next.

In other words, these methods may help with gradual drift of the optimum, but they do not solve the more general acquisition problem if the optimal sampling phase changes substantially between equalizer settings.

George's acquisition-versus-tracking analogy helped me clarify this. The Local Search mechanism behaves more like a tracking algorithm and therefore assumes that a valid sampling phase has already been acquired. Neither edge detection nor adaptive-radius expansion guarantees recovery when that assumption is violated.

I will share with you Adam the results of the 684 cases involving all the CR and KR channel part of the IEEE 802.3dj Public Area for without and with itick pruning.

Regards,

Hansel D'Silva

Standards Development Engineer- Amphenol

From: Hansel DSilva <00004708d0869f3e-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 2, 2026 6:55 PM
To: STDS-802-3-COM@xxxxxxxxxxxxxxxxx <STDS-802-3-COM@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_COM] local optimized phase search

CAUTION: EXTERNAL EMAIL

Hi Adam,

George got a point, but Hossein mentioned that he saw a significant higher value of COM when changing the sample_adjustment from [-24 24] to [-32 32], which got me thinking.

May we should consider adding an "edge-detect mechanism" as a safety enhancement on top of your Local Search itick pruning? Please review the attached optimize_fom.m (rename _ItickPruningEdgeDetect.txt to .m), will need to clean it a but though.

At the present, it only evaluates iticks within +-LOCAL_SEARCH of the current best itick.

=> For example, BEST.itick= -6 and LOCAL_SEARCH= 2

=> Then only these itick are evaluated: [-8 -7 -6 -5 -4].

=> After evaluating the window, the BEST.itick= -8 and now it landed on the edge of the allowed window.

=> The FOM may still improve if we move to the left, but the optimizer does not know whether -8 is really optimal or whether -9, -10 or -11 would be even better.

The proposed edge-detect mechanism monitors whether the winning sampling phase lands on the boundary of the Local Search window. When an edge hit occurs, the search radius is automatically expanded for the next sweep, reducing the risk of missing an optimum FOM that has migrated outside the current search range.

Importantly, a single edge hit does not permanently enlarge all future searches. The expansion only applies to the subsequent sweep, after which the algorithm returns to the nominal Local Search radius unless another edge hit is detected.

I am evaluating the 684 cases to evaluate the itick pruning with and without the edge detect.

Regards,

Hansel D'SIlva

Standards Development Engineer- Amphenol

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 1, 2026 8:20 PM
To: STDS-802-3-COM@xxxxxxxxxxxxxxxxx <STDS-802-3-COM@xxxxxxxxxxxxxxxxx>
Subject: [802.3_COM] local optimized phase search

CAUTION: EXTERNAL EMAIL

This is the first time you received an email from this sender (george@xxxxxxxxxxxxxxxxxxxx). Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

I believe the situation being discussed on the call where the phase search appeared ill-behaved was one where the optimum sampling phase was not within the initial sweep or a valid FOM had not yet been found (e.g., because the sweep was too coarse). The local search shoudl behave similar to acquisition and tracking of sampling phase. Once you find a valid sampling phase, you generally don't lose it except in very pathological channels (e.g., with unterminated stubs, which we generally don't see). Such channels would be problematic anyways, as tracking loops would also get stuck in these local minima.

Note that slide 3 of the presentation (https://www.ieee802.org/3/ad_hoc/COM/public/telecon/260901/gregory_COM_01_260901.pdf) states the requirements below and specifically warns against this. The resolution of the initial sweep needs to be sufficient to sample the open eye (which I believe is needed for a valid FOM, if I understand the statement below correctly)

The text from slide 3 is below. It may be useful to consider better guidance on just what "far away" is.

-george

(from slide 3)

It requires:

• Valid FOM has been found

• Local Search is enabled

• One full sweep of sampling phase has finished

If the current sample phase is far away from the best sample phase, don’t run it. Far away is defined by the Local Search parameter, which is usually set to 2

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

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