Bug 165969

Summary: [ath] Slower performance in adhoc mode vs Client/AP mode, same HW
Product: Base System Reporter: Johann Hugo <jhugo>
Component: wirelessAssignee: freebsd-wireless (Nobody) <wireless>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 9.0-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
athregs-FreeBSD-7.4-STABLE.txt
none
athregs-FreeBSD-8.0-RELEASE.txt none

Description Johann Hugo 2012-03-12 11:00:26 UTC
I get lower throughputs in adhoc mode, compared to AP/client mode for 
the same two devices.

AP -> client            iperf   27.2 MBytes  28.8 Mbits/sec
adhoc -> adhoc          iperf   12.1 MBytes  21.3 Mbits/sec

dev.ath.0.stats.ast_tx_longretry is more than double in adhoc mode.

The two devices are directly next to each other in the LAB
HW platform = Gateworks Avila GW2348-4
Wifi adapters = Compex WLM54AGP23
Atheros driver from +- 10 Jan 2012
OS = FreeBSD 9.0-STABLE

Adhoc mode for FreeBSD 9.0-STABLE (as well as FreeBSD 8.0-STABLE) are also slower than adhoc mode for FreeBSD 7.2-STABLE

9.0-STABLE  adhoc -> adhoc  iperf   21.3 Mbits/sec
8.0-STABLE  adhoc -> adhoc  iperf   21.3 Mbits/sec
7.2-STABLE  adhoc -> adhoc  iperf   25.1 Mbits/sec

How-To-Repeat: - Place two wifi nodes next to each other. 
- Configure one device into AP mode and the other onto client mode.
- Do an iperf between the two nodes.

iperf  28.8 Mbits/sec

- Now use the same two devices and configure them into adhoc mode.
- Do an iperf between the same two nodes.

iperf  21.3 Mbits/sec
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-03-12 11:36:12 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:47 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.