Not at all - well worth investigating.
In semi-lay terms (based on a very foggy memory from diagnosing all this about years back) ADSL/2/2+ VDSL/2 all use HF signalling over copper using Discrete Multi Tone spread out over many sub-channels or bins in the bandwidth of the standard - up to 2.2 Mhz for ADSL2+ and 12 Mhz for VDSL2. Each of these bins as a given bit loading based on the frequency response of the bin, which is determined when the connection is established with the DSLAM or node. Once the router has worked out the deal with the DSLAM/Node, it literally enters a state called “Showtime” or at least that was the case for ADSL2+. I always had a giggle with that.
At the time, I had a router that gave a detailed log of the negotiation and establishment - and with a command from memory like “show dsl int atm0” it would display loads of data including a very handy table of “DMT bits per bin” …
OK, so here’s an email I just located which shows the detail from one of my sessions …
> show dsl int atm 0 ATM0 Alcatel 20190 chipset information ATU-R (DS) ATU-C (US) Modem Status: Showtime (DMTDSL_SHOWTIME) DSL Mode: ITU G.992.1 (G.DMT) Annex A ITU STD NUM: 0x01 0x1 Vendor ID: 'STMI' 'BDCM' Vendor Specific: 0x0000 0x93D1 Vendor Country: 0x0F 0xB5 Chip ID: C196 (0) DFE BOM: DFE3.0 Annex A (1) Capacity Used: 100% 99% Noise Margin: 3.0 dB 10.0 dB Output Power: 19.5 dBm 12.5 dBm Attenuation: 54.5 dB 31.5 dB FEC ES Errors: 0 0 ES Errors: 19 2 SES Errors: 0 0 LOSES Errors: 0 0 UES Errors: 0 0 Defect Status: None None Last Fail Code: None Watchdog Counter: 0xB5 Watchdog Resets: 0 Selftest Result: 0x00 Subfunction: 0x00 Interrupts: 16566 (0 spurious) PHY Access Err: 0 Activations: 2 LED Status: ON LED On Time: 100 LED Off Time: 100 Init FW: init_AMR_4.0.018.bin Operation FW: AMR-E-4.0.018.bin FW Source: external FW Version: 4.0.18 Interleave Fast Interleave Fast Speed (kbps): 5504 0 864 0 DS User cells: 2774731 0 US User & Idle cells: 4529182 0 Reed-Solomon EC: 55312 0 1 1 CRC Errors: 10 0 1 0 Header Errors: 12 0 1 0 Total BER: 1059E-9 0E-0 Leakage Average BER: 1059E-9 0E-0 ATU-R (DS) ATU-C (US) Bitswap: enabled enabled LOM Monitoring : Enabled LOM watch configured for 250 times LOM appeared continuously for 0 times DMT Bits Per Bin 000: 0 0 0 0 0 0 0 8 A A A B B B B B 010: B B B B B B B B A A A A A 9 9 8 020: 0 9 A A B C C C C D D D D D D D 030: C D D D D D E E D E E D D D D D 040: 0 D D D D D D D 2 C C C C B 9 B 050: B B B B B B B A 9 A 9 A A B B B 060: B B 9 9 A B B 9 B A B A A A 9 9 070: A B B B A A 8 A A A A A 9 9 9 9 080: 9 9 8 8 7 7 7 7 7 7 7 7 7 7 7 7 090: 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 0A0: 8 8 8 8 8 7 6 8 8 7 7 7 7 7 7 7 0B0: 7 7 7 7 7 4 0 5 6 7 7 7 6 6 6 6 0C0: 6 5 5 5 5 5 5 5 5 4 4 4 4 4 4 3 0D0: 0 0 3 3 3 3 2 0 0 0 0 0 0 0 0 0 0E0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0F0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 DSL: Training log buffer capability is not enabled >
Now if we hop over to a site like this: Nigel Franklin: Charting DMT bits per Bin data from xDSL routers
We can paste in that DMT bits per bin data and see a graph of essentially how good our connection is based on the frequency respinse of the line/etc …
Now to illustrate, lets assume someone turns on a device that creams a really consistent chunk of the HF spectrum we are using on xDSL - to demonstrate this, I’ve just edited the DMT bits per bin to zero for a big chunk on this handy graphing site …
All those nicely coloured lines are bits in your bins the taller they are is how good each bin is - all the bins together make up your aggregate bandwidth. Small lines or big chunks missing is bad. HF interference can do this. Ethernet over powerline is just one potential source of HF interference, others include televisions, set top boxes, AM radios, mothers in law - ok I made that one up, but you might find it useful. To be fair, the ham living next door to you, running his linear amp and rag-chewing with a guy in Lithuania is also a potential source of HF badness from an xDSL perspective … and if the interference is lower level but much broader as I perceive it might be from Ethernet over power-line, you might just see sadness across the whole bandwidth in terms of lower bits per bin but no specific chunks missing … that’s a bit of a guess.
My story involved 4 households who all experienced massive ADSL issues twice per day during the week - dawn-ish until school time, and end of school until about when primary school kids go to bed, 7 or 8pm. This took me a long while correlate … the owner of the dodgy old-school tube tele eventually fessed up that the times I and two neighbours had logged almost exactly coincided with their kids television habits. Weekends were toast. I was logging the bits per bin every couple of minutes 24x7 for months - I could have told you to within minutes when that television was switched on, and off … The television was retired - the problem went away permanently.
Apologies to people more knowledgeable in current xDSL than I - my memory is a little vague, but I think that captures it and is to a large extent still valid …
So yes, worth checking
As a footnote: people bag Telstra, but it was a team of telstra guys if I recall correctly based somewhere north of Sydney who educated me on the evils of HF interference and the strange and wonderful cases they had dealt with where xDSL was trashed by some unsuspecting device. The suggestions they made were going out with an AM radio tuned OFF-station high in the AM range and walking up and down the street listening for increases in the noise floor. Another suggestion they made was when finding a suspect house, locating the main switch and ‘turning it off’ to see if the problem went away. The guy who told me that did so verbally, and suggested it was a last resort