Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: niemand on April 11, 2017, 12:53:34 PM
-
So just for the amusement of the Kitizens last Monday I had my second line brought back into service running VDSL. A few (4) DLM interventions later and my primary line, running happily for months at 67Mb, looks a little different.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22393 Kbps, Downstream rate = 65508 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 48997 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): 11.1 7.0
Attn(dB): 17.0 0.0
Pwr(dBm): 14.3 7.2
Banded like a boss.
I doubt this will actually get resolved, and can't really be bothered with much in the way of investigation, but caveat emptor to those wanting both pairs on the same cable running.
-
Is g.vector available?
Are you going to bond the two together to get ~90 Mbps?
-
This is not a vectored cabinet.
The two are load balanced, not layer 2 bonded.
That said, one of them is going to be ceased in fairly quick time once Virgin Media arrive so not going to fixate on it.
-
I was thinking of IP bonding. So by 'load balanced' some people mean that the system is TCP-aware and individual TCP connections are allocated to one link or the other but one TCP flow doesn't not use both links? (Unlike how my system works.)
-
A few (4) DLM interventions later and my primary line, running happily for months at 67Mb, looks a little different.
Banded like a boss.
Harsh. :( Do you happen to have any indication of what the trigger was? (Errors/Retrains).
I doubt whether 'just crosstalk' (which is more of a constant) on its own has caused that. Lower sync, entirely possible. Banding, unlikely.
My line has had about 4 DLM interventions over the past few months, but its been high rates of E/Secs in the 10's of 1000's and it has relented in between.
From the pre ASSIA info I had (which was available to ISPs too) it would have been most likely excess retrains over a fairly short time frame that would cause an ILQ scarlet situation - resulting in probable banding. I'm not sure what changes have been made since as they remain pretty tight lipped these days. I do know that during a scarlet situation DLM has the capability to look at some other factors such as FEC/SNRm. To make 4 changes in less than 2 weeks shows DLM was not a happy bunny. :(
SNR and max attainable shows surplus, but level of INP not given and unsure if your surplus varies over the course of the day.
Pure speculation but the line was possibly flapping all over the show or throwing an exceedingly high amount of errors.
I physically notice when my starts throwing 1000's of Errors, pages take an eon to load, speeds drop to just a few Mbps and vids buffer. I'm quite sure you will have noticed that type of situation, but then again do you /did you have G.INP and that may have made a little difference. If you do then LEFTRS type errors may be the important ones that DLM takes note of.
I also wonder just how possible it could be that during activation of the 2nd pair, something has been disturbed on the 1st.
I could be talking out of my backside as I have very little info to go on from what you've told us, but my instincts are screaming that's not normal crosstalk.
I doubt this will actually get resolved
Depends on what BTw quotes for your line estimate. If it was an engineer install your ISP should use the clean range.
- That said some ISPs of late tend to be using the MGAL figure which can vary from ISP to ISP and doesnt take into account past performance.
Banding is extremely hard to get rid of without an engineer reset.
However like you say, problem is crosstalk on 2x pairs within the same cable. It's a known high risk situation. :( Roll on that VM cable day which no doubt cant come soon enough.
Whats line 2 performance like?
-
The trigger was errors. Retrains were a problem a couple of days ago that worsened the issue.
The other line is fine.
It's not just crosstalk; when the second line was made live again 'something' happened that caused problems with the primary. Disturbance at DP, disturbance at PCP, whichever.
These are the kinds of things that happen when you are constantly trying to sweat the same copper harder and harder.
-
>> The trigger was errors. Retrains were a problem a couple of days ago that worsened the issue.
I suspect it was the retrains that dumped you in land of the banded. :/
>> It's not just crosstalk; when the second line was made live again 'something' happened that caused problems with the primary. Disturbance at DP, disturbance at PCP, whichever
Yup. I had very few stats and any other info to go by, but as I said my gut instincts yelled no way is that typical of just crosstalk.
>> The other line is fine.
Out of curiosity what speed?
-
The initial banding actually appeared to be before any unexpected retrains. There were retrains but they were at about the same time every morning, implying DLM intervention.
The other line:
Max: Upstream rate = 19692 Kbps, Downstream rate = 57084 Kbps
Both are about 500m long. Both are getting the wotsits kicked out of them by about 500 disturbers.
-
I should kinda be grateful for this. It's made me employ active QoS. I am monitoring usage via SNMP, and if the bandwidth gets close to maxed for too long, 30 seconds, it'll then find the heaviest user over the past 30 seconds and downgrade them to lowest privilege for bandwidth. This repeats every 30 seconds.
A user is removed from the list once bandwidth usage has dropped for a minute, or persists but due to another user more than this one, then if they are below 25% of consumption they are released.
Given Openreach seem determined to give me many others too far from the PCP, and VM still isn't a guaranteed thing best work on remedies myself.
Incidentally picture A PCP with the stand-off shell on one side, a G.fast pod on the other, and a VDSL cabinet nearby.
Isn't this an amazing visual analogy, especially if you visualise all the cabling underground? The copper PCP has all kinds of stuff attached to it to extend its lifespan. It's on life support. A great analogy for the Openreach network.
-
Worst of the banding has been removed, which is nice.
Found out that a G.fast pod is due to arrive at the cabinet in the not too distant future too.
No use to me but good to know!
-
Worst of the banding has been removed, which is nice.
Did DLM remove the banding automatically ?
Did you have to reboot to get the new banding or did DLM resync for you ?
I've just had a second line installed to allow me to load balance and its banded for about week now. I'm trying to avoid reboots as my line stats are now fully green and I'm hoping DLM will relent
-
kwillers: the banding is not removed fully, just relented on somewhat. The line resynched itself.
The issue is some noise impacting the higher end of the VDSL spectrum intermittently causing errors. Running QPSK on tones at 10-12 dB SNR doesn't work too well.
-
Mystery solved.
When the nice Openreach man reactivated the second pair in the cable he did something that's ensured the first pair is picking up BPL / Powerline Networking when it wasn't previously.
You can see a notch where there are no BPL carriers in the image below, the rest of the tones vary in SNR depending on the power being used on the 24.414 kHz spaced OFDM carriers overlapping them.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.fibreformiddleton.uk%2FBPL.PNG&hash=48628d8e942e9250f8f72c0768bb32c25ec6c2e0)
-
I wonder why the notch isn't visible in the QLN graph. Was the powerline running at the time of the resync?
-
I started using the BPL as a test, it's on all the time but only starts blasting away across the carriers when in use. I stop using it and this happens to the SNR:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.fibreformiddleton.uk%2FBPL-Off.PNG&hash=c368e2d573f59b34701ad842031fbd3c38b230c6)
-
This has been worked around for now. Used the BPL to trigger the noise and triggered a resync intentionally. Modem and DSLAM duly changed bit allocations to heavily favour downstream band 1 and reduce reliance on band 2 and especially band 3.
There might still be the odd correctable FEC as 10 dB is a tad low an SNR even for QPSK but it should be better. Pity there's no capacity to use BPSK on those really poor tones, would've helped a little bit but probably not worth it in the grand scheme for just an additional 4kbps per tone.
The line will probably remain banded until it is retired for a VM Business service in the upcoming months.
Hope this is useful to someone in the future - subject changed for easier searching.
-
Hope this is useful to someone in the future - subject changed for easier searching.
The subject line has now been adjusted for all posts in this thread.
-
Thank you, Sir.
-
surprised you even was using one of these horrible devices ignition, would have thought you have known they not the best idea :)
For people who dont want to deal with ethernet cable routing indoors, the cables are covered in waterproof material so can be routed outside.
-
For people who dont want to deal with ethernet cable routing indoors, the cables are covered in waterproof material so can be routed outside.
Indeed.
I'm using one 20m section of flat ethernet cable to cover one tricky run. That flat cable can be routed out through the double-glazed windows, as there's just enough room to get past the sealing strips.
The downside is that it is indoor grade, so it'll be killed by UV sooner or later. There's a backup cable waiting to be run out when this one fails.
-
Banded to the same sync speed as my line. Hope you have more luck having the banding removed than I've had so far!
-
Not attempted to get it removed: don't care, can't be bothered.
-
Banded to the same sync speed as my line. Hope you have more luck having the banding removed than I've had so far!
I convinced my ISP to get a BT Engineer out. I provided evidence that I had found and repaired a faulty modem so they where happy to send them out for a DLM reset
Speeds and g.inp back to normal in 48hrs from reset.
-
surprised you even was using one of these horrible devices ignition, would have thought you have known they not the best idea :)
For people who dont want to deal with ethernet cable routing indoors, the cables are covered in waterproof material so can be routed outside.
I'm quite aware of what they do and don't care. ;)
Other things in the property to do, like upgrade the kitchen, living room flooring and looking into an extension, before I start messing around with getting Ethernet cables up 2 floors.
Neither am I going to start drilling holes in walls and climbing ladders to do it externally.
Until the broadband coming into the property makes the PLN obsolete I'm fine with it. Latency is satisfactory and it's delivering an aggregate throughput of 400-500Mb/s :)
-
surprised you even was using one of these horrible devices ignition, would have thought you have known they not the best idea :)
For people who dont want to deal with ethernet cable routing indoors, the cables are covered in waterproof material so can be routed outside.
This has now joined the list of things to do. A design has been done and the active equipment required drawn up as part of making the property gigabit Internet ready.