web: the Monitor page headlines the PCIe max capability as the link speed - a downgraded link shows "Gen3 · idle Gen1"
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 80/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- frontend
Research direction
The metric renderer is in serve/web/app.js; start by reading the PCIe metric code shown in the issue and trace how it uses gpu_pcie_gen and gpu_pcie_gen_max. Feed it the hardware-independent sample from the issue and confirm it shows Gen1 with Gen3 capability context; done when the current generation is the headline and below-capability wording is neutral.
Written by the indexing model from the issue text.
Description
What is wrong
The Monitor page's PCIe metric headlines the link's capability, not the link's speed, and describes a below-capability link as idle power saving:
const gen = hw.gpu_pcie_gen_max || hw.gpu_pcie_gen;
setMetric("pcie", gen ? `Gen${gen}` : null, ..., ` · idle Gen${hw.gpu_pcie_gen}` ...)
So a downgraded link shows as "Gen3 · idle Gen1". That reads as "the link is Gen3, currently idling at Gen1" - but on a link whose Gen3 training failed, the link never reaches Gen3 under load either, and "idle" is exactly the wrong word: the link is downgraded, not resting.
Expected / Actual
Expected: the PCIe metric shows the link's current generation, with the capability as context.
Actual: it shows the capability as the headline (Gen3) and labels a below-capability link as idle ( · idle Gen1) - on a downgraded link, idle power saving is exactly what is not happening.
Why it matters (a real case)
Found while measuring the PCIe tier for the prefix-reuse series in #2099. This GTX 1080 Ti box: LnkSta: Speed 2.5GT/s (downgraded), Width x16 on both the card and the root port (LnkCap 8GT/s, Target 8GT/s), so the link never leaves Gen1. Root cause found later (and worth recording): a leftover driver option, NVreg_RegistryDwords="...;RmDisableGen2LinkRetraining=1" in /etc/modprobe.d/nvidia.conf, suppresses link speed retraining outright - LnkSta2 shows the root port's equalization completed while the card's never ran (PerformEqu=0, the request left pending), which is "driver never starts it", not "signal fails". Measured over a 171 s sustained cold prefill (147 s of >2 GB/s streaming):
- 8,859 link-gen samples (sub-second, idle baseline included): Gen 1 at every sample, never >= 3
gpu_pcie_rx_mbpeak 3,191 MB/s - pinned at the Gen1 x16 practical ceiling (~3.2 GB/s)- the Monitor page nevertheless showed "Gen3 · idle Gen1" the whole time
On this machine the PCIe tier is the prefill bottleneck (81% duty at the Gen1 ceiling), and the one number that would have pointed at it was displayed as fine. The telemetry data is already correct (gpu_pcie_gen vs gpu_pcie_gen_max); only the rendering picks the wrong one as the headline.
Suggested fix
Headline the current generation and keep the capability in the note with neutral wording (one sample cannot tell idle power-saving downtrain from a permanent downgrade):
const cur = hw.gpu_pcie_gen, gen = hw.gpu_pcie_gen_max || cur;
setMetric("pcie", (cur || gen) ? `Gen${cur || gen}` : null, ...,
... + (cur && gen && cur < gen ? ` · below its Gen${gen} capability` : ""));
We run this on the box here (installed copy) and can send it as a PR - it is a three-line change in serve/web/app.js. A further refinement if wanted: when recent history shows the link below capability under load (say gpu_pcie_rx_mb above some threshold while gpu_pcie_gen stays below max), the note could say "downgraded" instead, which is the case worth acting on.
How to verify the fix
Hardware-independent: feed the metric renderer hw = {gpu_pcie_gen: 1, gpu_pcie_gen_max: 3, gpu_pcie_width: 16} and check it renders Gen1 (with the capability in the note), not Gen3. On a healthy link the two renderings agree, which is why the wrong one went unnoticed.
- Dominant language
- C++
- Stars
- 11.6k
- Forks
- 1k
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Niko1221/Strata
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
BENCH.bat crashes on Japanese-locale Windows: UnicodeDecodeError (cp932) reading CMakeLists.txtOpen
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
IPv6 not supportedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Niko1221/Strata#2592 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
NVIDIA-RTX/NRI#277 ·
Maintainers usually reply within 1 day
-
os:Linux
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
acceptable_buffer_backends: unknown backend names are silently ignoredPossibly taken @mini-1235 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ros2/rmw_fastrtps#945 ·
Maintainers usually reply within 1 day