Felix Fietkau <[email protected]> writes: > - if I put a hack in the fq code to force the hash to a constant value > (effectively disabling fq without disabling codel), the problem > disappears and even multiple streams get proper performance.
There's definitely something iffy about the hashing. Here's the output relevant line from the aqm debug file after running a single TCP stream for 60 seconds to that station: ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit collisions tx-bytes tx-packets wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925 (there are two extra fields here; I added per-txq CoDel stats, will send a patch later). This shows that the txq has 146 flows associated from that one TCP flow. Looking at this over time, it seems that each time the queue runs empty (which happens way too often, which is what I was originally investigating), another flow is assigned. Michal, any idea why? :) -Toke -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
