I can't say I've seen comments here about how SNRM held up, though if it were only certain frequencies being impacted you're at the mercy of how it's being calculated.
You mentioned flow control earlier. A properly working TCP connection should not show abrupt drops in throughput once ramped up given modern TCP stacks.
The throughput should show a tiny sawtooth effect that is imperceptible. A big drop indicates congestion control kicking in - a different issue and one indicative of a possible fault.
Packet loss would trigger congestion control, not flow control.
Congestion control is about avoiding flooding the network with data it won’t be able to handle, not necessarioy related to DSL error rates.
Flow control occurs when the receiver is unable to accept the data at the rate it is being presented. If for example, the receiver simply unplugs a local ethernet cable, then the incoming data will be buffered up to a point but when the buffers are full, flow control will kick in to tell the sender to stop transmitting, and the connection will fall silent.
Error recovery is a different process to either of these, but can also cause a glitch. That’s the scenario that would be attributable to home plug interference.
@cbdeakin, I think you said you are running this test over WiFi. Have you tried to negotiate an agreeable time with other occupants to temporarily disconnect all home plugs, and run the same test in those circumstances?