21 lines
2.0 KiB
Markdown
21 lines
2.0 KiB
Markdown
# Goals
|
|
|
|
cabletest finds Ethernet cables that misbehave under sustained full-duplex 10 Gbit load. It exchanges raw Ethernet frames (no IP, no ARP) across a variety of sizes and payloads between two directly-cabled ports on one host, and attributes every problem it can to the cable rather than the host. It runs as PID 1 on a dedicated appliance with a framebuffer UI; development happens on the same machine under Arch.
|
|
|
|
The target of measurement is the cable, not throughput. Line rate is a means to stress the physical layer.
|
|
|
|
## Outputs, in priority order
|
|
|
|
1. **Loss and error attribution** — reception gaps, link errors, NIC/driver counters as first-class output alongside application loss. Baseline loss must be exactly zero before a run counts; any host-side loss masks real cable faults.
|
|
2. **Noise tolerance** — a deliberately-bad "noise" cable intertwined with the test cable, driven by link up/down cycling, stresses the cable under test with alien crosstalk.
|
|
3. **Per-pair SNR** from the module PHYs — the leading indicator of a marginal cable before it drops frames. IEEE 802.3an standard registers on the Marvells; the BCM leaves those unpopulated and reports through its vendor command handler instead (modules/fs/).
|
|
4. **Cable length** — sanity check and fault localization. The BCM ECD is the product path: per-pair lengths in meters, healthy pairs included, proven meter-accurate on the bench (modules/fs/).
|
|
5. **Pre-FEC error visibility** — corrected-error counters that move before post-FEC loss appears. Vendor-specific; located on the Aquantia (modules/fibergaga/), unlocated elsewhere. Standard latched PCS counters (errored blocks, BER, block-lock loss) are the working proxy under noise stress.
|
|
|
|
## Design preferences that shaped the tool
|
|
|
|
- Plain sockets first, escalate only after measuring: AF_PACKET reached line rate on the shipping mix; the AF_XDP experiment is parked.
|
|
- Pre-populated frame contents.
|
|
- Goroutine-heavy is fine — many cores to burn.
|
|
- DPDK is off the table: it would kill the sysfs counters and link management the tester depends on.
|