By that you mean the interleaving is always turned off for the upstream?
For my connection,
since I have been logging Interleaving levels, yes.
There was a period back in July/August when Plusnet's logs reported that Interleaving was HIGH for my upstream.
I do not have any of my own collected data from that period, other than speed test results.
At that time my US was capped at Plusnet's standard 2Mb level. Usually US speed tests reported 1.67Mb, but for a while it reduced to 0.67Mb. It was only at that time that US Interleaving was reported as HIGH by Plusnet.
Since various "repairs" have been carried out on my D-side cabling, my US speeds have not been affected by Interleaving.
The cap on my US is now 10Mb (arranged by Plusnet as a trial), but I only achieve around 4.8 to 5 Mb throughput.
Attenuation on my US appears quite high at:-
8.3dB - U0
52.8dB - U1
64.1dB - U2
N/A - U3
@Walter,I harvest some of my connection's stats every minute 24/7 & some only "as & when" - on an ad-hoc basis.
From my 24/7 logs, I notice that Interleaving levels for my VDSL2 connection only ever change when the connection re-syncs.
I have not been logging INP levels 24/7, but any changes do "appear" to coincide with re-syncs & changes in Interleaving levels.
Neither have I been logging QLN levels 24/7.
I had assumed that re-syncs at lower speeds were initiated by some of the incredibly high & sudden bursts of errors on my connection (sometimes 2 Million or more CRC / RSUNCorr errors within a one minute sample period).
It may be that the error bursts (presumably caused by increased noise levels) suggest a need to increase INP levels, which in turn suggests a need to increase Interleaving levels, the only way to do this being during a re-sync.
Following a re-sync, I have noticed that sometimes error counts start to mount almost immediately, & sometimes it may be a couple of hours or so before they start to mount significantly.
It appears that when INP & Interleaving levels are higher, the error counts are reduced.
Now that you can monitor INP levels etc. you may see a pattern developing over a prolonged period.
Are you able to capture any useful data with RouterStats or similar tools for the connection(s) you are monitoring?
My connection appears to show higher error counts during the period between 22nd December & 8th January.
(Christmas lights perhaps?)
Unfortunately we suffered a few power cuts during that period which may have also had some effect on matters.
FWIW, My connection has now been up for around 130 hours & error counts are vastly reduced in both frequency & level.
In your case, I presume the electric fence noise is fairly constant 24/7. Is that the case?
From your audio sample, I could hear a constant "buzzing" sound, with some "clicking".
Are you saying the "buzzing" is normal & expected, & that it is the "clicking" that is causing the issue?
Also, is the issue purely low speeds, or is it also frequent re-syncs (not initiated by the user).
I try to stay connected 24/7.
The vast majority of my connection's re-syncs occur "on the fly", are completed within around 16 seconds, & are not reported in Plusnet's logs as the PPP session & dynamically allocated IP address is maintained.
Until I was able to collect my stats & generate relevant graphs, Plusnet believed my connection to be very stable.
For curiosity, who is the ISP that provides the service for the particular connection you mention, & do they consider it to be stable?
Extract from BT's SIN 498 doucument.
It refers to VDSL2 connections, but may also be relevant for ADSL2?:-
2.1.6 Downstream shapingThe CP is expected to shape the downstream traffic to match the actual VDSL2 line
rate in order to avoid excessive traffic loss.
CPs should be aware that the mechanism for reporting the downstream and upstream
line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP
session or a new DHCP request. The success of this is down to the CP's choice of
timers used around PPP / DHCP handling.
If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in
the line rate and will not be able to shape appropriately.
The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with
typical values in the 20-30 second range.
As DHCP typically uses lease timeouts in the order of days rather than seconds, CPs
intending to use DHCP are advised to consider the impact of downstream line rate
changes on their service and any strategies they could adopt if they wish to shape
downstream traffic.
Paul.
P.S. I'm still trying not to hijack your thread, with the thought that some of my own connection's details may assist some way in comparing matters (even though mine is atually a VDSL2 connection).
EDIT (1):
Walter, are you suggesting that 2wire 2700 HGV users now have the ability to adjust INP levels themselves, the modem does it automatically, or just that the updated firmware is now reporting INP levels, requiring ISP manual intervention to manually adjust them in a similar manner to how they can adjust SNRM levels?EDIT (2):
Some of us have noticed that the TBB speed tests appear to occasionally under-report throughput speeds.
Apparently it is something to do with them being HTTP speed tests?
We have found the speedtest.net speed tests to be generally more consistent & reflective of true throughput speeds