I have experienced the ‘specks of packet loss’ thing and sometimes it really really kills downstream performance. Some server in the internet not using BBR then, methinks. Either that or the actual packet loss is rather worse than I can see in the clueless graphs from the dripping blood specks. Perhaps you can only see a speck given the low res of the graphs when there is a short-ish period of sustained packet loss or a cluster of non adjacent loss events. On Saturday I was getting diabolical speed tester results in both directions and experiencing really poor downstream performance in Zoom. I couldn’t work it out. Started hunting for a rogue background downloading process on some machine or other, couldn’t see such associated traffic in the clueless graphs though. So I suddenly thought about the specks I could see for my line 2. I forced a resynch of line 2 and fixed the problem!
All a bit mysterious, but to sum up: the theory is that there was line 2 packet loss, almost invisible, presumably downstream, and it would have to be the case that even a small amount was having a really bad effect on eg TCP without BBR. By the way, my available line 2 modem stats did not help much as the time periods covered were either too recent and short, or way too long, so I could not tell when any reported ES or CRC errors were. The problem’s perceived effects were always present, not coming sporadically, so the packet loss would have to be occurring at least at a low level all the time.
It would be nice to have a packet loss thrash tester program, looking for unnatural packet loss only, that is, and I would also need an easy mechanism if directing stuff to one line downstream or upstream. Downstream would require me to untick all the per-line tick boxes in clueless apart from the line under test. Upstream would require awkward messing around damaging my Firebrick’s config, with a backup, tweak and restore being needed.