Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > Grant Grundler <grundler@xxxxxxxxxx> writes: > >> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: >>> >>> Grant Grundler <grundler@xxxxxxxxxx> writes: >>> >>> >> And, well, Grant's data is from a single test in a noisy >>> >> environment where the time series graph shows that throughput is all over >>> >> the place for the duration of the test; so it's hard to draw solid >>> >> conclusions from (for instance, for the 5-stream test, the average >>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7 >>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware >>> >> used in this test, so I can't go verify it myself; so the only thing I >>> >> can do is grumble about it here... :) >>> > >>> > It's a fair complaint and I agree with it. My counter argument is the >>> > opposite is true too: most ideal benchmarks don't measure what most >>> > users see. While the data wgong provided are way more noisy than I >>> > like, my overall "confidence" in the "conclusion" I offered is still >>> > positive. >>> >>> Right. I guess I would just prefer a slightly more comprehensive >>> evaluation to base a 4x increase in buffer size on... >> >> Kalle, is this why you didn't accept this patch? Other reasons? >> >> Toke, what else would you like to see evaluated? >> >> I generally want to see three things measured when "benchmarking" >> technologies: throughput, latency, cpu utilization >> We've covered those three I think "reasonably". > > Hmm, going back and looking at this (I'd completely forgotten about this > patch), I think I had two main concerns: > > 1. What happens in a degraded signal situation, where the throughput is > limited by the signal conditions, or by contention with other devices. > Both of these happen regularly, and I worry that latency will be > badly affected under those conditions. > > 2. What happens with old hardware that has worse buffer management in > the driver->firmware path (especially drivers without push/pull mode > support)? For these, the lower-level queueing structure is less > effective at controlling queueing latency. Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377 PCI devices, which IIRC do not even support push/pull mode. All the rest, including QCA988X and QCA9984 are unaffected. -- Kalle Valo
