Why field engineers carry iPerf3 on the phone
A field engineer's day is structured around 'turn it up, prove it works, get the sign-off.' The 'prove it works' step is where most of the friction lives. Carrying a laptop just to run iperf3 is overhead. Borrowing the customer's laptop is awkward and often blocked by policy. A native phone app that speaks the same iperf3 protocol removes both problems. The protocol is wire-identical to the standard iperf3 binary, so the customer's NOC sees the same numbers regardless of which side runs the phone. For circuit commissioning, that interoperability is the whole point.
Validating VPN throughput without surprises
VPN concentrators are a frequent source of post-install support tickets. The circuit shows full speed on direct testing, but throughput inside the VPN tunnel is half, or less. Causes range from CPU-bound encryption on older firewalls to suboptimal cipher negotiation to fragmentation triggered by an MTU mismatch. Running iPerf3 over the VPN tunnel and comparing to the same test outside the tunnel isolates whether the tunnel itself is the bottleneck. If it is, the data lets you push back to the VPN vendor instead of debating it abstractly. Without that data, the conversation is 'the customer thinks it's slow.' With it, it's '740 Mbps direct, 380 Mbps through tunnel. Please review the IPsec cipher set.'
Long sessions expose instability that short runs miss
Many circuits look great in a 10-second test and fall apart after a few minutes: TCP windows scale up, the buffer on a CPE saturates, retransmits climb. For circuits sold with SLA commitments, a 5-minute or 30-minute run is more representative than the default 10 seconds. The app lets you set test duration in settings and saves the full session. Looking at retransmits over time and the gap between average and 95th-percentile throughput is what catches a circuit that passes a nominal check and underperforms in service. That kind of finding is much easier to make stick when you have the session data exported.