|
|
|
I've been quite happily using a TalkTalk FTTC LLU connection for the last six months, (some line issues initially, all sorted and stable for the last 5 months) with a connection rate of around 54Mb down, 20Mb up and Latency circa 18 - 28 mS. Reported error rates were very low (single figures consistently) and the line has been on Fastpath since the initial issues were corrected.
I've been using an HG612 with modified firmware on an ECI Cab, three days ago, G.INP was applied, we instantly had an increase in latency, (relatively) high error rates on the upstream predominantly but with statistically significant increase on the downstream and a drop in download speed and rate.
Now today, the modem lost it's IP address, the 'DSL' light was still on on checking DSLStats, it had also lost G.INP but with a massively increased interleave (904) on the downstream and an INP figure of 3.00. Rebooting the modem had no effect, neither did powering down and disconnecting for an hour. I managed to get back online using a 'spare' ECI modem which connected instantly but with a much lower connection speed of low 40's Mb.
I checked the settings of the HG612 which all looked normal and reloaded them from a stored conf. file, reconnecting the HG612 once again did not re-establish communication to the internet although the 'DSL' light was still illuminated. Ultimately, I decided to re-flash the firmware and then re-load the conf. file, only then did the HG612 establish a connection. The stats are as follows:-
Stats recorded 02 Apr 2016 17:52:31
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 38 min 37 sec
Resyncs: 0 (since 02 Apr 2016 17:14:58)
Downstream Upstream
Line attenuation (dB): 11.5 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps):46017 20000
SNR margin (dB): 6.2 6.3
Power (dBm): 13.6 -1.3
Interleave depth: 901 1
INP: 3.00 0
G.INP: Not enabled Not enabled
RSCorr/RS (%): 0.0000 0.0011
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 4.65
Any ideas as to what happened? - and why?
|
|
|
|
Looks like G.INP has been disabled
|
|
|
|
Well, Yes... but why?
The high interleave on the download? previously the value was 1/1 with no INP
The upstream values and performance has remained constant save for a slightly higher ES/Hour value
Also doesn't explain the hobbling of the HG612
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
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.
|
|
|
|
Hmm... It was running with G.INP for two days, DSLStats reported it as being enabled and there was an additional 'G.INP' tab appeared with additional sub-tabs so I assume that would indicate it was supported and functional.
That said, providing DLM does it's thing and we get back the lost downstream rate and fastpath, I won't be worrying about the loss of G.INP, crosstalk doesn't seem to be an issue here as most properties are on VM coaxial connections and the local cab is only about 300 metres away (but with a lot of aluminium running from it!)
|
|
|
I have the HG612 and it works fine on an ECI cab with G.INP enabled.
Could there be a fault on your line?
Edited by deleted (Sat 02-Apr-16 21:27:40)
|
|
|
I did consider that, unlikely though as the upload performance is unchanged, there is no noise on the line and a TDR test doesn't show any unusual spikes... also a fault wouldn't explain the strange behaviour of the modem and the need for a complete reload - no thunderstorms or low flying fast jets today either 
|
|
|
|
It's made mine even better
Status
xDSL
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 8.2 9.8
Attenuation (dB) 16.8 0.0
Output Power (dBm) 13.4 4.9
Attainable Rate (Kbps) 89662 27456
Rate (Kbps) 79999. 20000
B (# of bytes in Mux Data Frame) 178 236
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 5
R (# of redundancy bytes in the RS codeword) 6 16
S (# of data symbols over which the RS code word spans) 0.0712 0.3771
L (# of bits transmitted in each data symbol) 20780 5410
D (interleaver depth) 1 1
I (interleaver block size in bytes) 185 255
N (RS codeword size) 185 255
Delay (msec) 0 0
INP (DMT symbol) 46.00 0.00
OH Frames 0 0
OH Frame Errors 166 30
RS Words 2222837040 2854428
RS Correctable Errors 74265 338
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 1817062459 0
Data Cells 747919192 0
Bit Errors. 0 0
Total ES 10 30
Total SES 4 0
Total UAS 0 0
|
|
|
|
As I thought might happen, G.INP is back... seems to be less invasive than last time though...
Stats recorded 03 Apr 2016 09:28:21
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 37 min 5 sec
Resyncs: 1 (since 02 Apr 2016 21:11:17)
Downstream Upstream
Line attenuation (dB): 11.4 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 51185 20000
SNR margin (dB): 6.4 6.2
Power (dBm): 13.6 -1.7
Interleave depth: 1 1
INP: 48.00 0
G.INP: Enabled Not enabled
RSCorr/RS (%): 0.0000 0.0033
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0.62 1.66
Downstream Upstream
General
rtx_tx 25 0
rtx_c 6 0
rtx_uc 0 0
LEFTRS 0 0
minEFTR 51174 0
errFreeBits 4734471 0
Bearer 0
RxQueue 87 0
TxQueue 29 0
G.INP Framing 18 0
G.INP Lookback 29 0
RRC Bits 0 24
Interleave depth 1 1
INP 48.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.00 0.00
INPRein 2.00 0.00
Delay 0 0
Oddly, last time it was showing as being active, the INP figure was 0, wheras this time it is (correctly, I believe) showing as 48.00. There also appears to be no negative impact on the performance, unlike a couple of days ago.
|
|
|
Nice bump up in your sync speed too
|
|
|
As I thought might happen, G.INP is back... seems to be less invasive than last time though...
Stats recorded 03 Apr 2016 09:28:21
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 37 min 5 sec
Resyncs: 1 (since 02 Apr 2016 21:11:17)
Downstream Upstream
Line attenuation (dB): 11.4 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 51185 20000
SNR margin (dB): 6.4 6.2
Power (dBm): 13.6 -1.7
Interleave depth: 1 1
INP: 48.00 0
G.INP: Enabled Not enabled
RSCorr/RS (%): 0.0000 0.0033
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0.62 1.66
Downstream Upstream
General
rtx_tx 25 0
rtx_c 6 0
rtx_uc 0 0
LEFTRS 0 0
minEFTR 51174 0
errFreeBits 4734471 0
Bearer 0
RxQueue 87 0
TxQueue 29 0
G.INP Framing 18 0
G.INP Lookback 29 0
RRC Bits 0 24
Interleave depth 1 1
INP 48.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.00 0.00
INPRein 2.00 0.00
Delay 0 0
Oddly, last time it was showing as being active, the INP figure was 0, wheras this time it is (correctly, I believe) showing as 48.00. There also appears to be no negative impact on the performance, unlike a couple of days ago.
How come your downstream is so low with that attenuation? mine is at 16.8 dbi and I get the full 80mbps and an attainable of just under 90mbps
|
|
|
|
Probably the aluminium
|
|
|
Probably the aluminium
What he said
|
|
|
Probably the aluminium
What he said
Can you share graphs from your HG612?
|
|
|
|
Which one(s) would you like?
|
|
|
Which one(s) would you like?
Bit loading & QLN would be interesting.
Cheers
Edited by deleted (Sun 03-Apr-16 13:07:00)
|
|
|
There ya go!
https://onedrive.live.com/redir?resid=3CD50427430923...
Edited by deleted (Sun 03-Apr-16 13:53:22)
|
|
|
There ya go!
https://onedrive.live.com/redir?resid=3CD50427430923...
Pretty good for an aluminium line!
Cheers
|
|
|
It's had some work... the dropwire is copper, the pole DP has had the blue beads removed and the crimps replaced, from there the only other joints are in the PCP. The only reason I can see for the 'low' connection rate is the different reactance values of copper vs. aluminium BTO and TalkTalk both estimated a >69Mb/s connection on an impacted line!
There is however, some variance between the TBB speedtester reported latency and that of other speedtesters, along with the latency reported by the TBB BQM, It varies for me between 12 and 20mS, which is odd...
http://www.thinkbroadband.com/ping/share/542c2674961...
http://www.thinkbroadband.com/speedtest/results.html...
Edited by deleted (Sun 03-Apr-16 16:41:37)
|
|
|
It's had some work... the dropwire is copper, the pole DP has had the blue beads removed and the crimps replaced, from there the only other joints are in the PCP. The only reason I can see for the 'low' connection rate is the different reactance values of copper vs. aluminium BTO and TalkTalk both estimated a >69Mb/s connection on an impacted line!
There is however, some variance between the TBB speedtester reported latency and that of other speedtesters, along with the latency reported by the TBB BQM, It varies for me between 12 and 20mS, which is odd...
http://www.thinkbroadband.com/ping/share/542c2674961...
http://www.thinkbroadband.com/speedtest/results.html...
How did you get BT Openreach to do all that work? I've recently had a pair swap.
|
|
|
|
Persistence... and knowing when to accept that the cost* vs. benefit curve was at it's optimum.
* As in cost to me in time, effort and stress!
|
|
|
It's had some work... the dropwire is copper, the pole DP has had the blue beads removed and the crimps replaced, from there the only other joints are in the PCP. The only reason I can see for the 'low' connection rate is the different reactance values of copper vs. aluminium BTO and TalkTalk both estimated a >69Mb/s connection on an impacted line!
There is however, some variance between the TBB speedtester reported latency and that of other speedtesters, along with the latency reported by the TBB BQM, It varies for me between 12 and 20mS, which is odd...
http://www.thinkbroadband.com/ping/share/542c2674961...
http://www.thinkbroadband.com/speedtest/results.html...
How did you get BT Openreach to do all that work? I've recently had a pair swap.
Blue beans are supposed to be removed as a matter of course anyway. Or at the very least a request submitted for someone to remove them.
|
|
|
|
A request was submitted... by me to the second tech. that turned up!
Helpfully(!), the first tech. mentioned their existence but did nothing about it, neither did he put in a request for the pole DP to be changed due to extensive corrosion ('pair rot'), that was left for the second tech to do...
Fortunately, the third tech. that turned up lived not far away and is served by the same PCP so knew all the pitfalls and how to get the best possible connection rate.
|
|
|
A request was submitted... by me to the second tech. that turned up!
Helpfully(!), the first tech. mentioned their existence but did nothing about it, neither did he put in a request for the pole DP to be changed due to extensive corrosion ('pair rot'), that was left for the second tech to do...
Fortunately, the third tech. that turned up lived not far away and is served by the same PCP so knew all the pitfalls and how to get the best possible connection rate.
You've lost me a bit there, what do you mean by you submitted a request.
The engineer should have submitted a request for the blue beans to be removed. Actually, the appropriate thing to request is something called a BT & Tail renewal. Basically the cable down the pole is renewed and the block terminal at the top. This is done by a different team.
|
|
|
|
What exactly is 'blue beans'?
|
|
|
Not that 
|
|
|
|
Sorry, the request was made by me to the tech. that turned up, the 'pair rot' is probably known in the trade as a BT & tail renewal, that has been requested as I understand it. What I was saying was that once I was aware that they were still in place, that the 'blue beans' were removed by the tech. that was deployed to rectify my phone line connection problems.
'Blue beans' are ferrite cores, the individual wires of the pairs were fed through them to reduce inductive noise ('echo') when phone lines were just that, particularly prevalent at the time aluminium was substituted for copper. They have a negative effect upon the xDSL carrier frequencies.
|
|
|
'Blue beans' are ferrite cores, 'Blue beans' are an old version of a crimp connector.
They resemble a liquorice 'torpedo' and use a serrated sleeve that is crushed into a pair of wires to make a connection.
|
|
|
'Blue beans' are ferrite cores, 'Blue beans' are an old version of a crimp connector.
They resemble a liquorice 'torpedo' and use a serrated sleeve that is crushed into a pair of wires to make a connection.
Looks like if was fed misinformation by the first tech. then!
|
|
|
Hmm. The attenuation value should take into account the effect of aluminium.
So, while you will get lower speeds with an aluminium line, you will also get a higher attenuation value compared to the equivalent copper line.
There ya go!
https://onedrive.live.com/redir?resid=3CD50427430923...
Looks to me like the reason for low speeds is more to do with high QLN values.
A really quiet line will be around -140dBm.
I considered my previous line to be "quite quiet", with readings between -120 and -140. I consider my current line to be "quite noisy", with readings about 10dBm lower than yours, across the spectrum (edit: around -130dBm in the ADSL2+ tones, and around -110dBm in the higher tones).
Yours looks pretty noisy to me - and differences like that 10dBm can be worth a lot of speed.
Edited by deleted (Mon 04-Apr-16 14:30:47)
|
|
|
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?
|
|
|
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...
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)
|
|
|
|
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.
|
|
|
|
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.
|
|
|
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.
|
|
|
|
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.
|
|
|
Here's a side-by-side comparison, the spike was a previous screeshot uploading to Onedrive
https://onedrive.live.com/redir?resid=46B87F8D0BFE93...
|
|
|
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.
|
|
|
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 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."
|
|
|
yes I agree it would not be any kind of reliable fix for crosstlk, as a pair swap is just been given a new lottery ticket for entry in the crosstalk lottery.
But thats different to saying they have absolutely no means of trying to manage crosstalk issues.
|
|
|
Sorry for raising an old thread but this might be a similar issue.
On 29th March overnight latency for my FTTC line increased from about 20 to 30 (unable to link TBB graph for some reason - see linked image) and my sync rate decreased from 79996 to 69964. I'm with Zen with an ECI modem (which I can't unlock so no stats) and about 60 yards from the green cabinet. I've rebooted modem etc with no effect.
It might be coincidence but I was reading about G.INP/ECI issues and wondered if it might be due to this. I have not contacted Zen support as yet.
http://imgur.com/ule2yFN
|
|
|
about 60 yards from the green cabinet. Is the green cabinet a Huawei or an ECI?
|
|
|
|
I've always assumed it was ECI given that the engineer gave me an ECI modem. In those days they matched them, I think. I was the first one in the cabinet.
|
|
|
It's just that the behaviour you described isn't what I'd expect for an ECI cab, more like what I'd expect for a Huawei cab. If you tell me the exchange and cabinet number I can check the make or you can look it up yourself as described here http://www.kitz.co.uk/adsl/cabinet-lookup.htm
|
|
|
|
It's ABERDEEN DENBURN - CABINET 35.
Thanks for your help.
|
|
|
Thanks, yes it's an ECI
I think you should raise it with Zen
Edited by deleted (Mon 18-Apr-16 12:59:18)
|
|
|
|
Will do - thanks again.
|
|
|
you possibly had g.inp enabled and then disabled again as the rollout got suspended and even undone on some activated lines(lack of coverage, so hardly anyone knows).
|
Pages in this thread: 
Print Thread
