General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | [4] | 5 | (show all)   Print Thread
Standard User deleted
(deleted) Mon 04-Apr-16 12:56:27
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
In reply to a post by BatBoy:
Without stats I can only guess. It sounds like your modem doesn't support G.INP, as that's a faily typical description of what happens - G.INP is turned on, modem acts strange, DSLAM turns G.INP off.


I wonder if Batboy has hit the nail on the head here.

Older versions of the HG612 firmware anecdotally didn't support G.INP, though we have little idea of how those versions would behave on ECI cabinets, due to a lack of previous evidence.

As you've re-flashed, is it possible that you reflashed to the newest version?
Standard User deleted
(deleted) Mon 04-Apr-16 15:00:09
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
How's mine?

http://imgur.com/pMUCvJG
http://imgur.com/0xZB6yD

This is after a recent D-side pair swap which is related to my issue here: http://forums.thinkbroadband.com/fibre/f/4469415-noi...

In reply to a post by WWWombat:
In reply to a post by BatBoy:
Without stats I can only guess. It sounds like your modem doesn't support G.INP, as that's a faily typical description of what happens - G.INP is turned on, modem acts strange, DSLAM turns G.INP off.


I wonder if Batboy has hit the nail on the head here.

Older versions of the HG612 firmware anecdotally didn't support G.INP, though we have little idea of how those versions would behave on ECI cabinets, due to a lack of previous evidence.

As you've re-flashed, is it possible that you reflashed to the newest version?

Edited by deleted (Mon 04-Apr-16 15:39:23)

Standard User deleted
(deleted) Mon 04-Apr-16 19:07:45
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
The version I re-flashed was the same version (B030SP08) originally applied, I didn't re-download it so no possibility of a modified version...
Thanks for your comments with regards to the noise floor, i'll wait until the work at the top of the pole is carried out before reporting noise on the line.
To be honest, as much as I enjoy wringing every last bit of performance from the broadband, it's never really fully utilised more than 70% of current rates, so it may well be a sleeping dog that's left lying for some time - as I said, thanks for your views on the noise floor levels.


Register (or login) on our website and you will not see this ad.

Standard User simon194
(experienced) Mon 04-Apr-16 19:32:23
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
My line is even worse at around 10dBm higher across the board than 10forcash unfortunately it passes all the tests so I have to live with it.
Standard User deleted
(deleted) Tue 05-Apr-16 18:22:56
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
In reply to a post by 10forcash:
Thanks for your comments with regards to the noise floor, i'll wait until the work at the top of the pole is carried out before reporting noise on the line.
To be honest, as much as I enjoy wringing every last bit of performance from the broadband, it's never really fully utilised more than 70% of current rates, so it may well be a sleeping dog that's left lying for some time - as I said, thanks for your views on the noise floor levels.


Note that the "noise floors" don't really mean the same thing as hearing audible noise on the line - which is the only real noise that you can report for engineering rectification.

High noise across the VDSL2 spectrum, all 17.6MHz, is mostly caused by other VDSL2 subscribers, and is known as crosstalk. It is well-known, and is the biggest downside to FTTC.

BT's engineers can't do anything about crosstalk, so Openreach mostly won't accept faults raised on this issue.

To work around it, BT need to choose to deploy vectoring.
Standard User deleted
(deleted) Tue 05-Apr-16 21:00:34
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
Thanks for the explanation, my networking expertise isn't in PSTN - as you can probably tell!
Since the re-application of G.INP, I've noticed a large percentage of Reed-Solomon corrected errors on the upstream connection, is this by virtue of G.INP being applied on the downstream only? prior to the change, the reported figures were in the 10th's of a percentage point, now they hover around 17-35% and sustained burst up to 95%
Stats recorded 05 Apr 2016 20:50:00

DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 2 days 12 hours 58 min 43 sec
Resyncs: 0 (since 05 Apr 2016 20:29:57)

Downstream Upstream
Line attenuation (dB): 11.4 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 51185 20000
SNR margin (dB): 5.9 6.0
Power (dBm): 13.6 -1.7
Interleave depth: 1 1
INP: 48.00 0
G.INP: Enabled Not enabled

RSCorr/RS (%): 0.0005 95.5315
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0.16 1.85

Any comments appreciated - please note that traffic is minimal, there is no (or seems to be no) correlation to data throughput either up, down or both.
Standard User deleted
(deleted) Tue 05-Apr-16 21:15:09
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
Here's a side-by-side comparison, the spike was a previous screeshot uploading to Onedrive

https://onedrive.live.com/redir?resid=46B87F8D0BFE93...
Standard User deleted
(deleted) Wed 06-Apr-16 09:31:08
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
In reply to a post by 10forcash:
Since the re-application of G.INP, I've noticed a large percentage of Reed-Solomon corrected errors on the upstream connection, is this by virtue of G.INP being applied on the downstream only? prior to the change, the reported figures were in the 10th's of a percentage point, now they hover around 17-35% and sustained burst up to 95%


There's probably more concentrated commentary going on in the Kitz forum on this aspect.

I first noticed it a couple of weeks ago, when analysing some of the MDWS graphs of recently-activated-G.INP users on ECI cabs, but I had no explanation then, and I still don't. However, I've been out of the investigation for 10 days now, while on holiday.

There shouldn't be anything that G.INP downstream can do to cause real bit errors upstream. That leaves you with the possibility of a fault in the DSP in either the processing of upstream data outbound, or a reverse bug in the DSLAM, or in the processing of the upstream error statistics as they are sent from the DSLAM and/or received by the modem.
Standard User Chrysalis
(legend) Wed 06-Apr-16 11:46:38
Print Post

Re: ECI Cabinet G.INP issue...


[re: deleted] [link to this post]
 
I will correct

"BT engineers dont like trying to resolve crosstalk as pair swaps, replacing budles with less dense bundles etc. is time consuming so they wont accept faults raised on the issue, unless the crosstalk drop off is very extreme".

I dont know why you deliberately misled the poster in your reply, but I corrected it.

Sky Fibre Pro BQM - IPv4
Standard User deleted
(deleted) Wed 06-Apr-16 18:37:31
Print Post

Re: ECI Cabinet G.INP issue...


[re: Chrysalis] [link to this post]
 
In reply to a post by Chrysalis:
I will correct

"BT engineers dont like trying to resolve crosstalk as pair swaps, replacing budles with less dense bundles etc. is time consuming so they wont accept faults raised on the issue, unless the crosstalk drop off is very extreme".

I dont know why you deliberately misled the poster in your reply, but I corrected it.


I'm not sure that counts as "correcting".

Let me correct it myself:
- "BT's engineers can't do anything about crosstalk"
- "BT's engineers can't do anything meaningful about crosstalk"
- "BT's engineers can't do anything predictable about crosstalk"
- "BT's engineers can't do anything long term about crosstalk"
- But it is plausible that they might, temporarily.

1) "Fixing" crosstalk is an impossible game
Engineers can indeed perform pair swaps in an attempt to alter the impact of crosstalk.

However, there is no engineering tool available to them to say which pairs will get less crosstalk or more crosstalk. And no way to predict the crosstalk tomorrow.

All they can do is try other pairs, to see if things change. All with no guarantee, because the other pairs might have worse crosstalk, or worse crosstalk might appear tomorrow, courtesy of a new subscriber, or might have their own latent fault.

2) Pair swaps cannot eradicate all crosstalk
The first leg that VDSL2 signals must pass is the tie pair to the PCP - where every single pair will ultimately be carrying signals. And, even though it might be a short leg, is also the one where signal strength is highest, and induced crosstalk is at its worst.

A pair swap within the D-side cannot ever eradicate this portion of crosstalk.

3) The jobs Openreach accept aren't likely to be pure crosstalk.
Openreach will only accept jobs, where the only fault indication is one of low speed, when that low speed is in the bottom 10th percentile of the nationwide pool of that type of line.

Some of these lines will be ones with extreme crosstalk; some will be lines with real copper faults, but the user never reports a low speed. However, I suspect a lot of them really suffer from a latent copper fault that cannot be detected by the automatic test tools.

When an engineer turns up, he won't be looking for crosstalk, or trying to "fix" crosstalk. He will be looking for a latent copper/aluminium fault. And will attempt to fix such faults as he can do in a limited timespan - if you'r lucky.

If his work fixes nothing, then a procession of further engineers will all attempt to do the same thing. None of them will look for crosstalk.

Only in the absence of anything else to do will they then consider a pair swap. But, in some places, they won't even do that.

If you are amongst this bottom 10% (so get an appointment at all), and you don't have a hidden line fault (after many engineers), and your issue is really pure, extreme, crosstalk, and you are very persistent as you run through that procession of engineer visits, then you might be very lucky, and persuade someone to perform a pair swap. You might then be lucky further, and find a pair with less crosstalk. At least temporarily - until a new subscriber is added.

Bottom 10%; No fault; Persistence; Luck; More Luck. Permanent, ongoing luck.

Yes: getting anyone to look at "extreme crosstalk" is a time-consuming affair. But there is never, ever, a permanent guaranteed solution. Not without vectoring.

Perhaps my correction should read:
- "BT's engineers can't do anything about crosstalk"
- "BT's engineers can't do anything about crosstalk. They can do plenty of things, but they cannot guarantee a positive outcome."
Pages in this thread: 1 | 2 | 3 | [4] | 5 | (show all)   Print Thread

Jump to