Post B6nPVQjgCCfi45Bowq by manawyrm@chaos.social
 (DIR) More posts by manawyrm@chaos.social
 (DIR) Post #B6n68q8PhOIH35H0YS by manawyrm@chaos.social
       1 likes, 1 repeats
       
       Modern PC hardware is real RF voodoo these days: DDR5 runs at 5+ GHz, PCIe 5.0 runs at 16 GHz (!!), networking/SFPs running at 26+ GHz, often using advanced modulation like PAM4.All of those ultra high speed links are doing some form of equalization/link training and their hardware is very often capable of measuring/reporting eye diagrams.
       
 (DIR) Post #B6n69ZLPbuQhGQhWYy by manawyrm@chaos.social
       1 likes, 2 repeats
       
       Very few devices are capable of reporting these stats, though. Some Mellanox NICs can, some Ampere server CPUs can.Why isn't there tooling to view/check the link budgets/eye diagrams on (for example) regular AMD CPUs?I'm sure it exists, just hidden away under NDA.Being able to measure, plot and alert with link budget values in a data center at scale (or even just a single home PC?) could be extremely helpful.
       
 (DIR) Post #B6n69vtBn0WJBYfoGW by manawyrm@chaos.social
       1 likes, 0 repeats
       
       Dirty contacts on memory modules, improperly seated CPUs, wrong CPU cooler mounting pressure, defective transmitters/receivers, etc. could maybe be detected before they become an actual problem.I'm guessing that monitoring such parameters could catch reliability issues early, allowing operators to swap hardware before it completely dies, possibly corrupting data in the process (or causing packet loss on network links).Thoughts? Have you seen such tooling?
       
 (DIR) Post #B6nBVLpR2emNUGwxBw by wolf480pl@mstdn.io
       0 likes, 0 repeats
       
       @manawyrm My gut feeling is if anyone would want to, and have the leverage to, expose that info to the end user, it'd be Oxide.
       
 (DIR) Post #B6nPVQjgCCfi45Bowq by manawyrm@chaos.social
       0 likes, 1 repeats
       
       I've built a project in the past, monitoring both the link parameters of fiber optic links (SFP transceivers) and signal quality of the actual signal (timing margin, BER, etc.).This allowed us to notice failing laser diodes, failing receivers, subtly broken cabling, dirty connectors, broken network cards, etc. before they ever became an outage or had a chance to cause packet loss.Having the same for DDR, PCIe, maybe even USB, Thunderbolt, etc. seems useful?
       
 (DIR) Post #B6nPVRAGbLwHOXd3OC by manawyrm@chaos.social
       0 likes, 1 repeats
       
       Imagine if the Linux kernel could output warnings in dmesg going "PCIe device xx:yy.z has insufficient timing margin, please clean connectors."
       
 (DIR) Post #B6nXVrDeWwOdppvLiy by linear@nya.social
       0 likes, 0 repeats
       
       @manawyrm@chaos.social if this were a common and normal feature on embedded linux SoCs with PCIe, it would have saved me a great deal of pain in my day job