Add DOM post-test deviation attributes, telemetry profiling TC#23356
Add DOM post-test deviation attributes, telemetry profiling TC#23356mihirpat1 wants to merge 5 commits intosonic-net:masterfrom
Conversation
|
/azp run |
There was a problem hiding this comment.
Pull request overview
Updates the transceiver DOM and system test plan documentation to add configurable post-test deviation validation attributes and define a new telemetry update interval profiling test case, while clarifying prerequisite failure behavior.
Changes:
- Documented new DOM post-test deviation attributes (upper/lower bounds) and added a post-test deviation validation rule.
- Added a new “Telemetry update interval profiling” advanced DOM test case with configurable polling interval/duration attributes.
- Clarified prerequisite-test failure semantics in both DOM and system test plans.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| docs/testplan/transceiver/dom_test_plan.md | Adds new post-test deviation attributes/rule, updates dom.json example, expands advanced test cases, and introduces telemetry update interval profiling TC. |
| docs/testplan/transceiver/system_test_plan.md | Adds a note documenting how prerequisite test case failures affect dependent system test cases. |
|
/azp run |
|
/azp run |
Signed-off-by: Mihir Patel <patelmi@microsoft.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com>
Signed-off-by: Mihir Patel <patelmi@microsoft.com>
b7696fb to
1743d52
Compare
|
/azp run |
Signed-off-by: Mihir Patel <patelmi@microsoft.com>
|
/azp run |
| | telemetry_profile_poll_interval_sec | integer | 10 | O | transceivers or platform_hwsku_overrides | Polling interval in seconds for the telemetry update profiling test | | ||
| | telemetry_profile_duration_min | integer | 10 | O | transceivers or platform_hwsku_overrides | Duration in minutes to run the telemetry update profiling test | | ||
|
|
||
| **Post-test range rule:** For tests that restore a port to steady-state operation, verify each post-test DOM reading falls within its configured `{"min", "max"}` range. The check applies only to attributes that are present in the configuration (`min <= post-test value <= max`). Lane-based entries such as TX bias and TX/RX power use the `LANE_NUM` expansion and are validated per lane. The test fails if any enabled field falls outside its configured range. |
There was a problem hiding this comment.
It would be good to clarify that the post-check is looking for relative changes based on the first (or average) measurement. Something like min <= post-test value - first-read value <= max
| "MMA1T00-VS-400G": { | ||
| "temperature_threshold_range": {"lowalarm": -30.0, "lowwarning": -10.0, "highwarning": 75.0, "highalarm": 85.0} | ||
| "temperature_threshold_range": {"lowalarm": -30.0, "lowwarning": -10.0, "highwarning": 75.0, "highalarm": 85.0}, | ||
| "voltage_deviation_range": {"min": 3.25, "max": 3.45}, |
There was a problem hiding this comment.
These thresholds use absolute values, not relative values.
Suggestions are:
"voltage_deviation_range": {"min": -0,2, "max": 0,2},
"laser_temperature_deviation_range": {"min": -10, "max": 10},
"txLANE_NUMbias_deviation_range": {"min": -5, "max": 5},
"txLANE_NUMpower_deviation_range": {"min": -0.2, "max": 0.2},
"rxLANE_NUMpower_deviation_range": {"min": -0.5, "max": 0.5}
Signed-off-by: Mihir Patel <patelmi@microsoft.com>
|
/azp run |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
|
AI agent on behalf of Ying.\n\nI found issues that need attention.\n\n |
yxieca
left a comment
There was a problem hiding this comment.
AI agent on behalf of Ying. Reviewed; no issues found.
Description of PR
Summary:
Add post-test deviation validation attributes, a new telemetry update interval profiling test case, and clarify prerequisite failure behavior in DOM and system test plans.
Type of change
Back port request
Approach
What is the motivation for this PR?
Tests that restore the port to steady-state operation (e.g., interface shutdown/startup, DOM polling toggle) had no way to verify that sensor readings returned to acceptable levels. Additionally, there was no test to profile DOM telemetry update intervals for cross-release regression detection. Finally, the prerequisite failure behavior was undocumented.
How did you do it?
Please refer to the HLD diff
How did you verify/test it?
Documentation-only change — reviewed for internal consistency across attribute table, example JSON, post-test deviation rule, and test case steps/expected results.
Any platform specific information?
N/A — deviation attributes are optional and configured per-transceiver in
dom.json.Supported testbed topology if it's a new test case?
N/A — test plan documentation update only.
Documentation
Updated
docs/testplan/transceiver/dom_test_plan.mdanddocs/testplan/transceiver/system_test_plan.md.MSFT ADO - 37280302