> There is probably also a tradeoff in how long you hold back packets while waiting for more data to show up;
Also recall that a transmit has to adhere EDCA and NAV. If energy detect or virtual carrier are active the device "backs off" and arbitrates again. Then there is the encoding and number of spatial streams which influence propagation delay.
So packet queues aren't typically the bottleneck in uncongested scenarios and aren't the forcing function for end/end latency. It's typically related to the RF conditions which includes energy by peers, same BSS or otherwise. Then there is OS related stuff with respect to writes and reads that can add latency per thread scheduling. That's another reason why it helps to measure end/end latency which includes application level writes and reads.
The following components of latency might be helpful:
Propagation delay
Amount of time required for a message to travel from the sender to receiver, which is a function of distance over speed with which the signal propagates.
Transmission delay
Amount of time required to push all the packet’s bits into the link, which is a function of the packet’s length and data rate of the link.
Processing delay
Amount of time required to process the packet header, check for bit-level errors, and determine the packet’s destination.
Queuing delay
Amount of time the packet is waiting in the queue until it can be processed.
Bob