3 ms·
Fundamental engineering debugging process is similar. I recently debugged packet issues after 100gbps port speed change to 25gbps, to 10 gbps issues. Break
by srcmap 9y ago
Fundamental engineering debugging process is similar.
I recently debugged packet issues after 100gbps port speed change to 25gbps, to 10 gbps issues. Breakdown the issue to sub-system components - check phy, mac loopback, check link status on both side of the QSFP connections before and after speed changes, check counters (A LOT of them), enable debug packet to send to CPU with special command. Check all the VLAN, port settings, configuration commands over and over again. Enable debugging on kernel driver to track down every bytes/bits of every packet. Use tcpudmp on linux socket layer when one gets to that point.
Instead of oscilloscope, today's SOC does have a lot of counters inside that help one identifies issues.
For complex issue, one does get tremendous high when the issue was ID and resolved.
- nerpderp83 9y ago> one does get tremendous high when the issue was ID and resolved I find getting a little high really helps with long debugging sessions.
- planteen 9y agoSure, that is very true during development or debugging a complex production issue as you mentioned. I meant troubleshooting and reworking along the lines of "this board used to work, now it doesn't". Most reworks I see of boards involve replacing parts, which in a modern Ethernet design would consist of the jack, some magnetics, PHY, and SoC.