Well, in my experience the dslreports speedtest for example is mostly self consistent when used with the same browser in similar conditions, and will for example show a clear increase in latency under load when I disable my traffic-shaper/AQM versus enabling that (shaped 100/36 versus unshaped 116/37). Since these increases are well reproducible I tend to trust that test, but I also do not put too much stock in its bufferbloat "grade" but always loot at the time resolved latency plots and compare those between different conditions. I also took care to properly configure that test in the first place.
Well my question is still open:
Sorry, I do not understand that question, could you maybe rephrase that?
I am sure I have no clue about the average user's set-up, so I do not mind threads like these that are tailored to some specific settings. At least over here PLC adapter are (unfortunately) quite popular and so the painted scenario does not sound outlandish to me. Sure, I would assume (not know) that many more users are bottlenecked by their WiFi link or WiFi mesh, but that still leaves the true bottleneck inside their home network. Sometimes these bottlenecks are properly debloated already (Openwrt with fq_codel in the WIFi stack and/or airtime fairness patches applied), some times these are stock proprietary solutions that range from competently done and bloat-free to painfully over-buffered and under-managed.
As I said in the second post, quite early on bufferbloat has been detected in switches and WiFi, which is not too surprising, as queueing will happen where ever there are speed transitions in a nework and unless these queues are properly sized and managed bufferbloat will show up if that link becomes the relevant bottleneck.
Whether bufferbloat matters or not is mostly a policy question each network admin needs to decide for herself, but I think it important to inform folks about bufferbloat and its consequences so these can be educated decisions.