Performance and resilience validation method
Validate bonding performance and application resilience
This is a repeatable test method for your configured deployment. It explains what to record and how to compare outcomes; it does not present a measured Mushroom Networks benchmark or a guaranteed speed, recovery time or availability figure.
Controlled peered-bonding test path
- LAN test hostKnown client and tool version
- Mushroom routerRecorded model, firmware and routes
- WAN pathsRecorded links and test conditions
- Relay / serverRecorded service and endpoint path
- Remote test hostControlled receiver beyond the relay
Define the test configuration
Use a controlled LAN test computer and a controlled remote test computer reachable beyond the selected relay. Confirm the approved test window and endpoint access policy. Keep the local LAN, remote host, test tool and server/network capacity suitable for the connection mix.
| Area | Record | Why it matters |
|---|---|---|
| Appliance and software | Exact model, hardware/modem configuration, firmware, tunnel/service profile, licence/options and QoS/shaping policy. | Different configurations and profiles have different limits. A brochure maximum alone is not the test configuration. |
| WAN connections | Provider/plan, modem/interface, direction, standalone link baseline, latency/loss/jitter, antenna/location conditions and configured rates. | Changing access-link conditions affect both the baseline and the combined result. |
| Relay and addressing | Cloud or customer-hosted endpoint, location, route/return-route policy, egress/cloud IP behaviour and active encryption/authentication settings. | An “up” tunnel does not establish which test traffic uses it or the path/cipher actually selected. |
| Test hosts and method | Tool/version, client/server network interfaces and CPU limits, protocol, direction, data-flow count, duration, timestamps and repetitions. | Results can be limited by the test hosts, tool behaviour or measurement method. |
Choose the acceptance criteria for the application and network before running the trials. Keep the relevant configuration constant when comparing modes; record any change rather than attributing it automatically to bonding.
Separate single-session and concurrent throughput
- Establish each WAN baseline. Verify the route uses the intended individual link and record usable payload throughput in each direction under the same test-host conditions.
- Confirm the peered test path. Verify the test traffic and replies enter the intended tunnel and monitor the eligible WANs. Review any binding, capture-all or QoS rules that could restrict the flow.
- Run a single TCP data-flow trial. Record the receiver’s payload throughput and the per-WAN/device counters. This is a different question from the aggregate result of several separate sessions.
- Repeat in the reverse direction. Uplink and downlink can have different limits and WAN conditions.
- Run a concurrent-session trial. Compare multiple data flows separately from the single-flow result. Load balancing can use several WANs across independent sessions; that result alone does not demonstrate single-session packet bonding.
- Repeat and preserve the raw outputs. Keep the test period, configuration and baseline alongside the variation between runs. Identify any test-host/server or service limits.
Example TCP commands on the test computers
The following examples use a 60-second trial and JSON output. This is an example test duration, not a performance or recovery result. Check the installed tool’s manual and choose a suitable duration for the workload.
On the controlled remote test host:
iperf3 -sFrom the LAN test host, with one data flow:
iperf3 -c TEST_SERVER -P 1 -t 60 -JRepeat with server-to-client traffic:
iperf3 -c TEST_SERVER -P 1 -t 60 -R -JReplace TEST_SERVER with the controlled endpoint. For a concurrent trial, set -P 4 and record the four-flow result separately. Use the official iperf3 invocation reference for the installed version’s options. Run other protocols or application workloads as separate, documented trials.
iperf3 also uses a separate control connection. The parallel setting counts data streams; when checking WAN use, distinguish the test payload from control or unrelated background traffic.
Compare delivered application payload, not just the sum of interface counters. Tunnel overhead, retransmissions and reliability handling can make on-wire traffic different from useful payload throughput.
Test changing paths and the real application
| Trial | Keep / change | Observe and record |
|---|---|---|
| One WAN disconnected | Maintain the application session; remove one access path on a test network. | Application reconnects, gaps or freezes; tunnel state; source-IP behaviour; delivered throughput and remaining capacity. |
| Reduced capacity or impaired path | Introduce a controlled capacity change, loss or delay on a test path and record the impairment. | Adaptation over time, QoS under competing traffic, receiver quality and the usable remaining path capacity. |
| WAN restored | Restore the impaired/disconnected path under the same policy. | Return to normal path use, application behaviour and any recovery/rebalance period observed. |
| No usable WAN or unavailable relay | Exercise these expected failure cases in the test setup. | Application interruption and recovery behaviour. Resilience is conditional on a usable path and reachable endpoint. |
| Voice / conferencing | Use the actual phone/PBX or meeting workflow, routes, codec and QoS policy. | Audio gaps, application reconnects, signalling/media in both directions and measured latency/jitter/loss at the stated observation point. |
| Live encoded video | Use the real encoder, stream protocol, bitrate, relay, play-out policy and receiver/player. | Receiver continuity, sender/play-out delay, delivered bitrate, audio/video sync and end-to-end production delay. |
Keep the observation points clear: access-link loss, tunnel counters and packet loss seen by the receiving application are different measurements. Video production delay also includes encoder, relay/buffer and receiving-player behaviour. A router status indicator alone does not establish the user’s experience.
Report the results with their limits
- Keep the exact topology/configuration, raw outputs, trial timestamps, duration, repetitions and the relevant WAN baselines.
- State units and the observation point for each result. Report the range between runs, any application interruptions and the controlled impairment/failure event.
- Separate observations from expectations. A configured capability or a successful short trial is not an annual availability measurement.
- For an availability claim, define the service/application, observation period, available/unavailable criterion and exclusions. For a cost comparison, define the sites, services, dates, recurring charges and like-for-like scope.
- For public customer evidence, confirm the customer’s permission, deployment period, model/connection mix, outcome and the source of each figure before publication.
Download the blank measurement worksheet
The worksheet contains trial names and empty configuration/result fields. It is a recording template, not a dataset of test results.