Toke Høiland-Jørgensen <t...@toke.dk> writes: > Felix Fietkau <n...@nbd.name> 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? :)
And to answer this: because the flow is being freed to be reassigned when it runs empty, but the counter is not decremented. Is this deliberate? I.e. is the 'flows' var supposed to be a total 'new_flows' counter and not a measure of the current number of assigned flows? -Toke -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
