[feature request] separate upload/download in bidirectional tests

[lukehsiao]

It seems the behavior right now for --bidir is just to sum the upload and download.

Instead, typically what I want as a user is to just know both directions separately, especially when the up/down are asymmetric.

As is, I still need to run xfr and xfr -R to get the information I want, rather than just --bidir.

[lance0]

Thanks for the report — this is a legitimate gap and a common iperf3-parity ask. You're right that for asymmetric links the combined number is nearly useless, and running upload + download separately defeats the purpose of --bidir.

Confirming what xfr currently reports in bidir mode:

• bytes_total = sent + received summed
• throughput_mbps = combined throughput in both directions

What iperf3 does (and what I'm guessing you'd want): separate send and recv lines in the summary, plus separate fields in --json output.

Straightforward to add — already have per-stream bytes_sent / bytes_received tracking internally. Just need to expose both in TestResult, split the plain text / JSON / CSV / TUI outputs, and likely keep the combined number for backward compat on existing scripts.

Scheduling this for a near-term release. A couple questions so I can nail the format you'd actually want:

1. Preferred JSON layout: flat (bytes_sent, bytes_received, throughput_send_mbps, throughput_recv_mbps) or nested (directions.send.bytes, directions.recv.bytes, ...)?
2. Plain text summary: iperf3-style two-line format (one for send, one for recv) plus a combined total, or just two lines without the sum?
3. Any existing tooling that parses the current bidir bytes_total you'd like us to preserve?

Thanks for opening this — will mark as an accepted feature and track.

[lukehsiao]

Thanks for opening this — will mark as an accepted feature and track.

Thanks!

Scheduling this for a near-term release. A couple questions so I can nail the format you'd actually want:

1. Preferred JSON layout: flat (bytes_sent, bytes_received, throughput_send_mbps, throughput_recv_mbps) or nested (directions.send.bytes, directions.recv.bytes, ...)?
2. Plain text summary: iperf3-style two-line format (one for send, one for recv) plus a combined total, or just two lines without the sum?

This is perhaps an unhelpful answer, but...any! I would defer to your taste here. I think either flat or nested or however you decide to do the plain text will be easy to adjust to.

3. Any existing tooling that parses the current bidir bytes_total you'd like us to preserve?>
   Thanks for opening this — will mark as an accepted feature and track.

For me personally, no, none. Even if there are others, I suspect this is easy to adjust to.

[lance0]

Hey @lukehsiao — opened #57 with the implementation. Settled on flat JSON fields and an iperf3-style three-line summary.

Plain text (bidir):

Transfer:    Send: 4.52 GB    Recv: 7.42 GB    (Total: 11.94 GB)
Throughput:  Send: 17.64 Gbps  Recv: 28.94 Gbps  (Total: 46.58 Gbps)

JSON adds bytes_sent, bytes_received, throughput_send_mbps, throughput_recv_mbps alongside the existing fields. CSV gets four new columns. TUI shows live ↑ / ↓ throughput in the stats panel during the test.

The combined bytes_total / throughput_mbps are kept for backward compat. Unidirectional tests are unchanged. No protocol break — older clients/servers gracefully degrade to the combined number.

Will ship in the next release once CI is green and you've had a chance to check it works for your asymmetric-link case. No rush.

[lukehsiao]

Will ship in the next release once CI is green and you've had a chance to check it works for your asymmetric-link case. No rush.

cargo install --locked --git https://github.com/lance0/xfr

server

❯ xfr serve
 INFO TCP listening on [::]:5201 (dual-stack)
 INFO QUIC server listening on [::]:5201 (dual-stack)
 INFO QUIC endpoint ready on port 5201
 INFO Registered mDNS service: redacted
 INFO Client connected: [::ffff:100.112.208.122]:64714
 INFO Test requested: TCP 1 streams, Bidirectional mode, 10s
 INFO Test c5ce25c0-ffb6-4ab6-9829-c1a1379f01e4 cancelled: User requested cancellation
 INFO Test c5ce25c0-ffb6-4ab6-9829-c1a1379f01e4 complete: 13.00 Mbps, 3418040 bytes
 INFO Client connected: [::ffff:100.112.208.122]:64722
 INFO Test requested: TCP 1 streams, Bidirectional mode, 10s
 INFO Test 594ebf5b-c27a-42aa-bd1a-804d85d884f6 complete: 14.45 Mbps, 19292116 bytes

client

❯ xfr redacted --bidir
────────────────────────────────────────────────────────────
  xfr Test Results
────────────────────────────────────────────────────────────

  Duration:    10.68s
  Transfer:    Send: 17.73 MB    Recv: 682.36 KB    (Total: 18.40 MB)
  Throughput:  Send: 13.9 Mbps  Recv: 0.5 Mbps  (Total: 14.4 Mbps)

  Sender TCP Info:
    Retransmits: 0
    RTT:         0.03ms
    RTT Var:     0.00ms
    Cwnd:        146 KB

────────────────────────────────────────────────────────────

This looks great, thank you!

I suppose it could be neat to also show the split in the server-side, but that's definitely not important compared to the win of the client-side change.

Throughput: Send: 17.64 Gbps Recv: 28.94 Gbps (Total: 46.58 Gbps)

Also, I want your Internet, sheesh! :P

[lance0]

🎉 Glad it works for your case — that 13.9 / 0.5 Mbps split is exactly the asymmetric scenario the old combined number was hiding.

Good call on the server-side split — opening a follow-up for that. Should be small (server already has the numbers, just needs to log them on completion). Will track separately.

Closing this once it ships. Thanks for the report and the validation!

(And 🙃 — the local network has its perks.)

[lance0]

Released in v0.9.8 — cargo install xfr works now (no need for the git install). Closing since you've already verified the fix; reopen if anything regresses.