Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: New FTTC install - G.INP, 3db margin & vectoring  (Read 5282 times)

johnson

  • Reg Member
  • ***
  • Posts: 838
New FTTC install - G.INP, 3db margin & vectoring
« on: October 19, 2017, 12:33:58 AM »

Hey kitz users! Long time lurker first time poster.

Just thought I'd give a summary of how my new FTTC line has gone from install to now 3 months later as I've found myself searching for other peoples experience when wondering when features like G.INP or vectoring might be enabled, deciding on new modems etc and what to expect out of a long-ish noisy line.

Originally had ADSL2+ on a long (~2.2km) line but capped at 8mbps as from not changing packages over the course of the last 10 years as ISP was bought again and again, eventually with talktalk business. Stats suggested a max rate of 12ish mbps. Have had a FTTC enabled cab for a few years now, but BT checker always gave "This PCP has a waiting list" so I guess it was at capacity, they stood a new larger cab last year and after checking semi-regularly it became available with estimated 'clean' range of 16.1 to 22.4 mbps down and 0.9 to 1.4mpbs up. By road we are only around 800m from the cab and the line largely follows them, so this estimate seemed conservative. Worth a ago, so ordered from talktalk business with a minimum guaranteed speed of 14mbps.

Line installed on the 2nd of August with a disappointing 13 down 1.2 up with the TT supplied HG633. Over the course of a couple of weeks it became apparent that noise spikes were causing resyncs to lower speeds, some times to as bad as 6mbps and causing various amounts of interleaving to be applied. After a while using an AM radio and walking around the street during the noise bursts found a SMPS in a neighbours house was the culprit. Even when just connected without a load it put out serious RF, and when the pc monitor it was powering was switched on enough to cause a connection drop. Removing this combined with a shorter twisted RJ11 cable and the HG633 got up to 16mbps with interleaving enabled only on the downstream with 8ms delay.

A better modem with proper stats reporting seemed logical now so an old openreach HG612 was purchased, and the new ability to graph SNR/FEC errors led to finding another (far less) noisy PSU in a computer in the house. The broadcom chipset modem combined with less noise in the house got us to 18mpbs, nearly 19 if the perfect time of day to resync was picked.

The cab turned out to be a Huawei (is this the case for all new cabs now?) so cue expectant waiting for G.INP to be enabled. After waiting over a month G.INP was enabled on the 22nd of September. So ~ 1.5 months since install date. I will add that a day or so before it was enabled I was messing around in the HG612s settings and found that at some point previously I had deselected all but VDSL2 from the supported protocals options section, since G.998.4 wasnt another protocol option and PhyRe was enabled I'm not sure if its just coincidence that I changed this the day before G.INP was enabled, but nevertheless I changed this to the 'all' checkbox, make of it what you will.

G.INP yeilded a decent increase to around 20mbps and of course no interleaving delay, so pings to google were now 9ms. Pretty good!

After noticing the graph of SNR per tone looked different and clicking around in DSLStats for a while it turned out vectoring had also been enabled.

https://imgur.com/a/bcilq

These are from my own scritps so the x-axis label is frequency rather than tone number. Ignore the ripple centred around 3mhz in the before graph, its an intermittent noise that happens some nights that I have yet to find the source of.

It seemed that vectoring had little to no effect on sync speed as the increase that occurred at the time it was enabled seemed to be solely the result of G.INP, as the max attainable had been around 21mbps all the time it wasnt enabled and so lined up with G.INP removing the interleaving overhead as I understand it, please correct me if I'm wrong. More so it seemed if anything to decrease the upstream rate from around 1200kbps to 1000kbps so I began wondering how well the HG612 supported vectoring. Much searching of forums yielded no firm answer to whether the hg612 supported vectoring properly other than one post by someone saying that they tried both one and a draytek modem on a vectored line and sync was 10mbps or so lower with the hg612 (cant find the post right now). So I began looking for a modem that 100% supported it, more on that later.

To complicate matters now, the enabling of G.INP & vectoring was accompanied by the start of the gradual change to 3db target SNR margin. So over the course of the next 10 days it dropped by 1db every ~3 days:

https://imgur.com/a/ro2ta

This got the line to around 23mbps sync speed.

So to come back to how well vectoring was working on the HG612. Although I guess there are probably lots of reasons vectoring might have little effect on my line (little crosstalk to begin with, the length and noise etc) I still wondered if maybe the HG612 was to blame. I'm not sure of other people experience (and I could find little information from google) but since vectoring was enabled the HG612 reported SNR per tone became odd (both in DSLStats and own scripts). My line uses the U1 & U2 upstream bands and only the D1 downstream. As you can see from the previous graphs it was now showing no SNR per tone from the U2 band at all and showing a weirdly thin U1 band. The pbparams result from CLI showed after the 'discovery' phase the modem had selected the full U1 & D1 bands as before (7,32 & 33,859) but now a larger U2 band, around (871, 980) before it had been (871, 910). Despite this increase the bitloading graph and sync rate showed if anything a decrease in upstream rate as mentioned before. This made me question the modems vectoring support, so I looked for a modem with a newer chipset that might support it better, in the end choosing a Zyxel VMG1312-B10A.

First sync with the new modem offered a pleasing bump to 25mbps from 23 down, and a return to the original (but still disappointing) 1.2mbps up. I'm not sure if this initial increase is just down to the newer BCM63168 over BCM6368 with newer firmware and maybe better input circuitry on the zyxel or due to vectoring. The second sync 2 days later to my shock the modem started using the D2 band with a sync of 28mbps and attainable of 29, this felt like confirmation that vectoring was at least better supported by the zyxel.

However vectoring appears to be a cruel mistress. Some time the next morning after the 28mpbs sync the modem dropped the connection by itself and resynced at 13mbps... A manual resync later in the day returned it to 25mbps, but since this occurred every manual resyc since, even after several ~5-7 day uptimes has resulted in this strangely lower (seems like exactly half?) speed, with a second one later in the day getting back to 25-26mbps. Worth noting that there is no increase in errors or low SNR before or during these manual resyncs. Examining the pbparams output on the CLI shows when this weird sync happens, the discovery phase has resulted in all 3 downstream bands being selected, but no bits being put into any of the 2 higher frequency ones and a much reduced loading on the D1 band. The same odd SNR per tone graphs with missing upstream sections persist across both broadcom chipset modems so I have to assume its a firmware quirk with vectoring enabled.

So thats where I am at now, apologies for the rambling essay of a post but I felt since I've read so much information from kitz it would be worth detailing my experience with a new line in case anyone found it useful.

So has anyone had similar experiences with vectoring? Anyone with a HG612 or VGM1312 with proper SNR per tone graphs?

Has vectoring started to roll across most of the network now? I have to say I was surprised when I found it enabled.

Any clues as to what characteristics of a line result in my ~26mbps downstream with only 1.2mpbs up? From looking through MDWS users it seems common for 25 or so down to have at least 3-4 up. I have thought maybe I was wrong not to ask for an engineer back when the initial speed was so low, but I'm not sure what good it would of done unless there is some fault causing a lower speed other than the poor modem and local noise sources I had then. Does 26/1.2 for ~800-900m line seem low, given 3db + G.INP + vectoring?

Thank you to anyone still reading! :D


Edit: TL;DR

Approx 800m from cab, 2nd of August live date 13mpbs/1.2mpbs. Fixed noise sources and changed to HG612 modem, 18mpbs. 22nd of September G.INP, 3db target & vectoring all enabled. Vectoring seems to have no effect with HG612 so change to a zyxel VMG1312-B10A. After getting to 3db target + new modem = 25mpbs/1.2mbps. Vectoring on zyxel results in one sync as high as 28mpbs but since then manual resyncs result in temporary 14mpbs. Line stable for weeks at a time at 26mbps now, but still unsure of some fault on the line or problem with vectoring.
« Last Edit: October 19, 2017, 01:06:02 AM by johnson »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #1 on: October 19, 2017, 01:38:18 AM »

Welcome to the Kitz forum.  :)

Thank you for your comprehensive post, providing all the facts. I shall give it some thought as I slowly . . .  :sleep:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #2 on: October 19, 2017, 01:47:33 AM »

Many thanks for the welcome!

Apologies again for the wall of text, any input is greatly appreciated.
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 4098
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #3 on: October 19, 2017, 04:44:22 PM »

Would be interesting to see the output of the "xdslcmd/adsl info --vectoring" command for both devices.
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #4 on: October 20, 2017, 10:19:08 AM »

I can but its not very revealing.

From the VMG1312:

Code: [Select]
> xdslctl info --vectoring
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 1157 Kbps, Downstream rate = 29225 Kbps
Bearer: 0, Upstream rate = 1157 Kbps, Downstream rate = 27620 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Vectoring state: 1
VCE MAC Address: 0:10:fc:20:0:0
Total error samples Ethernet pkts sent: 79929
Total error samples Ethernet pkts discarded: 0
Total error samples statuses sent: 79929
Total error samples statuses discarded: 0

This looked identical on the HG612, but with a different number of packets depending on uptime. I have noticed that at some points with the zyxel modem the total of Ethernet pkts sent and the total statuses sent are not exactly equal, with the number of statuses being slightly lower.

You may notice the sync speed is now higher, I reset the modem yesterday and again experienced the much lower (half?) speed, another reboot 20 minutes later resulted in a 27.6mpbs sync but still just using the D1 band. I have no idea what is going on to be honest  ???

Here are the bitloadings with both the low and high syncs, also with the SNR per tone extended enough to see the flat line going up to all the selected but unused tones:

https://imgur.com/a/F0Nen
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #5 on: October 20, 2017, 11:38:00 AM »

You may notice the sync speed is now higher, I reset the modem yesterday and again experienced the much lower (half?) speed, another reboot 20 minutes later resulted in a 27.6mpbs sync but still just using the D1 band. I have no idea what is going on to be honest  ???

Here are the bitloadings with both the low and high syncs, also with the SNR per tone extended enough to see the flat line going up to all the selected but unused tones:

https://imgur.com/a/F0Nen

Those graphs tell you an outcome - that something odd happened - but don't give us much clue about why.

The QLN and Hlog graphs, under similar circumstances, would be the next port of call, to see if they point at a cause.

It'd probably be interesting to see the SNRM over time, the attenuation over time, and perhaps the power over time. Probably over enough time to see some of these resyncs.

(Incidentally, the image in the last post was much more informative than the 1st image in your original post; even though you warned us that the X-axis was frequency, it was scaled perfectly to look like tone number, and was really hard to "untrick" my head into believing the right scale. The before/after difference in SNR wasn't very marked in the first image, but more obvious in the recent one.)
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #6 on: October 20, 2017, 12:30:05 PM »

Quote
(Incidentally, the image in the last post was much more informative than the 1st image in your original post; even though you warned us that the X-axis was frequency, it was scaled perfectly to look like tone number, and was really hard to "untrick" my head into believing the right scale. The before/after difference in SNR wasn't very marked in the first image, but more obvious in the recent one.)

Honest apologies, the only graph of SNR per tone/frequency I had saved from before vectoring was the badly labelled one.

This is two SNR margin graphs over 24hr periods, one from last week, one from the past 24hrs during resyncs. See they both briefly go up to just under 5db margin during the weird half speed. Also included is the lines current QLN and Hlog, sorry but I dont have one saved from during the bad resync, but will get one next time.

https://imgur.com/a/e2PMU


Edit:

Also the output of xdslctl info --stats in case its useful:

Code: [Select]
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 1157 Kbps, Downstream rate = 28922 Kbps
Bearer: 0, Upstream rate = 1157 Kbps, Downstream rate = 27620 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.5             6.5
Attn(dB):        30.3            0.0
Pwr(dBm):        9.2             10.4

                        VDSL2 framing
                        Bearer 0
MSGc:           -6              26
B:              227             31
M:              1               1
T:              0               53
R:              10              0
S:              0.0000          0.8649
L:              7252            296
D:              4               1
I:              238             32
N:              238             32
Q:              4               0
V:              0               0
RxQueue:                64              0
TxQueue:                16              0
G.INP Framing:          18              0
G.INP lookback:         16              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               423928
OHFErr:         185             19
RS:             1346537264              2414666
RSCorr:         23887116                0
RSUnCorr:       0               0
                        Bearer 1
OHF:            5523984         0
OHFErr:         3               0
RS:             33143533                0
RSCorr:         1881            0
RSUnCorr:       3               0

                        Retransmit Counters
rtx_tx:         46775220                0
rtx_c:          4264049         0
rtx_uc:         3056            0

                        G.INP Counters
LEFTRS:         301             0
minEFTR:        26832           0
errFreeBits:    36877046                0

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    357605919               0
Data Cells:     141437795               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:             28              13
SES:            4               0
UAS:            124             124
AS:             88744

                        Bearer 0
INP:            49.00           0.00
INPRein:        1.00            0.00
delay:          0               0
PER:            0.00            11.50
OR:             0.01            22.25
AgR:            27681.04        1179.39

                        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:        34749/37896             1/1

Total time = 1 days 41 min 8 sec
FEC:            23887116                0
CRC:            185             19
ES:             28              13
SES:            4               0
UAS:            124             124
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 15 minutes time = 11 min 8 sec
FEC:            113995          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:            139845          0
CRC:            0               13
ES:             0               7
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 41 min 8 sec
FEC:            399708          0
CRC:            0               13
ES:             0               7
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            23487408                0
CRC:            185             6
ES:             28              6
SES:            4               0
UAS:            124             124
LOS:            0               0
LOF:            0               0
LOM:            0               0
Since Link time = 1 days 39 min 3 sec
FEC:            23887116                0
CRC:            185             19
ES:             28              13
SES:            4               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
« Last Edit: October 20, 2017, 01:11:08 PM by johnson »
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #7 on: October 21, 2017, 12:18:25 AM »

I'll put some quick responses, but I'm due to be away, so other might have to pick up the advice...

- The attenuation is pretty high, suggesting a fairly long line.
  Watch that it doesn't change over time, especially after odd SNR problems
- The Hlog graph looks a nice curve, though it is steep because of the length.
  Watch that it doesn't change either
- The QLN graph shows almost no crosstalk. Seeing noise as low as -140dB is good; getting down to -150dB is excellent. It is often noisier, though, in the ADSL frequency band.
  We haven't seen much data for when vectoring is turned on, but I don't think vectoring would cause QLN graphs to change. I'd still expect a QLN graph to show all noise.
- Really quiet QLN indicates why you saw no improvement from the switch-on of vectoring.
- SNRM seems to show problems.
  a) There seems to be an underlying range of 1dB (higher daytime, lower overnight) which is likely reasonable
  b) There are frequent 20-minute periods where the SNRM drops by around 0.7dB. This isn't a good sign, and it would be interesting to see how the error rates change
  c) There are very infrequent drops of 1db+ on occasion. One taking the margin down to 1dB
  d) There are odd places where there is a 1.5dB increase in SNRM that seems odd too (and, from your description, might coincide with resyncs).

The combination of all of those SNRM changes makes for a range of more like 3 or 4dB, which isn't great.

At this point, I'd be trying to correlate the changes in SNRM to changes in errors, or as triggers for resyncs. I'd be looking to understand the behaviour at (b), (c) and (d) above. And at each resync, I'd be watching for significant changes to attenuation, Hlog, QLN.

See they both briefly go up to just under 5db margin during the weird half speed.

SNRM and speed tend to work in opposition: one goes up, the other goes down. Provided, at least, that power stays the same.

One reason that MyDslWebStats is useful is because you can display a number of graphs above each other, and try to correlate how changes in one parameter runs alongside the other aspects.
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #8 on: October 22, 2017, 01:15:52 AM »

Thanks a lot WWWombat, really helpful. I will have a think on what you have mentioned and keep a closer eye on attenuation as well as the Hlog & QLN graphs.

I would say that since the DLM stopped doing the ~3 day interval resyncs getting to the 3db target, and the one resync the day after the sudden use of the D2 band all of the subsequent resync have been forced by me, the line has not dropped itself even when there have been impulse noise bursts like you mention. The 20 minute drop every approx 3 hours is a puzzle, I have been speculating whether its a neighbours central heating or security system. It seems pretty regular, but have noticed both extended and reduced interval times.

If you will excuse me putting on my tinfoil hat, is there any evidence of BT putting VDSL equipment in the exchange? I have been over and over tracing the most circuitous routes my line could take given the visible poles from the road, and adding meters on at each one for going up and down, tracking across the road etc, the most I can come up with from house to cabinet is 1km. The exchange is at most a further 700m. The graph shown in a post further down this section: https://images.imgbox.com/a6/a0/7JTTcZOI_o.png, would put a 1.7km line at just a hair under 20mbps predicted. Given without the new additions of G.INP, 3db margin and vectoring I had a downstream of 18mpbs and the low upstream of 1.2mbps that persists, it really feels plausible that a VDSL2 connection directly to the exchange would give this performance. I'll add that my downstream attenuation with ADSL2+ was 30db, and now on VDSL2 only using the D1 band is 30db still, I know the D1 band extends slightly higher in frequency, but shouldn't the near halving of distance caused at least a slight drop?

I am aware of exchange only lines and the woes they have trying to get VDSL cabs installed so it does seem highly unlikely. But I would offer the fact that my cabinet serves a great deal of houses (over 600) and is part of "super fast hampshire" as incentives for BT to connect VDSL equipment at the exchange to meet targets.

Feel free to tell me how wrong I am, I realise I'm probably reaching.
Logged

gt94sss2

  • Kitizen
  • ****
  • Posts: 1281
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #9 on: October 22, 2017, 01:35:40 AM »

If you will excuse me putting on my tinfoil hat, is there any evidence of BT putting VDSL equipment in the exchange?

Openreach have installed VDSL cabinets outside telephone exchanges as part of network rearrangement schemes to deal with what were exchange only lines especially in BDUK funded areas. However, they are forbidden from putting VDSL kit actually in exchanges by the UK Access Network Frequency Plan (ANFP)
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #10 on: October 22, 2017, 01:49:02 AM »

Openreach have installed VDSL cabinets outside telephone exchanges as part of network rearrangement schemes to deal with what were exchange only lines especially in BDUK funded areas. However, they are forbidden from putting VDSL kit actually in exchanges by the UK Access Network Frequency Plan (ANFP)

Thank you! I'm a bit lost looking through the linked documents, whats the rational behind stopping them putting vdsl stuff in the exchange? Seems they have a monopoly on the network regardless of where the equipment actually is.
Logged

gt94sss2

  • Kitizen
  • ****
  • Posts: 1281
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #11 on: October 22, 2017, 01:57:55 AM »


The ANFP forbids installing VDSL equipment in exchanges to prevent crosstalk with ADSL from interfering with the service of those remaining on ADSL - hence building the cabinets outside.

Also, LLU providers have ADSL kit in exchanges - its not all just Openreach/BT Wholesale stuff.
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #12 on: October 22, 2017, 02:01:24 AM »

Thanks so much for explaining!  :)

So I guess its pretty much madness to think they would stand cabs outside the exchange to deal with (way) over capacity cabs further away?
Logged

c6em

  • Reg Member
  • ***
  • Posts: 504
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #13 on: October 22, 2017, 08:35:11 AM »

You also need to think long term ahead....
Think of the time when the cabinets albeit with revised equipment inside will be handling all the telephony services: voice and broadband.
All of which will go back from the cabinets as fibre to a large regional head end fibre connection exchanges - perhaps handling thousands of cab's.
All the copper lines going back to the exchanges will new be redundant and could be removed.
At that point many of the exchange buildings themselves are redundant - and can be sold off for housing.

So putting any long term equipment actually in the exchange is not a good idea - put it outside somewhere just beyond the land boundary on public land.
Logged

tubaman

  • Senior Kitizen
  • ******
  • Posts: 12627
Re: New FTTC install - G.INP, 3db margin & vectoring
« Reply #14 on: October 22, 2017, 10:03:55 AM »

...
At that point many of the exchange buildings themselves are redundant - and can be sold off for housing.
...

I'd like to see them do that with my exchange - it's a big shed next to the church in the next village. :lol:
Logged
BT FTTC 55/10 Huawei Cab - Zyxel VMG8924-B10A
Pages: [1] 2
 

anything