How long is the timescale of the March 3-5db SNR rollout ?

How long is the 3db SNR rollout from March expected to take ? Is it a few weeks or months for a nationwide rollout? I'd love to regain the 5Mbits of sync I've lost. So I was just wondering how long until my cab might switch to the 3-5db target. I currently get:

"Stats recorded 24 Feb 2017 06:30:26

DSLAM/MSAN type: BDCM
Modem/router firmware: Not reported
DSL mode: G.993.2 (VDSL2)
Status: Showtime
Uptime: 16 days, 8:07:08
Resyncs: 0 (since 22 Feb 2017 15:54:24)

Downstream Upstream
Line attenuation (dB): 14.8 5.9
Signal attenuation (dB): Not monitored
Connection speed (kbps): 35582 7195
SNR margin (dB): 6.2 6.0
Power (dBm): 13.9 7.4
Interleave depth: 8 0
INP: 48.00 0
G.INP: Enabled

RSCorr/RS (%):
SUnCorr/RS (%):

ES/hour:"

Just nattering on here, but:

I used to get a 39998/7999 stable sync for a long time. Then the DLM decided 34/35 downstream was where it was at. So I lost about 500Kbytes/sec of speed. The problem is a 150m loop of copper which goes out to the pole then runs back to the manhole outside my window about 14 feet away.

Any trouble about the neighbourhood is almost always at the pole with the various properties all around me. I've had an engineer change the pair after water ingress dropped me to 11Mbit sync and an unusable voice line. If I was connected from the NTE to the manhole by the shortest route I would probably get a 50-60 Mbit sync. When I tried 80/20 I got 51Mbit sync for 3 days, then it dropped back. I'm about 450m straight from the manhole to the cabinet.



VDSL Range Down A high: 63.6 low 49 Up High 17.3 low 11.5
Range Down B high: 51 Low 32.5 Up High 14.3 Low 7

Sorry to be a doom-monger, but I don't think there is any chance of your line getting a lower noise margin with those figures and history. Not until the fault is fixed. Even your upstream is affected.

You are still getting a high level of noise, or your noise margin would be well above 6.2dB now. Can you get any error stats?

(I assume you have a typo and meant a loss of 4500Kbps).

Given the way the system works, the failure to reach to 40Mbps sync is hugely significant, and even only reaching 51Mbps on 80/20 is very disappointing.

It might be a silly question, but are you absolutely sure there are no internal wiring issues as well as the external problem? FTTC is very sensitive to that, much more so than ADSLx is.

It would be so much easier to understand if you stayed with convention and referred to the speeds in kbps and Mbps (kilo and Mega bits per second) and did not randomly throw in Bytes per second.

Edited by MHC (Fri 24-Feb-17 09:19:18)

What are liko bits per second?

Your reply beat my correcting edit ... and for some reason "liko" was not flagged as a spelling mistake!

I think the OP's mistake is also a double typo and means bits. Bytes would mean 3200Kbps which would make no sense in the context. 4500Kbps fits perfectly.

Its a trial, so no-one can say if or how long a nationwide roll-out would be. Or as I've been busy on stats have I missed some announcement from Openreach about a nationwide roll-out

If trial leads to more moans about instability I suspect it might be end of game

I have Asperger's Syndrome. My mind thinks in mysterious ways. I tend to meander in my thought processes and express things in unconventional ways. I also tend to assume a degree of telepathic intuition on the part of others. Heh!

I'm also a bit tired and slightly hypomanic this morning.

I Hope that explains things a little

What I actually meant to express was that my longterm median download speeds had dropped from c. 4.2-4.4 Megabytes per second, to c. 3.5-3.8 Megabytes per second.

In reply to a post by TygerTyger2010:

I also tend to assume a degree of telepathic intuition on the part of others.

I think the majority of us suffer with that one, I know I do.

In reply to a post by RobertoS:

You are still getting a high level of noise, or your noise margin would be well above 6.2dB now. Can you get any error stats?

It might be a silly question, but are you absolutely sure there are no internal wiring issues as well as the external problem? FTTC is very sensitive to that, much more so than ADSLx is.

The internal wiring is straightforward. There is a splice in the loft as the previous tenants before I moved in in 2009 had the NTE in the middle of the loft floor, with a plugin extension to the phone below. The outside wire had been cut off where it exits under the roof line. The house had been empty for a few years. BTO repaired it and ran the line to a new NTE beside the computer, and a new wire spliced on the outside running to the pole.

I first had fibre in May 2015, 40/10. I regraded to 80/20 on Dec. 31st 2015. It jumped between 46/48 and 51 Mbits. Stable throughput, but with a lot of ES/hour. It went back to 40 and then a couple of months later decided to drop to 35. It has stayed there ever since, with occasional jumps to 34 every few weeks. A router reset always brings it back to 35. I downgraded to save £3 a month since I wasn't getting any higher sync speed than that.

Average error rates over a 24 hour period:

24 hours starting 23 Feb 2017 13:36:56

Per second Per minute Per hour Per day

CRC Up 0 0.05 3.09 74.3
Down 0 0 0 0

FEC Up 0 0.14 8.46 203
Down 0.07 4.07 244 5863

HEC Up 0 0 0 0
Down 0 0 0 0

ES Up 0 0 0 0
Down 0 0 0 0

SES Up 0 0 0 0
Down 0 0 0 0

All I asked was to stay with convention and use bits - kilobits or Megabits and not swap to Bytes.

Look at the modem data you have - it is in kbps or Mbps, the service from your ISP is defined in Mbps, the TBB speedtester quotes results in Mbps.

your line attenuation is pretty good, id say youre probably 250-300m away from the cab.

my attenuation is 15.8 and im synced at 70/20.

deffo an issue somewhere, i dont think crosstalk would hit you that bad.

considering youre interleaved by 8ms on the downstream, it would indicate your line isnt stable, unless you turn the router off.

Edited by arronlowley (Fri 24-Feb-17 12:32:59)

Quite apart from replying to the wrong person, interleaving depth is (in crude terms) the number of packets each real packet is distributed across for error correction purposes in conjunction with other information. Depth 8 appears to be the default for when G.INP is active, with 4 and 16 certainly having been seen. It is nothing to do with milliseconds.

The addition to latency is the millisecond figure in the "delay" line. The default on FTTC when non-G.INP interleaving of depths usually in the hundreds or over 1000 is present is indeed 8ms. G.INP usually zeroises it. But the OP has not supplied that figure, and may not be able to see it.

Bearer 1 figures below are specific to the operation of G.INP itself. Bearer 0 is the main channel for data.

xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 14190 Kbps, Downstream rate = 66145 Kbps
Bearer: 0, Upstream rate = 14193 Kbps, Downstream rate = 65258 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.1
Attn(dB): 19.0 0.0
Pwr(dBm): 13.7 7.4

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 62
R: 10 16
S: 0.1191 0.5333
L: 17067 3810
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 51 0
TxQueue: 17 0
G.INP Framing: 18 0
G.INP lookback: 17 0
RRC bits: 0 24

Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 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 1584953
OHFErr: 9 42
RS: 100294976 3362783
RSCorr: 1472752 394
RSUnCorr: 0 0

Bearer 1
OHF: 32146614 0
OHFErr: 0 0
RS: 321465525 0
RSCorr: 1 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 132005329 0
rtx_c: 23894 0
rtx_uc: 74467 0

G.INP Counters
LEFTRS: 244 0
minEFTR: 65265 0
errFreeBits: 625696977 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 375550167 0
Data Cells: 101114541 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: 96 57
SES: 21 0
UAS: 103 82
AS: 516417

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.29
OR: 0.01 30.84
AgR: 65325.10 14224.43

Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01

Bitswap: 347634/368011 4210/4235

But when downloading files most popular OS's do list it in bytes rather than bits. So, it isn't that unusual for someone to say something like "have a 16Mbps line that downloads at 2MBps".

The files download at a rate, and when talking about files you talk in Bytes.

When talking about streams and broadband you talk in terms of bits, take a peek at Windows 10 Task Manager

I meant to ask, the trial ends tomorrow, so all lines affected will get reset again. Do we know when/if the trial will be extended and/or when the official rollout begins next month?

No

It looks like DLM has set my target snr to 3db last night. Has anyone else had the same? I am not in the trial area but at WNROS exchange.

My sync increased by about 15mbit downstream, and max attainable went from 65000 to 82000.

On the down side, although I am on a Huawei cab, G.INP has not been activated since the last DLM reset nearly 2 months ago (I'm on fastpath), and now my ES are over 1000 an hour The DLM is not going to like that one little bit so it's a question of whether it will enable G.INP or apply interleave. The last thing I want is interleave, I'd rather have 6db margin, lower sync and no interleave!

user name is Sheepie on MDWS

I believe G.INP is only applied to largely remove interleaving.

Interleaving even at its worst I don't think takes more than 12Mbps or so off, so you are in a Win-Win situation. What is does do is add 8ms to latency though. Occasionally more.

G.INP normally kicks in after two or three days interleaving these days. That pretty well restores the Fast Path sync and zeroises the additional latency. Very dodgy lines may be a bit different but up until this change yours looks fine.

It's almost certain if DLM doesn't like those ES rates its first step will be to 4dB or 5dB. Then back to 6dB if they stay too high.

False alarm, rebooted modem and it's back to 6db margin. sorry.

But it still clearly looks like it was a 3db profile as attainable was higher than sync and you was on fast path.

Edit: Just seen post over on kitz.

Edited by R0NSKI (Tue 28-Feb-17 19:04:27)