FTTC - Poor Sync

Hi TB,

I�ve got an interesting problem with my current FTTC connection, I am looking into other options now but that�s outside of this post for the moment.
To give you a bit of background on this issue my line has been running a solid sync at 80/20 for many years now but 29/10/19 my line dropped from 79999/19999 sync to the following:

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16265 Kbps, Downstream rate = 58324 Kbps
Bearer: 0, Upstream rate = 16265 Kbps, Downstream rate = 58992 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.3 6.0
Attn(dB): 15.9 0.0
Pwr(dBm): 12.7 6.8

Here are the stats from the day before:

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19492 Kbps, Downstream rate = 80936 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.4 3.0
Attn(dB): 15.9 0.0
Pwr(dBm): 12.7 6.9

However, since then my line continues to drop in sync speed which is currently on the following:

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22031 Kbps, Downstream rate = 49148 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 50216 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.9
Attn(dB): 15.8 0.0
Pwr(dBm): 12.7 6.8

Zen Internet have attempted to T-Shoot the issue but after 9 BT engineers they are unable to provide any improvements. Also, each time BT come out they stay the line is well above average, but they can�t explain the speed loss, one engineer said I would need vectoring to be enabled to return my line to normal. Due to the poor performance Zen have released me from my contract and issued a full refund for the problems.
As of this month I have moved the line over to AA ISP where the line first dropped to 43Mb but has now come up to the above, so I am currently waiting on an update from then about the next steps if any?

So, in a nutshell, I have lost 40% of my total sync speed sync 29th October.

If anyone has any ideas how to improve the current sync speed that would be welcomed, I believe the BT line length is 400m~ from my local cab.

DSL Checker results: https://imgur.com/rTZIeHi

400 metres so good sync for distance. Likely issue is people on neighbouring pairs have upgraded from ADSL to VDSL2 so increased cross talk

I wonder if the OP is on one of the exchanges where BT Wholesale are wanting to withdraw ADSLx?

There have been a couple of reports here of users receiving emails from BT about a free "upgrade".

Not identical, but similar, I'm currently dealing with a BT Business line that is too expensive on it's legacy package, and BT's recommendations are all with VOIP instead of PSTN. Though equivalents with PSTN can be found later in the initially hidden "More" section.

Not sure I follow the reasoning.

https://forums.thinkbroadband.com/fibre/t/4639174-ft... is the post and user is already on VDSL2 so not sure where free upgrades and BT come into, as with AAISP too now

I did wonder if was cross talk but I wouldn't have expected such a dramic fall off, maybe 60Mb but not as bad this. As looking around I see people here with much higher attenuation with faster syncs.

I have been wondering about ordering a new line to see if that would help.

Only that BT are nudging users away from both ADSLx and PSTN. I did say it was only similar, not directly on topic.

The OP could be on a small exchange they want to close, so causing the FTTC upgrades, and in the case I cited it would be Stepping Hill which is large but PSTN is supposed to be gone everywhere by 2025.

I am on a rural small exchange in Essex, oddly my cab does have G Fast but I am too far away.

ADSL/VDSL is RF signalling over wires. If the RF noise floor in the environment increases it will have a corresponding effect on the overall SNR which will affect max attainable sync.

Did any of the 9 visits check anything RF wise as opposed to 'yes our line is carrying DC and a bit of AC up to 4KHz'? ie. did anyone get a radio out and listen for nasty buzzes?

Similarly, do you have any modem stats that could offer a 'bitloading per tone' type measurement or graph, ideally before the sudden drop & after?

I have a current REIN issue in my area coming from a nearby house, who refuse to accept there's a problem etc. Their noisy device takes out a (fortunately) fairly narrow band of frequencies (adjacent tones have a 14bit loading capacity, the affected tones are down to 3) and does affect sync rate.

Edited by deleted (Sat 21-Mar-20 11:49:14)

In reply to a post by kevindb:

Did any of the 9 visits check anything RF wise as opposed to 'yes our line is carrying DC and a bit of AC up to 4KHz'? ie. did anyone get a radio out and listen for nasty buzzes?

Similarly, do you have any modem stats that could offer a 'bitloading per tone' type measurement or graph, ideally before the sudden drop & after?

I have a current REIN issue in my area coming from a nearby house, who refuse to accept there's a problem etc. Their noisy device takes out a (fortunately) fairly narrow band of frequencies (adjacent tones have a 14bit loading capacity, the affected tones are down to 3) and does affect sync rate.

No, not one of them got a radio out to check for buzzes, as they just done the normal line checks. It was just the normal plug the little hand held in and run a normal 5 min test and then a close down test.

Yes, I have over 3 years or so worth of stats as I run a unlocked HG612, i'll dig them out and post them up.

Here are my Bit loading Graphs along with SN, I have shown these to Zen / BT and they didn't seem overly interested.

Before - 29/10/19 - https://imgur.com/iLM0cwn
When the Sync dropped - 29/10/19 - https://imgur.com/UTnXIOI
Today - 21/03/20 - https://imgur.com/tRFjNLj

Also the QLN Graphs also show a consistant drop.

Before - 29/10/19 - https://imgur.com/DOMC6uM
When the Sync dropped - 29/10/19 - https://imgur.com/g2Ui0BH
Today - 21/03/20 - https://imgur.com/IDPa8an

If you need any more graphs let me know.

I'm still waiting on a update from AA ISP

Edited by RSR1 (Sat 21-Mar-20 14:38:41)

Your original speeds were reasonable for a 16dB attenuation line. At one time I was seeing high 80s downstream. As others came online it slowly dropped ontil one particular neighbour was enabled and I saw a drop of well over 8Mbps ... Looking at your graphs it is likely that somewhere the noise floor has risen by 8 to 10dB and probably not much you can do about it.

NOTE

Before people panic no exhanges are closing for voice yet. Trial in Salisbury and Mildenhall is due later this year.

Result of trial is not a foregone conclusion

So suggesting people should/might worry about being on a small exchange they want to clsoe is over reacting at this time.

I didn't notice any panic about voice closure.

However, closure of ADSL means that that people will be forced onto VDSL, which for some properties will be worse than ADSL.

Once ADSL is removed can the VDSL profile be changed to include the now vacant ADSL frequencies to boost data rates?

Only once LLU ADSL2+ is also removed can the PSD masks be updated

You should try to deliberately slow down the line (see: https://forum.kitz.co.uk/index.php/topic,16427.0.html), and then slowly increment speed as to find the best characteristics whereby there are no Errored Seconds (ES or SES) being reported. As soon as you see even a single ES/SES slow it down one notch, and then DLM will keep the line on FastPath.

For me, despite having a cab literally glaring at me outside my window, I'm on a 600m line with 17.4dB attenuation that can only just support 56mbps down and 16.5mbps up on FastPath while maintaining the prized 5ms latency that's of utmost importance.

Why DLM can't do this automatically, even if we chose to be on the 'super stable' IP profile, is solely down to Openreach's ignominious incompetence.

Thank you, i'll have a look into this and see what it does.

What exchange in Essex? I noticed in your last stats that it�s targeting the 6db whereas before it was going down to 34.

In reply to a post by Danman7200:

What exchange in Essex? I noticed in your last stats that it�s targeting the 6db whereas before it was going down to 34.

My exchange code is EAWDF.

Yes, that's one of the main things I have noticed the SNR seems to target 6db rather than 3db. So I am hoping the limits on the line brings back the 3db target. Looking at the errors on the line today, its very clean, so I can only hope DLM is feeling generous.

Prior to reducing my speed, my stats looked like this:

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19846 Kbps, Downstream rate = 77153 Kbps
Bearer: 0, Upstream rate = 18994 Kbps, Downstream rate = 61081 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.1 5.5
Attn(dB): 17.4 0.0
Pwr(dBm): 6.7 6.7

VDSL2 framing
Bearer 0
MSGc: 14 68
B: 39 59
M: 1 1
T: 64 3
R: 14 16
S: 0.0208 0.1001
L: 20736 6072
D: 1495 253
I: 54 76
N: 54 76

While I was getting more speed through the line, my SNR was struggling to get to 6dB and DLM was interleaving quite heavily. This resulted in quite a fast download, but terrible latency. (The 'D' is interleave depth). In further stats you will also probably see INP applied (INP and G.INP are different things), and a delay, but I've omitted for brevity. They were 4 and 8ms respectively.

Today, my stats are like this:

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22222 Kbps, Downstream rate = 68559 Kbps
Bearer: 0, Upstream rate = 15047 Kbps, Downstream rate = 56494 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 9.1 9.6
Attn(dB): 17.4 0.0
Pwr(dBm): 5.0 5.0

VDSL2 framing
Bearer 0
MSGc: 17 159
B: 239 236
M: 1 1
T: 64 2
R: 0 16
S: 0.1352 0.5010
L: 14200 4072
D: 1 1
I: 240 255
N: 240 255

By deliberately slowing down my line, I sacrifice some speed, but get rid of interleaving and increase my SNR to 9dB. On balance I now have a much more stable line. As you can see, I've limited speeds to 56500 down and 15050 up, but I have FastPath back, and my latency dropped from 21-24ms to 5-7ms. These figures coincidentally to the largest number that rounds up to the 'Low' estimate of an impacted line on BT Availability Checker (56.6 mbps down and 15.1 mbps up for me), although I'm only pointing this out without empirical evidence.

DLM will not remove interleaving if you have an average of 10 or more Errored Seconds (ES) per hour. On a troublesome line it's highly unlikely you'll get ES down to zero (I'm in the 2-3 ES/hr average), but as long as the MTBE is below the threshold, then DLM will become forgiving (read: https://kitz.co.uk/adsl/DLM.htm for everything you need to know about DLM and MTBEs).

For the record, I'm on an ECI cabinet without 3dB nor G.INP enabled in Shepherd's Bush (LWSHE). The latter would probably help me massively - I've asked my ISP, IDnet to opt in, but so far nothing.

For some 24ms latency is no big deal and they need fast downloads. Peddle to the metal, my line can go quite fast, but that's not important. For me, losing 1MB/s on downloads is annoying but not nearly as annoying as the delays of high latency for DNS, SSH and the general 'snappiness' of everything, so it's each to their own.

Please note, to slow down a line, it has to be done on the modem itself (see: https://forum.kitz.co.uk/index.php/topic,16427.0.html) as part of the DSL training process when it syncs with the DSLAM, and deliberately increasing the SNR on the line in the process - slowing down a line on the router via QoS or some other limiter won't affect the line's quality.

Incidentally for QoS, you would want the QoS max line speed to be precisely 96.68% of the sync speed of your modem on a FastPath line. On an interleaved line, I haven't quite worked out the maths unfortunately, but people say you have to consider the Reed Solomon parity overhead (in order for FECs to work properly), and that it's related to R / N. However that would mean a 25.9% penalty on my original stats, and I could hit 60mbps on speed tests, which is far higher than such a penalty would suggest (43mbps), so I don't quite know.

Edit: grammar

Edited by zzing123 (Wed 01-Apr-20 12:53:45)

Thanks for the detailed reply, I’ve limited mine to 29Mb/15Mb and I can already see that DLM has not only dropped the interleaving it’s also increased the max sync by 4Mb~ so far and I am also on a Huawei cab.

The interesting thing is INPRein: 1.00 changed which suggests the re-transmits are high but looking at the ES rate sync the resync, it’s not showing anything errors on the DL just the UL


Since Link time = 15 hours 14 min 59 sec
FEC: 126 225
CRC: 0 26
ES: 0 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

I can only assume DLM will take some time to sort it out, I did see that interleaving has dropped to 2 from 32 and I have noticed the latency us around 6ms, which is the same as I used to get on Zen.

This was the resync this morning

DLM resync

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23228 Kbps, Downstream rate = 52608 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 12.8 10.5
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.8

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29190.49 15033.97


Before Resync

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Last initialization procedure status: 0
Max: Upstream rate = 21916 Kbps, Downstream rate = 48808 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 13.1 9.7
Attn(dB): 15.7 0.0
Pwr(dBm): 12.7 6.7

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29102.34 15033.97

Edited by RSR1 (Wed 01-Apr-20 18:22:36)

The higher the SNR the lower the attainable rate. Theoretically if your modem goes to 3dB SNR, then you'll get attainable rates that look very sexy and possibly over 100mbps - but don't worry about the attainable rate, it's just a calculation made from SNR values and not something we can possibly hope to achieve on our pair of rubbish lines!

DLM will take time to sort out. It works things out very slowly, but if after about 4-7 days nothing happens, call your ISP and ask for a 'DLM reset', and DLM will treat your line as if it's freshly connected. I'd advise doing that once you've got everything very stable though, as it will kick in with interleaving again otherwise.

INPRein is bad. 'REIN' is 'Repetitive Electromagnetic Impulse Noise', which means you have something that's impacting your line badly, and the INP (Impulse Noise Protection) is kicking in to try and mediate the problem. This most likely being caused by a power line.

This is something you can legitimately whinge to your ISP and call out an engineer for, but only if it's on the other side of the NTE. So first, make sure that the RJ11 cable from the modem to the NTE is as clear as possible from the power supply cable to the modem is as separated as possible. Those power warts can be stupidly noisy. When you're sure the modem's DSL line is clean, resync the modem.

If that REIN still exists, then call your ISP and mention to them you suspect REIN on the line. This will most likely result in an SFR investigation, and an Openreach engineer will go and inspect every part of the line to ensure that the noise is eliminated. But if he finds it's in your house, you'll have to pay for the call out, hence why I asked you to make sure first.

I've been making solid progress restoring on the speed on my line as I have gained 10Mb~ on where my line has started about 5 days ago.

Since the DLM reset this morning, its now showing the following from where it started. (You can pull stats by running - xdslcmd info --stats on a unlocked HG612)

Max: Upstream rate = 23435 Kbps, Downstream rate = 58904 Kbps

I've been limiting the line rate by running the following on my HG612 - xdslcmd configure --maxDataRate 29000 15000 100000

Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps

I will start to bring the speed from tomorrows re-sync if the DLM pattern holds true. However at the current speeds the line is free from any errors

Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

What is interesting though, since i've limited the line I can see the following

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00

Bearer 0, INPRein 0 is Retx Low
Bearer 0, INPRein 1 is Retx High

I expect this to change shortly though as well.

but the interleaving depth is quiet low.

D: 2 1

As it used to run much higher, which in theory means mines the latency should be nice and low.

I will also be moving this line back to Zen from AA ISP.

Edited by RSR1 (Sun 05-Apr-20 15:12:54)

IIRC the latency addition is shown by the delay line.

Is Bearer 1 still present? That is there when G.INP is active. It shows 0Kbps, but is actually 200bps rounded down. Also I think delay is to be expected to be zero with G.INP.

Edited by RobertoS (Sun 05-Apr-20 16:43:00)

Yes. Bearer 1 is present.

As its shows the following settings:

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Edited by RSR1 (Sun 05-Apr-20 17:46:16)

As RoberoS points out the Interleaving depth is completely irrelevant to latency.

You need to look at the Bearer 0 delay stats which is always 0 with G.INP.

There's only additional delay on Interleaving without G.INP, which is usually "delay: 8" which adds 8ms to latency.
High Interleaving can add 16ms delay/latency.

This should only be relevant for ECI cabinets as all lines on Huawei cabinets should have G.INP applied shortly after going live,switching ISP or having a DLM reset.
ECI cabinets have a G.INP trial running again but it's only been seen on a very small number of Plusnet lines who specifically opted in to the trial.

Retx Low/High doesn't effect latency.
It has an impact on throughput as Retx High has a lower IP profile so Retx Low would be preferable.

I recommend keeping the cap in place until Retx Low is applied.

That was my plan to see where it evens out, as above though I'm on a Huawei cabinet.

Here are the current stats off the line.

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22827 Kbps, Downstream rate = 58548 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 12.6 10.0
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.7
VDSL2 framing
Bearer 0
MSGc: -6 29
B: 228 31
M: 1 1
T: 0 64
R: 16 2
S: 0.2501 0.0678
L: 7838 4009
D: 2 1
I: 245 34
N: 245 34
Q: 2 0
V: 1 0
RxQueue: 138 0
TxQueue: 23 0
G.INP Framing: 18 0
G.INP lookback: 23 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1256885
OHFErr: 0 16
RS: 954108608 4117973
RSCorr: 102 124
RSUnCorr: 0 0
Bearer 1
OHF: 3727999 0
OHFErr: 0 0
RS: 22367627 0
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 115953 0
rtx_c: 1160 0
rtx_uc: 318323 0

G.INP Counters
LEFTRS: 98 0
minEFTR: 29001 0
errFreeBits: 1369581236 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3339421803 0
Data Cells: 933681097 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 59 729
SES: 59 39
UAS: 320 261
AS: 59882

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29190.49 15033.97

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Bitswap: 12901/12901 24/24

Total time = 1 days 23 hours 41 min 10 sec
FEC: 97398 12063
CRC: 3254 2032
ES: 59 729
SES: 59 39
UAS: 320 261
LOS: 4 0
LOF: 56 0
LOM: 21 0
Latest 15 minutes time = 11 min 10 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 41 min 10 sec
FEC: 182 1623
CRC: 559 101
ES: 10 41
SES: 10 7
UAS: 36 26
LOS: 1 0
LOF: 10 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 197 4728
CRC: 0 245
ES: 0 87
SES: 0 2
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 16 hours 38 min 1 sec
FEC: 102 124
CRC: 0 16
ES: 0 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

In reply to a post by j0hn83:

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

Ahh excellent, I will change that tomorrow after ther resync.

This has been a interesting learning curve but all good.

In reply to a post by j0hn83:

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

I'm not on a G.INP line, but I'd have thought SNR margins still matter? Upstream and downstream SNR's in my experience, especially on a high-att line like his and mine, seem to need to be roughly equal to ensure the ES counts stay low and that mixed SNRs on upstream/downstream directly affect the other part of the line. Unless there's some magic that G.INP does with SNR that I don't know?

Adjusting the sync-time SNRM on ADSLx is a well-known technique, but the BT Wholesale and LLU DLMs on it is a very different beast from the SNRM on the Openreach DLM that Openreach controls.

The latter alters many other parameters when it adjusts SNRM, and the SIN specifically instructs that intervention to alter it is not allowed. Presumably because the overall setup is screwed up.

Capping by limiting the sync speed isn't specifically banned, but whether it is safe or not I don't know. Speed capping (with other adjustments) is what OR does to cap lines due to instability.

Wrt altering the HG612 upstream speed setting immediately after a sync, that is going to cause an immediate re-sync. Hmmm. Probably safe but not ideal when G.INP is active.

In reply to a post by RobertoS:

Adjusting the sync-time SNRM on ADSLx is a well-known technique, but the BT Wholesale and LLU DLMs on it is a very different beast from the SNRM on the Openreach DLM that Openreach controls.

The latter alters many other parameters when it adjusts SNRM, and the SIN specifically instructs that intervention to alter it is not allowed. Presumably because the overall setup is screwed up.

Yes, and setting the SNR on VDSL on a Broadcom modem won't do anything. Ironically, I noticed you can SNR directly on VDSL on the Draytek 130 which is a SIN498 modem, but that's not really the point on VDSL and as you say it's not allowed in OR SIN - and DLM did *NOT* like that so don't even try it even if you can.

In reply to a post by RobertoS:

Capping by limiting the sync speed isn't specifically banned, but whether it is safe or not I don't know. Speed capping (with other adjustments) is what OR does to cap lines due to instability.

By lowering the sync speed we're just influencing the training of the line between modem and DSLAM and thus the increased SNR is a 'side effect'. Like I said, by having your speed just a bit under the lowest DSL checker reported speed, the BT infrastructure seems to sync at 9dB instead of 6dB.

In reply to a post by RobertoS:

Wrt altering the HG612 upstream speed setting immediately after a sync, that is going to cause an immediate re-sync. Hmmm. Probably safe but not ideal when G.INP is active.

If you do do this, first disconnect the RJ11 phone line from the modem, then do any reconfiguration necessary on the modem, including setting the speed. Then only put the phone line back in the modem AFTER 30 minutes have passed. DLM ignores a sync event when there's been no activity in the prior 15 minute bin, so to make sure you surpass that 15 bin then you have to wait double the time. If you just resync the modem while connected, DLM will think it's an instability event and count on the MTBR (Mean Time Between Resyncs), which alongside the MTBE (Mean Time Between Errors - ES counts) is the exact thing DLM measures and decides how to impose countermeasures on the line.

Like I said, by having your speed just a bit under the lowest DSL checker reported speed, the BT infrastructure seems to sync at 9dB instead of 6dB.

What exactly do you mean by lowest DSL checker reported speed?
The lower estimate, or the observed speed from nearer the bottom of the page?

The default target SNRM is 6dB.

On a line that makes good use of the D3 downstream band each 1dB SNRM is worth roughly 3-4Mb.

On a line that makes no use of the D3 band each 1dB is worth less than 3dB, depending much of D1 and D2 are used.

Yes, and setting the SNR on VDSL on a Broadcom modem won't do anything. Ironically, I noticed you can SNR directly on VDSL on the Draytek 130 which is a SIN498 modem, but that's not really the point on VDSL and as you say it's not allowed in OR SIN - and DLM did *NOT* like that so don't even try it even if you can

The DLM doesn't give a hoot what the current SNRM is.
It sets a target SNRM and the DSLAM and modem try to sync at that.

DLM doesn't like the increased ES that can come with manually/artificially lowering the target SNRM.
Many users run with their lines on a manually tweaked SNRM just fine without DLM blinking an eye.

f you do do this, first disconnect the RJ11 phone line from the modem, then do any reconfiguration necessary on the modem, including setting the speed. Then only put the phone line back in the modem AFTER 30 minutes have passed. DLM ignores a sync event when there's been no activity in the prior 15 minute bin, so to make sure you surpass that 15 bin then you have to wait double the time. If you just resync the modem while connected, DLM will think it's an instability event and count on the MTBR (Mean Time Between Resyncs), which alongside the MTBE (Mean Time Between Errors - ES counts) is the exact thing DLM measures and decides how to impose countermeasures on the line.

Overkill.

While that is all correct the DLM allows up to 20 resyncs a day on the Speed policy and 10 resyncs a day on the Standard policy.
A recently temporal trial was testing lowering the Standard policy to 5 resyncs a day.

Still, never once have I ever seen DLM take action on a line for doing a resync or 2.
Keeping the modem offline for 30 minutes every time you need to resync once in a blue moon is wholly unnecessary.

Edited by j0hn83 (Mon 06-Apr-20 14:10:00)

Looks like DLM kicked off two resyncs today with a total further speed increase.

It also looks like I am on on low retx now as well.

1st Re-Sync

Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22896 Kbps, Downstream rate = 59988 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 13.1 10.2
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.8
VDSL2 framing
Bearer 0
MSGc: -6 29
B: 228 31
M: 1 1
T: 0 64
R: 16 2
S: 0.2501 0.0678
L: 7838 4009
D: 2 1
I: 245 34
N: 245 34
Q: 2 0
V: 1 0

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29102.34 15033.97

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

2nd about 10 mins later

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23091 Kbps, Downstream rate = 59561 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 13.3 10.4
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.8
VDSL2 framing
Bearer 0
MSGc: -6 29
B: 158 31
M: 1 1
T: 0 64
R: 16 2
S: 0.1742 0.0678
L: 8039 4009
D: 16 1
I: 175 34
N: 175 34
Q: 16 0
V: 7 0

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29102.34 15033.97

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

I've now uppped my limits to the following

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23335 Kbps, Downstream rate = 59152 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 35999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.8 7.7
Attn(dB): 15.8 0.0
Pwr(dBm): 12.7 6.8

So all very postive progress, I just need to find the sweet spot now after it levels out.

In reply to a post by j0hn83:

What exactly do you mean by lowest DSL checker reported speed?

Low estimate of impacted speed. Mine is 56.6 and 15.1.

On a line that makes good use of the D3 downstream band each 1dB SNRM is worth roughly 3-4Mb.

On a line that makes no use of the D3 band each 1dB is worth less than 3dB, depending much of D1 and D2 are used.

Take a look at my stats in full if you like: Stats

The DLM doesn't give a hoot what the current SNRM is.
It sets a target SNRM and the DSLAM and modem try to sync at that.

I know it doesn't. Bearing in mind:
a) That I have 17.4dB of attenuation to deal with
b) My priorities are 1. Latency 2. Upstream and then only 3. Downstream

Means I regard FastPath as an SLA condition, and that battling with DLM to guarantee that it doesn't impose Interleaving is a big deal. Therefore, to keep ES's low enough to maintain Fastpath and to ensure there is sufficient SNR to keep the line stable, I needed to lower bandwidth, ergo DLM indirectly affected by SNR.

Overkill.

Good to know. However, even better would be to allow us to choose profiles based on our SLA priorities, and there's absolutely no reason DLM can't do this.

In reply to a post by zzing123:

b) My priorities are 1. Latency 2. Upstream and then only 3. Downstream

Means I regard FastPath as an SLA condition

The trouble with that is, it isn't!

It may be your priority, but I assume you are on a consumer level product at a consumer level price with a mass-market provider.

Is an SLA mentioned in the T & Cs for your contract?

Edited by RobertoS (Tue 07-Apr-20 19:55:49)

In reply to a post by RobertoS:

It may be your priority, but I assume you are on a consumer level product at a consumer level price with a mass-market provider.

Is an SLA mentioned in the T & Cs for your contract?

Unfortunately, no. Unless I'm very much mistaken, I don't believe such an SLA exists anywhere either... because I'd probably get it.

But I did say *I regard it as* such. I'm on a business line with SL3 at the moment with IDnet, but they're not delivering.

Thing is, there's such a wide gap between consumer lines at £30 and a leased line that starts at £250 for say 80-100mbps speeds, and there is quite a large market for quality products in between. My budget can stretch to about £125, and £1500/yr is a decent bit of wedge for internet access... so I'm willing to pay, but not excessively.

Problem is what do I get? G.Fast is available but can't do anything on my line since I'm too far away. FTTP isn't available here yet even under alt-net form. FTTPoD is a non starter while ECCs costs the same as a leased lines and there's no discount for the added contention and no SLAs. Virgin is also available, but service is even worse than FTTC for latency and quality. Their 'MIA' and 'DIA' products are equally a total waste of space since DOCSIS is the problem with them. Then there's EFM, which is too slow and *way* too expensive as it is now. EFM could be made viable if it wasn't 5x to 6x too expensive for what it is (essentially bonded VDSL with an SLA). In any case EFM is totally eclipsed by 'EoFTTC' (Ethernet over FTTC) which is VDSL with 1:1 contention and the same SLA as EFM for £75 (TTB) or £85 (BTW).

So really, my only option right now are either bonded broadband (no guarantees still, and offerings are too expensive for too little) and EoFTTC. But even with that, while I'll be able to call out an engineer every 7 hours for practically any reason, Openreach STILL won't guarantee performance!

So unless I'm very much mistaken, I don't know of any SLA offered on any product offers a decent quality line, that while pricier is not completely insanely so. Any suggestions?

Edited by zzing123 (Tue 07-Apr-20 23:21:39)