Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: S.Stephenson on March 06, 2016, 01:07:36 PM
-
See attached
Looks like it was done in 20mins at around 4am, as there is 20 mins of stats missing.
-
;) Never doubted for one minute it would get implemented.
-
WOW ;D
-
Can you check please using xdslcmd info what it says for the Vendor Id
Im still showing
adsl info --vendor
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 5502152235
-
PS
Just noticed les-70 has asked the same question here (http://forum.kitz.co.uk/index.php/topic,15921.msg315515.html#msg315515).
If you are using DSL stats then like he says, the info can be easily seen from the "Stats" tab.
-
This is great news for customers connected to an ECI cab. ;D
-
Unfortunately I'm at work till 10pm, will check asap
-
Mines on "06" but no changes yet..
-
Before I got G.INP I used to sync at the attainable, there is now a gap of 3mbit.
With G.INP do you not sync near the attainable?
Also at the moment I'm getting insane amounts of FEC's on the upload(60000), it's not resulting in allot of CRC's thankfully.
Question is can ECI manage g.inp on the upload I could definitely use it.
-
Also at the moment I'm getting insane amounts of FEC's on the upload(60000), it's not resulting in allot of CRC's thankfully.
Remember to regard FECs as "CRCs that never happened", as the error correcting protocols are operative.
-
Just seems strange for my line ive never seen them this high before.
-
Unfortunately theres not much history on MDWS to compare.
I'd be interested if you notice any change in latency.
I'd also be interested in seeing the VDSL2 framing parameters - Previous and current.
On the 'old' system all upstream lines had a low level of FEC protection applied by default - even if DLM wasnt taking any action to increase stability - and the RFEC was set at 16.
Its not impossible that one of these values related to RS such as the R/K/T/N have changed which could affect the amount of redundancy being applied... which in turn could affect the amount of recorded FECs.
MDWS doesnt (afaik) record these and you'd need to get them from the connection stats. We still arent certain of the relationship between the RS parameters - linky (http://forum.kitz.co.uk/index.php/topic,17054.msg314289/topicseen.html#msg314289).
-
On a Speedtest.net test latency dropped from 10ms to 9ms, I'll do some further tests when I get home.
-
I seem to be on the older one?
Latency to google.co.uk and bbc.co.uk have both dropped by 1ms for me also, so basically no change in latency as far as I can tell.
-
Something doesn't look quite as expected with those stats.
With G.INP active from a Huawei DSLAM, we would see a low level of DS Interleaving depth (typically 16 or 8).
It is showing 1 for both DS & US i.e. the equivalent of still being on fastpath.
Could you post the other stats as per the output from the telnet commands xdslcmd info --stats & xdslcmd info --pbParams?
-
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19351 Kbps, Downstream rate = 65888 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 62708 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.2 6.4
Attn(dB): 14.1 0.0
Pwr(dBm): 14.0 3.6
VDSL2 framing
Bearer 0
MSGc: -6 129
B: 243 236
M: 1 1
T: 0 7
R: 10 16
S: 0.1239 0.4443
L: 16400 4592
D: 1 1
I: 254 255
N: 254 255
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 2379674
OHFErr: 0 69
RS: 1074811752 283371
RSCorr: 201 6961768
RSUnCorr: 0 0
Bearer 1
OHF: 2080871 0
OHFErr: 0 0
RS: 20808093 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 66 0
rtx_c: 58 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 62691 0
errFreeBits: 31958668 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4030626726 0
Data Cells: 239623802 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: 0 58
SES: 0 0
UAS: 31 31
AS: 33426
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.02
OR: 0.01 153.75
AgR: 62772.11 17148.51
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: 11387/12400 0/0
Total time = 9 hours 17 min 37 sec
FEC: 201 6961768
CRC: 0 69
ES: 0 58
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 37 sec
FEC: 2 1
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: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 9 hours 17 min 37 sec
FEC: 201 6961768
CRC: 0 69
ES: 0 58
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 9 hours 17 min 5 sec
FEC: 201 6961768
CRC: 0 69
ES: 0 58
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19358 Kbps, Downstream rate = 65888 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 62708 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 19358 kbps 65888 kbps
Actual Aggregate Tx Power: 3.6 dBm 14.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 14.8 23.2 N/A N/A 9.0 20.4 32.5
Signal Attenuation(dB): 0.1 14.7 23.1 N/A N/A 10.5 20.2 32.4
SNR Margin(dB): 7.9 6.7 6.3 N/A N/A 6.2 6.2 6.2
TX Power(dBm): -5.3 -40.5 3.0 N/A N/A 11.3 7.3 7.4
#
-
This is all I can find before G.INP
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19619 Kbps, Downstream rate = 58612 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 58142 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.3 6.5
Attn(dB): 14.1 0.0
Pwr(dBm): 14.0 3.2
VDSL2 framing
Bearer 0
MSGc: 19 129
B: 239 236
M: 1 1
T: 64 7
R: 0 16
S: 0.1314 0.4443
L: 14616 4592
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 46607693 2067016
OHFErr: 95 184
RS: 0 655858
RSCorr: 0 1090
RSUnCorr: 0 0
Bearer 0
HEC: 657 0
OCD: 20 0
LCD: 20 0
Total Cells: 2385190202 0
Data Cells: 831707178 0
Drop Cells: 0
Bit Errors: 0 0
ES: 75 143
SES: 0 0
UAS: 193 193
AS: 98347
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.11 7.02
OR: 94.78 153.75
AgR: 58236.51 17148.51
Bitswap: 41258/41258 538/551
Total time = 1 days 3 hours 22 min 20 sec
FEC: 0 1090
CRC: 95 184
ES: 75 143
SES: 0 0
UAS: 193 193
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 7 min 20 sec
FEC: 0 1
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: 0 1
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 3 hours 22 min 20 sec
FEC: 0 69
CRC: 7 6
ES: 5 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 1021
CRC: 88 178
ES: 70 137
SES: 0 0
UAS: 193 193
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 3 hours 19 min 7 sec
FEC: 0 1090
CRC: 95 184
ES: 75 143
SES: 0 0
UAS: 0 0
-
Thank you for supplying those. Im only giving a quick scan before I head off to bed, but BaldEagle is correct in that I cant recall seeing a g.inp line at 1 either. Ive seen a few 8's. Thats not to say it cant happen. You certainly appear to have g.inp switched on though.
I cant see anything obvious in the config to show why your FECs would be higher on the upstream. I cant recall now, but did those that had the ECI cab upgrade to the f/w upgrade say they also saw more errors soon afterwards? ... but it eventually settled down?
I seem to be on the older one?
You do indeed - thank you for confirming that.
-
PS.
Just to rule out something quite important:
You dont live anywhere like Martlesham or Milton Keynes do you?
Weve seen g.inp in use on an ECI cab in Martlesham Heath about a year ago.
----
ETA.
and out of curiousity I looked at his stats. He was also on 'Fast' Path for downstream. (interleaved depth 1/0) - linky (http://forum.kitz.co.uk/index.php/topic,15190.msg283232.html#msg283232).
DS Max Rate : 67000
DS Min Rate : 128
DS Attainable : 62753
DS Delay : 0
DS INP : 44.0
DS Trellis : 16
DS Bitswap : 1
DS Bitswap Cnt : 56255
DS Margin (dB) : 5
DS Margin per Band (0.1dB) : 5,5,5,-63,-63
DS Attenuation (dB) : 19
DS Attenuation per Band (0.1dB) : 14,32,50,127,127
DS Powercutback : 0
DS SRA : 0
I wonder if its an ECI specific config.
-
West Yorkshire.
Hemsworth Exchange
Cabinet P19
My cabinet has plenty of people in the outer range of FTTC, so I'm hoping for vectoring...
I highly doubt it though but a man can dream...
-
Thanks for the url, but the link only works for the person making the query. :/
West Yorkshire.
That rules out the usual 2 test bed locations.
-
Thanks for the url, but the link only works for the person making the query. :/
West Yorkshire.
That rules out the usual 2 test bed locations.
I sorted it, I noticed when I tried to test it.
-
Is their no G.INP on the upload on ECI??
I'm just hoping the news about a second vendor being ginp/vectoring ready means my cabinet is set to somehow get vectoring.
I'm hopeful as my cabinet with vectoring would uplift 10-15% of the people on the cabinet to +24mbit/s.
Considering the cabinet serves >450 I'm not too optimistic as the vectoring engine would use up one of the line card slots.
-
Is their no G.INP on the upload on ECI??
Nope they have said it doesnt support it. The jury is out why this is, because from everything I could find out about g.inp indicated that the ECI cabs should in theory be able to support upstream re-tx.
However, the ECI modems cannot support upstream g.inp. G.INP Retransmission requires more processing and memory to be able to maintain a buffer to store data in case it needs to be retransmitted in the sending direction. For some reasons the ECI modems havent been updated to do this. Whether that is down to lack of hardware (memory or CPU) I dont know.
As regards to the ECI DSLAMs if they are already doing the hardwork for controlling re-tx in the downstream direction and doesnt need a buffer for upstream, I'm mystified why they dont also do upstream. Openreach R&D appear to have been under the [mistaken] impression that all users on ECI cabs were using ECI modems and that all users on Huawei cabs were using Huawei modems. Hence why they came a bit of a cropper when they did roll out to the Huawei cab and realised how many people were using lantiq based modems :/
-
Seems to be a problem with the HG612 GUI, i dont think it's effecting anything but have a look.
Also If I risk plugging in the HH5a directly to see what happens could it steal my G.INP from me?
-
Seems to be a problem with the HG612 GUI, i dont think it's effecting anything but have a look.
If you're referring to the displayed error figures, this is a known bug in the HG612 GUI. The monitoring programs use telnet to collect the data, and to the best of our knowledge this returns correct information.
-
Seems to be a problem with the HG612 GUI, i dont think it's effecting anything but have a look.
If you're referring to the displayed error figures, this is a known bug in the HG612 GUI. The monitoring programs use telnet to collect the data, and to the best of our knowledge this returns correct information.
It's also the noise margins, i'm pretty sure they were reporting correctly not long ago.
Also I'm probably going to sacrifice my G.INP to the HH5a gods, just to see what happens.
-
Well as much as I dislike the HH5a as a modem i'm going to roll with it for now.
At least I now know for sure the HH5a supports G.INP on an ECI cab, It would be completely insane if it didn't but I now know for sure.
-
At least I now know for sure the HH5a supports G.INP on an ECI cab,
Would you clarify how you have made that deduction, please? ???
-
At least I now know for sure the HH5a supports G.INP on an ECI cab,
Would you clarify how you have made that deduction, please? ???
I have synced with the HH5a many times before I got G.INP and have never gotten above 62mbit, also Ping is at 9ms before I got G.INP it was at 10ms.
If G.INP didn't work Id expect the speed to either drop marginally or stay roughly the same.
8th March - G.INp HH5a
6th March - G.INP HG612 - Was streaming however
Before that I had no G.INP and 10ms ping.
Generally I lost 1-2mbit/s using the HG612 instead of the HH5a.
-
Thank you. I now understand your logic.
-
Pity it's not conclusive proof though. It could be just because of the removal of Interleaving on the ECI cabinet setup, or even because of the matching chipsets in the cabinet and HH5.
-
Pity it's not conclusive proof though. It could be just because of the removal of Interleaving on the ECI cabinet setup, or even because of the matching chipsets in the cabinet and HH5.
I've always been on fast path.
With the matching chipset before G.INP I'd get 62mbit/s tops.
I could only know 100% if I got a GEA service test but I'm with BT Retail so it's not worth the hassle.
I'm like 90% sure G.INP is active on the HH5a.
-
You can prove it by comparing your sync speed with your IP Profile :)
-
Sync = 65852
IP Profile =63740
Ratio = 0.968
I know that it definitely works on my HG612 as I have access to stats, on the HH5a I can't be 100% unless the ratio gives a clue.
[attachment deleted by admin]
-
Well that's showing as G.INP being off.
-
Well that's showing as G.INP being off.
Can the ratios be compared to a typical Huawei one?
Their is no bit rate for bearer 1 for example on ECI, is the implementation not different?
Either way it syncs higher than it used to.
Also ratio with HG612 with G.INP on was 0.967.
-
The thing is that G.INP gives you a much smoother connection, ideal for streaming films say. I take it you are aware that you can use the HG612 to feed the HH5 and just use the HH5 as a router.
-
The thing is that G.INP gives you a much smoother connection, ideal for streaming films say. I take it you are aware that you can use the HG612 to feed the HH5 and just use the HH5 as a router.
I'm still convinced the HH5a has G.INP enabled, I know the HG612 is much more stable however the speed sits in my use case with the HH5a whereas without its just outside the zone.
Basically I need enough bandwidth for UHD BT Sports and A UHD stream, the HG612 is just slightly out of the range at the moment.
-
Basically I need enough bandwidth for UHD BT Sports and A UHD stream
You mean simultaneously?
-
Basically I need enough bandwidth for UHD BT Sports and A UHD stream
You mean simultaneously?
Pretty much there is usually something else going on also, can sometimes be 3 UHD steams occurring simultaneously.
Use around 4TB of data a month.
-
And the difference in sync between the HG612 and HH5 makes a difference for you? Amazing.
-
And the difference in sync between the HG612 and HH5 makes a difference for you? Amazing.
It's a case of 61mbit on the HH5a works with no dropping of quality, and I have issues at 58Mbits on the HG612.
Its just a case of that tiny amount of headroom.
-
He means on the HH5a TBailey, I know that it definitely works on my HG612 as I have access to stats, on the HH5a I can't be 100% unless the ratio gives a clue.
Okay, didn't realise that was what you were using. I've pulled that post..
-
I suppose another explanation could be that there's an inherent problem with G.INP on ECI cabs.
-
Well that's showing as G.INP being off.
Can the ratios be compared to a typical Huawei one?
Their is no bit rate for bearer 1 for example on ECI, is the implementation not different?
Either way it syncs higher than it used to.
Also ratio with HG612 with G.INP on was 0.967.
FWIW, the ratio for HG612s without G.INP is approximately 96.79% or 0.968
For HG612s with G.INP active, the ratio is approximately 96.69% or 0.967
That could suggest that G.INP is not actually active when using the HH5a.
However, according to stats from the HG612 with G.INP reported as active when connected to the ECI DSLAM active do show the connection is on fastpath (Bearer 0 Interleaving depth = 1), whereas HG612s on Huawei DSLAMs with G.INP active tend to have Bearer 0 interleaving depths of 8 or 16.
I think we'd have to see more G.INP related stats from other users on ECI DSLAMs before coming to final conclusions.
-
whereas HG612s on Huawei DSLAMs with G.INP active tend to have Bearer 0 interleaving depths of 8 or 16.
I think we'd have to see more G.INP related stats from other users on ECI DSLAMs before coming to final conclusions.
Or Interleaving depths from 2 to 16 as my own G.INP is now set at 4 but it started of at a depth of 8
Would have thought by now if there was a full scale roll-out of G.INP on the ECI cabs we would have seen another user go live :(
-
Maybe they just activated a few cabinets countrywide to see if it resulted in any problems, before a full rollout.
Could it have been activated mistakenly?
-
Could it have been activated mistakenly?
I doubt it. Activation is a two step process. First the cabs have to be upgraded and then they have to roll out new DLM profiles to the individual lines.
Maybe they just activated a few cabinets countrywide to see if it resulted in any problems, before a full rollout.
More likely, but then again theres already been some ECI cabs activated for almost a year. This is why I asked if you were in Martlesham or MK. Perhaps they are slowly extending it. Didnt the Huawei's start off quite slowly over the first few weeks?
-
Is this ever going to happen. This was over a week ago and no other reports for ECI. With having 1400 -2000 ES errors a day thought I would of had it but nothing.
-
Well theres only about 28 active ECI users on MDWS, so compared to Huawei users that's quite small, it took a long time for Huawei to roll out, so it could be a while before we see more ECI users become active, especially if they are being cautious.
-
I am sure we all remember the Huawei G.INP launch last March 2015 from memory 1 or 2 users got G.INP in the first week then a lull and then the second week it was one or three users per week and then I got it on the last week of March 25th at 06:00 hours.
Though there is a much smaller user base on theses ECI cabs it may take another 2 weeks to see a ECI MDWS user show up with G.INP being active.
-
What was the purpose of the rollout of the new firmware?
I am still on the old one, I'd have thought it would be a case of updating the firmware then activating G.INP?
-
What was the purpose of the rollout of the new firmware?
The changes are believed to be those listed in the EMP3050 ECI Release Notes (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/downloads/ECI_NGAE_8_00_3_2_CPE_Release_Notes.pdf)
I am still on the old one, I'd have thought it would be a case of updating the firmware then activating G.INP?
The changes don't refer to G.INP at all. This page (http://forum.kitz.co.uk/index.php/topic,16917.60.html) touches on some of the changes observced as a result of the new firmware.
-
Mr belter on another thread " something has gone wonky" sounds like he may have g.inp, but it's hard to tell as he has a hh5
-
Could it be anything to do with M41 vs M82?
I'm pretty sure my cabinet would have a M82 as it serves over 450 premises, also while looking at the V41 I noticed their is no V82 could that maybe be holding back BT deploying vectoring widely??
With the guy saying his connection went wonky with the HH5 it's more likely the new firmware, as a few people said their speeds dropped slightly when it rolled out.
-
I wasn't aware BT installed any M82s (their application for unmetered electricity supplies only mentioned the two types of Huawei cabinet and the one type of ECI cabinet). BT probably don't install a cabinet anticipating every single line to sign up for FTTC - you might be surprised at the number of people who have FTTC available but haven't signed up for it for whatever reason.
-
I wasn't aware BT installed any M82s (their application for unmetered electricity supplies only mentioned the two types of Huawei cabinet and the one type of ECI cabinet). BT probably don't install a cabinet anticipating every single line to sign up for FTTC - you might be surprised at the number of people who have FTTC available but haven't signed up for it for whatever reason.
I was under the impression of a M41 for a 128 and a M82 for a 256?
-
No, ECI has 64 ports per line card, M41 takes 4 line cards, M82 takes 8.
-
No, ECI has 64 ports per line card, M41 takes 4 line cards, M82 takes 8.
Did the ECI have 64 ports per line card available when BT first rolled them out?
-
Has anyone else who is connected to an ECI cabinet other than S.Stephenson had G.INP enabled?
-
Has anyone else who is connected to an ECI cabinet other than S.Stephenson had G.INP enabled?
Nobody as of yet, if we don't see any others by the end of March i'd start to worry.
So for the time being I get to be a special snowflake.
-
Did the ECI have 64 ports per line card available when BT first rolled them out?
ECI 128/256 is how BT designate them when applying for planning permission. I think the 128/256 may actually have something to do with power consumption - ie how much they pay for electricity.
afaik Openreach have only deployed M41's.
It would appear once they realised the M41's may have a problem with vectoring, they switched back to Huawei.
afaik all of them have 64 ports per line card. They are using VTU-C64 line cards in the M41s which as ejs said, can take up to 4 line card. Therefore if when applying for planning they assume the M41 will have 2 line cards then it will be designated ECI 128, or ECI 256 for 4 line cards.
In actual fact its not quite so straight forward as it being an indicator of the number of line cards.. but more the number of IDC Blocks.
If you look on the FTTC cab page (http://www.kitz.co.uk/adsl/fttc-cabinets.htm) it shows a couple of photographs of one cab provisioned as ECI 256 and another which is designated as an ECI 128.
This particular cabinet is designated ECI 256 - note provision availability for 4 line cards and full IDC rack
...
This cab would be designated EC1 128 - note provision for 2 line cards and only 128 IDC connectors
Note how the cab which according to planning permission was described as an ECI 256. Upon installation it only had one line card.. but had 256 IDC connectors - its a relatively easy task to slot in more line cards when needed.
-
I thought that the only reason they ever even touched ECI was due to the stuff about Huawei that was in the news around the time about China being able to spy through the hardware or something along those lines.
BT are going to be in trouble marketing wise if DOCSIS 3.1 is rolled out in 2016, the lowest speed on Virgin would probably be 100mbps and BT would have no response till G.Fast, even then it would be 330mbps vs 1gbps.
-
I thought that the only reason they ever even touched ECI was due to the stuff about Huawei that was in the news around the time about China being able to spy through the hardware or something along those lines.
The spying stuff was more of a scare story in the USA than in the UK - though HMG/GCHQ test their equipment at the 'huawei cyber security evaluation centre' (https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/416878/HCSEC_Report.pdf)
More broadly, BT have always used (or tried too) at least two suppliers for key infrastructure/equipment - partly to encourage price competition but more importantly to ensure security of supply..
-
Also would anyone be able to notice if they switched a M41 for a V41, for example my connection went down long enough(24mins) when G.INP was enabled for a switch to take place, would the DSLAM/MSAN type: IFTN:0xb204 / v0xb204 change at all?
I'm just tying to be an optimist and overly hopeful.... :D
-
Probably not, especially since the line cards used might be the same. DSLstats 5.7.3 (http://forum.kitz.co.uk/index.php/topic,17232.0.html) does report the vectoring status, so you can see if it ever is enabled.
-
Probably not, especially since the line cards used might be the same. DSLstats 5.7.3 (http://forum.kitz.co.uk/index.php/topic,17232.0.html) does report the vectoring status, so you can see if it ever is enabled.
Thats what I am hoping for ;D ;D :fingers: :fingers:
Doubt it though..... :'(
-
Probably not, especially since the line cards used might be the same. DSLstats 5.7.3 (http://forum.kitz.co.uk/index.php/topic,17232.0.html) does report the vectoring status, so you can see if it ever is enabled.
Thats what I am hoping for ;D ;D :fingers: :fingers:
Doubt it though..... :'(
Have you noticed a decrease in your attainable due to crosstalk what was your attainable before your were hit by crosstalk ?
-
Probably not, especially since the line cards used might be the same. DSLstats 5.7.3 (http://forum.kitz.co.uk/index.php/topic,17232.0.html) does report the vectoring status, so you can see if it ever is enabled.
Thats what I am hoping for ;D ;D :fingers: :fingers:
Doubt it though..... :'(
Have you noticed a decrease in your attainable due to crosstalk what was your attainable before your were hit by crosstalk ?
I have been completely destroyed by crosstalk, I when I first got the HH5a saw attainables of high 90's, Since then I have reduced my attenuation from 16.3 to 14.2 by having the line shortened.
Also see one of my crosstalkers below and my abysmal QLN.
-
I have been completely destroyed by crosstalk, I when I first got the HH5a saw attainables of high 90's, Since then I have reduced my attenuation from 16.3 to 14.2 by having the line shortened.
Also see one of my crosstalkers below and my abysmal QLN.
Ouch! I cant see the scale from the graph, so dont know the figures... so Im estimating. Is that circa 15Mbps loss?
-
I have been completely destroyed by crosstalk, I when I first got the HH5a saw attainables of high 90's, Since then I have reduced my attenuation from 16.3 to 14.2 by having the line shortened.
Also see one of my crosstalkers below and my abysmal QLN.
Ouch! I cant see the scale from the graph, so dont know the figures... so Im estimating. Is that circa 15Mbps loss?
It drops from 81 to 65, on a ECi modem I'd probably sync at 79999, they just need to move away or become Amish.
Also I'm pretty sure my cabinet would be the best in the area in terms of uplift to above 10mbps from vectoring, so :fingers: USO.
In the image below the black star is the cabinet, the circles are the postcodes served by the cabinet, Wragby is around 2km from the cabinet and is like 10-15% of the houses attached to the cabinet, and a local pub in wragby gets the estimate show below.
-
Also I'm pretty sure my cabinet would be the best in the area in terms of uplift to above 10mbps from vectoring, so :fingers: USO.
In the image below the black star is the cabinet, the circles are the postcodes served by the cabinet, Wragby is around 2km from the cabinet and is like 10-15% of the houses attached to the cabinet, and a local pub in wragby gets the estimate show below.
The good news for you is that Openreach's spec for FTTC modem testing now insists on new models undergoing testing having the ability for both G.INP and Vectoring to operate together; and that modems can sync at 1800m and 2400m.
The USO is still some years away and depending on local economics - and if they have a BDUK target to meet/funding - BT could decide to install FTTP/N in the Wragby area instead..
-
As I'm ~350m from the cabinet I'd rather they rollout Vectoring, but hopefully they'll be able to get better than 6mbits in the future.
Other than vectoring my only option to meet my requirements(70mbits) seems to be FTTPoD, hopefully the new method they are using will make the costs similar to when they first started offering it.
-
Other than vectoring my only option to meet my requirements(70mbits) seems to be FTTPoD, hopefully the new method they are using will make the costs similar to when they first started offering it.
You could bond or load balance 2 FTTC lines now. It may well be cheaper than paying for FTTPoD and certainly quicker to achieve..
-
You could indeed. It works extremely well.
-
The good news for you is that Openreach's spec for FTTC modem testing now insists on new models undergoing testing having the ability for both G.INP and Vectoring to operate together; and that modems can sync at 1800m and 2400m.
The vectoring test at 1800m and 2400m was removed from BT SIN 498 v7.1. I thought that vectoring provides less improvement for very long VDSL2 lines anyway, and the test was just so that they still establish a connection.
The CPE under test should also be connected to a 1800m and 2400m length of
cable to check that it still synchronises with vectoring enabled. Although no
significant performance gains are expected at these lengths , it is important to
verify that the CPE continues to function on a long line with vectoring
enabled.
That paragraph was removed from SIN 498 7.1.
-
The vectoring test at 1800m and 2400m was removed from BT SIN 498 v7.1. I thought that vectoring provides less improvement for very long VDSL2 lines anyway, and the test was just so that they still establish a connection
Thanks - you are right about the limitations of vectoring - and I had intended to include that when I referred to other technologies being used instead but forgot. :blush:
Also, thanks for mentioning v7.1 - I hadn't noticed they had issued the .1
-
If FTTPoD is around the cost it was when it first released when they offer the newer solution then it's a cheaper and more robust solution in the long run.
Plus I'd more than likely reduce both the lines speeds to something like 55 with crosstalk knowing my luck :o
I'm not making any changes till the new prices are released for FTTPoD.
-
After looking more into load balancing and combining them via a VPN type service, I've ordered a second line from Plusnet as my BT contract is over well before I see FTTPoD becoming available again.
Hoping the lines even with the crosstalk will give total 110mbps down and 32mbps upload.
-
Be sure to keep us up date on how it performs, perhaps in a new thread though.
-
Be sure to keep us up date on how it performs, perhaps in a new thread though.
I will do, the install date is on the 1st of April, hopefully there is enough pairs left at the DP.
Also I assure everyone in advance any posts made by me about the above subject on April the first will be legitimate.
Basically i'll combine the connections via a VPN on an service on my primary device, the BT connection will be mainly for the BT Youview box which involves a lot of either streaming or IPTV.
The plusnet connection will be my precious nobody else will get to touch it ;D ;D
Anyway to tell if my dropwire has more than one pair in it?
-
Take the master socket off and see if there's a couple of spare wires in the cable which goes to the A&B terminals
-
It's now 8 days since your ECI cabinet got G.INP and no other user is seeing the same have been looking though the BT forums and other forums like TT and PlusNet and even Thinkbroadband I am starting to think this is a one off anomaly.
Have you any close friendly neighbours with FTTC and ask them would they mind you setting up the HG612 to monitor their line stats in relation to scientific broadband testing.
-
It's now 8 days since your ECI cabinet got G.INP and no other user is seeing the same have been looking though the BT forums and other forums like TT and PlusNet and even Thinkbroadband I am starting to think this is a one off anomaly.
Have you any close friendly neighbours with FTTC and ask them would they mind you setting up the HG612 to monitor their line stats in relation to scientific broadband testing.
All my neighbors are hell spawn, except the nice ones to the right who have access to my guest network (limited to 10mbits)so have no broadband.
Surely though everyone on my cabinet has to have access to G.INP, and the HG612 has been swapped out a few times and reconnected, so G.INP is definitely activated and staying that way.
My theory is that they're either testing for longer than usual due to the trouble they had last time or they have something special planned for my Cabinet.
-
Take the master socket off and see if there's a couple of spare wires in the cable which goes to the A&B terminals
Is attached to plasterboard I don't feel confident on it being able to reattach to the wall.
Drop wire is less than 6 months old, so does that rule out 1 pair wire?
-
My theory is that they're either testing for longer than usual due to the trouble they had last time or they have something special planned for my Cabinet.
Yes if your FTTC cabinet is live with G.INP then others that use the same cab will also have it, I can't see the same trouble arising because this time it's an ECI cab and G.INP is turned off on the upstream as standard because the ECI modems and ECI cabinets can't do RTX-TX on the upstream side
We know the huawiei US G.INP can be turned on if the DLM sees issues and the hardware supports both US & DS G.INP, wondering what will happen with a ECI users line when the US errored seconds go's skew whiff as you won't have US G.INP to kick in
-
"Drop wire is less than 6 months old, so does that rule out 1 pair wire?"
1 pair is very rare (of the black stuff)... 2 pair+ is by far and away more common.
-
Well according to someone in this thread they are on the same exchange and not that far away from me and they don't have G.INP, I'd have expected them to have rolled out to every cabinet on my exchange by now.
If we see nothing by the end of the Month then id be wondering what the hell they are doing.
-
"Drop wire is less than 6 months old, so does that rule out 1 pair wire?"
1 pair is very rare (of the black stuff)... 2 pair+ is by far and away more common.
Well that simplifys the install of the second line but does it increase the crosstalk vs 2 separate lines?
I should get above 100mbps on the download total so it more than meets my requirements.
-
Well according to someone in this thread they are on the same exchange and not that far away from me and they don't have G.INP, I'd have expected them to have rolled out to every cabinet on my exchange by now.
If we see nothing by the end of the Month then id be wondering what the hell they are doing.
They have to be using the same Cabinet the exchange is nothing, you may have inadvertently raised the hopes for these guys it's deffo not a full rollout for ECI cabs and the Interleaving level is somewhat very different to what is expected for real G.INP :(
-
Well according to someone in this thread they are on the same exchange and not that far away from me and they don't have G.INP, I'd have expected them to have rolled out to every cabinet on my exchange by now.
If we see nothing by the end of the Month then id be wondering what the hell they are doing.
It doesn't surprise me that we have seen no other confirmed instances of G.INP yet - and I can easily foresee the possibility of no others being confirmed until April at the earliest.
This is because I suspect Openreach won't want to enable any lines over the Easter holiday period. So you potentially have is one of the first lines to be enabled, followed by an extended testing period and then a gradual increase in the number of lines enabled as they become more confident that there are no unexpected problems - and that the entire rollout could take months.
I also think that assuming others on the same cabinet also have G.INP isn't necessarily correct. With the Huawei roll out it was quite common to have some lines enabled on a cabinet and others not.
What will be interesting is how quickly your new line has G.INP enabled..
-
Its kind of lucky that I use DSLStatus otherwise we'd be none the wiser, however I suppose it makes the wait even more agonising for those without.
In regards to the interleaving expected, the ECI implementation seems to do the job just fine my DS is as stable as a rock 0ES a day currently, wish I could say the same for the upstream. There was no noticeable increase in latency either,so it's definitely doing its job.
-
Its kind of lucky that I use DSLStatus otherwise we'd be none the wiser, however I suppose it makes the wait even more agonising for those without.
In regards to the interleaving expected, the ECI implementation seems to do the job just fine my DS is as stable as a rock 0ES a day currently, wish I could say the same for the upstream. There was no noticeable increase in latency either,so it's definitely doing its job.
That is why we need to see more ECI G.INP data sooner rather than later and I know you have G.INP using a ECI cabinet but with all scientific tests we need to take other samples.
I am sure you can understand you just can't take just one user data as a reference to ECI G.INP it would be unscientific to do so and the reason for caution.....
-
the Interleaving level is somewhat very different to what is expected for real G.INP :(
But interestingly at the same level of the other user on an eci cab which also has has ginp enabled. I posted a link earlier in the thread to show his stats. Both his and s stephensons are set the same.
-
Bought one of these : http://www.amazon.co.uk/TP-LINK-TL-ER5120-Gigabit-Balance-Broadband/dp/B0064JCRXE
Judging from what I've read it supports 180mbps max so works perfectly for my needs.
Also reading up on load balancing it looks like it does what I was going to use the bonded VPN for (downloads from places that use multiple threads) so for my purpose it's a perfect solution.
-
Looks like we have another G.INP user, jamesfoley, uptime 48 minutes :)
-
Just woke up to G.INP on my line. Not sure what has changed as I didn't have interleaving on my line before it was applied...
If I can get hold of another HG612 I could stick it on my parents line to see if they're the same. They had a bad line due to being far away from the cab with a mixture of bad phone lines, would be interesting how it would perform there.
-
What exchange are you on just out of curiosity if you don't mind me asking
-
Hi James
It looks like you too are showing B0 Interleaving =1, so it looks like it may be the default config for the ECIs.
Can you provide output from these please xdslcmd info --stats & xdslcmd info --pbParams and also --vendor
Thank you :)
-
mine has just gone g.inp too...(skyeci)
-
mine has just gone g.inp too...(skyeci)
Ping time has dropped from a previous value of 20 to now being 12.
skyECI
This is an advisory mail to let you know that G.INP is now enabled for your line with Downstream Sync of 51324kbps ...
Automatic message from MyDSLWebStats
-
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 36381 Kbps, Downstream rate = 104428 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 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.8 16.1
Attn(dB): 10.8 0.0
Pwr(dBm): -5.0 -5.0
VDSL2 framing
Bearer 0
MSGc: -6 150
B: 178 236
M: 1 1
T: 0 5
R: 6 16
S: 0.0712 0.3771
L: 20780 5410
D: 1 1
I: 185 255
N: 185 255
Q: 16 0
V: 2 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 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 2167360
OHFErr: 0 4
RS: 742651712 3369820
RSCorr: 158 59
RSUnCorr: 0 0
Bearer 1
OHF: 826521 0
OHFErr: 0 0
RS: 9917510 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 46 0
rtx_c: 38 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 79982 0
errFreeBits: 16196719 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2042402461 0
Data Cells: 9047861 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: 9255 1509
SES: 12 0
UAS: 63 52
AS: 13276
Bearer 0
INP: 46.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.15
OR: 0.01 202.87
AgR: 80111.28 20203.27
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 9241/9241 0/0
Total time = 1 days 8 hours 4 min 42 sec
FEC: 158 59
CRC: 0 4
ES: 9255 1509
SES: 12 0
UAS: 63 52
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 4 min 42 sec
FEC: 0 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: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 8 hours 4 min 42 sec
FEC: 158 59
CRC: 0 4
ES: 29 6
SES: 11 0
UAS: 37 26
LOS: 1 0
LOF: 9 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 0 0
ES: 162 30
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 3 hours 41 min 15 sec
FEC: 158 59
CRC: 0 4
ES: 0 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 36381 Kbps, Downstream rate = 104428 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 36381 kbps 104428 kbps
Actual Aggregate Tx Power: - 5.0 dBm - 5.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.0 14.3 N/A N/A 6.2 13.4 22.0
Signal Attenuation(dB): 0.1 9.8 14.2 N/A N/A 7.8 13.3 22.0
SNR Margin(dB): 19.6 16.0 16.1 N/A N/A 11.8 11.8 11.8
TX Power(dBm): -9.7 -128.0 -6.8 N/A N/A 7.8 7.4 7.5
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 36403 Kbps, Downstream rate = 104428 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id: IFTN:0xb206
ChipSet VersionNumber: 0xb206
ChipSet SerialNumber: 5502482094
-
thanks James - looks like you have the updated f/w
0xb206
... and here comes another ECI cab member with g.inp @ 10:34 (daveesh) with interleaving = 1 :)
---
ETA
Hang on a mo.. I cant see that it is. I'd just walked in after getting back from the dentist and saw these emails
G.INP is now enabled for skyECI
G.INP is now enabled for daveesh1
-
btw has anyone else noticed that the output from vendor is now showing their Chipset Serial Number?
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 5502152235
Im sure it didn't used to.. or is it just for the ECIs?
-
Just had an email to say G.inp is active. Not at home at the mo will check when i get in
-
Also simon194 too :)
I am quite surprised these changes are being done in the daytime.
Kitz, my vendor info (no G.INP - yet):
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 5501682195
-
Just had an email to say G.inp is active. Not at home at the mo will check when i get in
Yes I saw that too yet when I looked on MDWS I couldnt see any G.INP parameters, nor did it show daveesh1 G which is why I suddenly wondered what was going on.
Yet Ive just looked again now and it is showing g.inp data - perhaps some sort of caching issue in my browser? It certainly does look like you have it.
I am quite surprised these changes are being done in the daytime.
Stage 2 of the g.inp upgrade is a DLM update to the EU's line ... and since DLM changes can now occur at any time of the day then its not too surprising. Any DLM changes made to my line are usually done at around 11-12 in the day.
Its interesting though that a whole batch of MDWS have all gone today, so seems like just with the Huawies, they started off slow then speeded up a bit.
-
Hi there everyone,
Can anyone see a pattern to where these ECI users are based, i.e. I think one specified West Yorkshire. Is it likely that this will be switched on region by region or is it just random ?
Here's hoping
toulouse
-
Yes I saw that too yet when I looked on MDWS I couldnt see any G.INP parameters, nor did it show daveesh1 G which is why I suddenly wondered what was going on.
Yet Ive just looked again now and it is showing g.inp data - perhaps some sort of caching issue in my browser? It certainly does look like you have it.
There are a number of database mods to do to get G.INP data active after the initial detection and can take a while to finish depending on other background activity....
I get the impression that most of the ones I've seen on ECI so far have lost some D/S sync rate rather than gained :-\
-
I wonder if all the 'doom and gloomers' (ECI's will never get G.INP etc etc ), will be cleaning the egg from their faces sometime soon ?? ;) ;D
-
I see what you mean tbailey, having a look at the user stats it seems most people are loosing around 2mb on the downstream, that's not so good. Now the ECI users will be on here in a couple of months "remember when we had no G.INP, I preferred those speeds!" lol. I suppose some people with bad lines may gain speed from this because of the error correction
-
I see what you mean tbailey, having a look at the user stats it seems most people are loosing around 2mb on the downstream, that's not so good. Now the ECI users will be on here in a couple of months "remember when we had no G.INP, I preferred those speeds!" lol. I suppose some people with bad lines may gain speed from this because of the error correction
As the saying goes - 'be careful what you ask for".
But as user on a long line - about 2km - I might gain some upload.
-
I gained 2mbps on a noisy line, but looking at what happened to others it seems like i'm the only one who got a higher sync from it at the moment.
-
I see what you mean tbailey, having a look at the user stats it seems most people are loosing around 2mb on the downstream
I can't see where you're getting that from.
Anyway, it's fairly easy to find a modem that doesn't support G.INP or downgrade the firmware.
-
I gained on ds and lost a bit on us. But the best bit is my latency is now 12ms instead of 20ms as it has been since I had fibre.
Very happy with that result. I am in frome somerset in case anyone wants to know
Mydsl stats user "skyeci"
-
I just noticed the losses too.. I've been playing in excel and its looking like a loss of 2Mbps from the downstream.
The two that havent are either on a capped 40Mb or able to achieve more than 80Mbps.
I gained on ds and lost a bit on us.
According to the figures in excel that I have for you - youve actually lost 1906 kbps downstream and 874 upstream :(
*goes to double check the figures.
--
ETA
Definitely lost just shy of 2Mbps.
-
There are a number of database mods to do to get G.INP data active after the initial detection and can take a while to finish depending on other background activity....
I get the impression that most of the ones I've seen on ECI so far have lost some D/S sync rate rather than gained :-\
Ahh thank you that explains the yes/no/yes :D
Yep also noticed it - not looking too good atm :(
-
I just noticed the losses too.. I've been playing in excel and its looking like a loss of 2Mbps from the downstream.
I gained on ds and lost a bit on us.
According to the figures in excel that I have for you - youve actually lost 1906 kbps downstream and 874 upstream :(
*goes to double check the figures.
Tbh I am happy with any sync rate over 50mb and upstream over 19mb. My neighbour was causing me huge cross talk issues which before g.inp my latency had a 8ms delay and poor snr.
Also completed all my internal cat5e hardwired networking today, christmas came early with the 8ms delay being removed. Couldnt be happier for a change. Flawless gaming on a recent test ::)
-
Out of the people who have eci ginp how many have better speeds and how many worse and how much worse?
Sent from my Wileyfox Swift using Tapatalk
-
From the tests I ran this morning I don't seem to have any noticeable change in download or upload. My ping also hasn't really changed, everything still below 10ms. Only thing I can really see is that I no-longer get any DS errors.
-
From the tests I ran this morning I don't seem to have any noticeable change in download or upload. My ping also hasn't really changed, everything still below 10ms. Only thing I can really see is that I no-longer get any DS errors.
That will be because you were syncing at 80/20 which plenty of spare. Your attainable has actually increased.
Out of the people who have eci ginp how many have better speeds and how many worse and how much worse?
See attached. Ive also included attainable because :-
1) There a couple of people who are capable of receiving more than the 40 or 80 Mbps product spec.
2) It could also show a more realistic figure, due to this parameter changing in real time (ie deviation from 6dB SNRm)
-
Kitz yeah looks about right for me. I am on Infinity 1 so capped at 40. At least my errors have now dropped to zero. can see I have Interleaving Off on up and down INP as 47 and Delay 0 on Both
-
MikeZ has joined the party :)
-
And he has seen a nice 5Mbps downstream rate increase!
-
MikeZ has joined the party :)
Indeed! A few weeks ago I had DS interleaving applied and it wasn't clear why, as ES were not high enough to cause DLM to intervene on the speed profile.
At 10:46 this morning I had a brief resync (just a few seconds) and the line came back with interleaving removed and G.INP enabled.
In the minutes following the resync I had three e-mails from MDWS - one saying G.INP was enabled, followed by one saying it was disabled, followed by another saying it was enabled ???
Firmware is 0xb206 and I'm in Northampton.
-
MikeZ has joined the party :)
Indeed! A few weeks ago I had DS interleaving applied and it wasn't clear why, as ES were not high enough to cause DLM to intervene on the speed profile.
At 10:46 this morning I had a brief resync (just a few seconds) and the line came back with interleaving removed and G.INP enabled.
In the minutes following the resync I had three e-mails from MDWS - one saying G.INP was enabled, followed by one saying it was disabled, followed by another saying it was enabled ???
Firmware is 0xb206 and I'm in Northampton.
I am also from Northampton but no G.INP for me as of yet but it's nice to know someone from my town has it.
-
My part of Northampton (Weston Favell Exchange) has had G.INP for ages (Huawei cabs). Which part on NN (which exchange) are yous?
-
My part of Northampton (Weston Favell Exchange) has had G.INP for ages (Huawei cabs). Which part on NN (which exchange) are yous?
NN5 here and on an ECI cabinet (Duston).
-
My part of Northampton (Weston Favell Exchange) has had G.INP for ages (Huawei cabs). Which part on NN (which exchange) are yous?
Hardingstone exchange - NN4.
-
NN16 Kettering. We have also had G.inp on Huawei cabs since last year but at last we have it on ECI and my lights are all green for the first time in a long time
-
I take it all who have seen G.INP being enabled on a ECI cabinet are using the HG612 or compatible modem with telnet rather than a ECI modem locked or HH5A as they won't show up the G.INP data.
My question will G.INP work on an ECI cabinet with a ECI modem or a HH5A
-
I take it all who have seen G.INP being enabled on a ECI cabinet are using the HG612 or compatible modem with telnet rather than a ECI modem locked or HH5A as they won't show up the G.INP data.
My question will G.INP work on an ECI cabinet with a ECI modem or a HH5A
Yes, I'm using an HG612. Given that openreach assume that most users of an ECI cab have an ECI modem I would have thought that the ECI modems would have had a firmware update to support G.INP. I still have my ECI modem but I'm reluctant to try it, just in case I lose G.INP and don't get it back for a while.
-
I take it all who have seen G.INP being enabled on a ECI cabinet are using the HG612 or compatible modem with telnet rather than a ECI modem locked or HH5A as they won't show up the G.INP data.
My question will G.INP work on an ECI cabinet with a ECI modem or a HH5A
I saw increases in speed with both the ECI Modem and HH5a, no way to tell 100% unless you have a unlocked ECI modem however.
HG612 before G.INP = 60mbps
HH5a before G.INP = 62mbps
HG612 after G.INP = 62mbps
HH5a after G.INP = 65mbps
Was constantly in that range before G.INP, so unless G.INp got rid of a fair amount of noise it seems to be active on the HH5a.
I've also swapped between all three with G.INP always being shown as active on the HG612.
-
btw I updated the list to add MikeZ's stats and attached it below.
I've also added in the interleaving and error correction parameters from prior to g.inp being applied.
I would expect those that previously had interleaving/INP applied to benefit the most from g.inp, so those are the group of people whom I would most likely expect to see sync speed increases from.
-
I take it all who have seen G.INP being enabled on a ECI cabinet are using the HG612 or compatible modem with telnet rather than a ECI modem locked or HH5A as they won't show up the G.INP data.
My question will G.INP work on an ECI cabinet with a ECI modem or a HH5A
I am on 8800nl as hg612 gave me loads of errors and packet loss from the trials I did. Latency improved again today now at 11ms.
-
I've also swapped between all three with G.INP always being shown as active on the HG612.
That is good testing S.S and I tend to go with you and mikez because why enable G.INP on a ECI cabinet if those ECI or HH5A FTTC modems are unable to make use of it downstream only that is the upstream seems like a grey area for the moment :-\
I am just so glad to see ECI cabinets get G.INP have waited over 1 year to see this event :)
-
Would someone like to check and see if another way of identifying g.inp via the IPprofile still applies on the ECI cabs in the same way as it does for the Huawei cabs.
From IPprofile (http://www.kitz.co.uk/adsl/IPprofile.htm#IP_and_bRAS_profiles)
Calculated as 96.79% of the sync speed or 96.69% for g.inp lines.
You can find out your IProfile from http://speedtest.btwholesale.com/
-
HH5a sync = 64138
IP profile = 62080
Ratio = 96.79%
It is 96.69 with G.INP enabled on the HG612, so it certainly points to it being off....
Could it be reduced noise due to G.INP?
-
Is the router responsible for updating the IP Profile?
-
I take it all who have seen G.INP being enabled on a ECI cabinet are using the HG612 or compatible modem with telnet rather than a ECI modem locked or HH5A as they won't show up the G.INP data.
My question will G.INP work on an ECI cabinet with a ECI modem or a HH5A
Yes, I'm using an HG612. Given that openreach assume that most users of an ECI cab have an ECI modem I would have thought that the ECI modems would have had a firmware update to support G.INP. I still have my ECI modem but I'm reluctant to try it, just in case I lose G.INP and don't get it back for a while.
Yes, I would have thought the ECI modems and HH5A would have received a firmware update to support G.INP in both directions. But it appears that this did not happen, and no-one knows why not. OpenWRT running on either of those devices can do it, so I think it isn't a hardware limitation.
-
Is the router responsible for updating the IP Profile?
The RAP part of RAMBO does it. When you sync up, the RAP function sends the info to the BRAS control.
Sometimes there is a slight delay and it's why bt recommend something like 60 seconds if you switch off your router to ensure that the system recognises a resync and change of sync speed.
There's more info and diagram on this page
http://www.kitz.co.uk/adsl/DLM_system.htm#RAP
-
I have now obtained some raw stats from skynewb in order to try to compare G.INP from an ECI cabinet DSLAM against G.INP from a Huawei DSLAM (mine).
See the attached montages.
We already know from testing that skynewb's connection is quite significantly affected by crosstalk from his neighbour, so I'm a little surprised to see zero LEFTRS counts.
His neighbour uses a locked ECI modem though, so we don't know for sure whether G.INP is now active on that connection or not.
-
Raw stats for comparison attached.
-
Any info into why the ECI cabs are using an interleaving depth of 1 when in G.INP mode it would seem the ECI G.INP looks better than the Huawei G.INP at a glance.
-
Nope sorry.
They obviously will have different config files.. because by all accounts upstream g.inp isnt going to happen any time soon.
When I have a clear head Im going to look at the raw stats BE provided to see if I can see any other differences.
-
I've taken a break from fixing my server, and taken a look at MDWS for the new ECI G.INP lines.
All looks reasonably well... The retransmission counters show it to be being used, and in every case, it has reduced CRCs to, or near zero and ESs to zero. There is a variety of impacts on FECs, depending on how the line was behaving before activation
For the two lines that had DLM intervention before, skyECI and MikeZ, the FEC rate reduced considerably. I presume the deactivation of interleaving means that the FEC process became less effective, and that more failures fell through. However, those extra failures are now mopped up successfully by the retransmission process.
The two lines that had no DLM intervention, S.Step and jamesfoley, both had no FECs (no surprise if the FEC process is deactivated, as ought to be standard), and low/no CRC and ES counts before activation. After retransmission was turned on, alongside FEC activation, jamesfoley's line starts up with a low level of FECs, a low level of retransmission, and the loss of all CRCs and ESs. S.Step's line is better, as it starts and ends with no CRCs and no FECs, and show a low level of retransmission happening. Strangely, it counted a non-zero ES level, beforehand, even with zero CRCs. Of note for S.Step is the sudden appearance of prolonged spikes of upstream FECs.
That leaves two further lines, Simon194 and daveesh1. These two lines do not show DLM intervention beforehand, with a zero INP value and no interleaving. However, both lines showed FEC counts even before G.INP activation, suggesting that the modems had chosen to turn on FEC anyway. In both cases, activation of G.INP results in FECs continuing, and both CRCs and ESs dropping to zero, alongside some use of retransmission.
This thread contains an amount of speculation about why the downstream speed has changed in the way it has, some up some down. I have no magic answers, but I suspect part of the answer comes down to the relative changes to the FEC settings, and the relative amount of bandwidth being "stolen" for the FEC parity overhead. We'd need to see a lot more of the before and after raw framing data to figure that out.
We can do a little bit of analysis, though.
- First, we can see that DLM has used 4 different INP values - 46, 47, 49, 50. Presumably ordered from best to worst.
- jamesfoley's line has INP=46, and gets FEC settings of R=6, N=185. This means 3% of the line's bandwidth is now being used for this small amount of FEC alongside retransmission.
- skyECI/skeynewb's line has INP=50, and gets FEC settings of R=12, N=240. This means 5% of the line's bandwidth is gobbled up by overhead.
With a sample size of two, it is hard to reach proper conclusions, but it looks like higher INP values make for higher FEC overheads.
@BE
Skynewb's retransmission usage is higher than the others, and has a few more spikes, but doesn't appear that heavy. I'm not sure how much heavier it would need to be to start registering LEFTRS.
-
Two more this morning
shadow4dog was not interleaved, 66 > 68 actual
jamesmayl was interleaved (1200) 64.3 > 70.6 actual
Watching eventful F1 while opening birthday presents and sipping a cup of tea :)
-
Hmm second re-sync. Larger drop in upstream this time. Higher Latency has returned. Not so good...
-
Watching eventful F1 while opening birthday presents and sipping a cup of tea :)
Happy birthday Tony!
Interestingly, my BT line with a HH5 connected and a much lower sync (61Mb vs 66Mb) hasn't been G.INP'd
Tim
-
Hmm second re-sync. Larger drop in upstream this time. Higher Latency has returned. Not so good...
It looks like DLM intervened upstream, and put an 8ms delay, INP=2.5 setting in place.
In turn, it looks like you had a lot of upstream ES's yesterday, with two prolonged bursts of CRC's at 6am and 7pm. Unfortunately, the CRC graph makes them look dwarfed by a couple of tall, one-off spikes downstream ... which aren't so important to DLM, as they only resulted in a couple of ES's.
You had similar prolonged bursts on Friday too. Heating?
-
Could be. The weird thing is pre g.inp my upstream was always synced at 20mb even though the ds was a bit hit and miss. I seem to be in a worse position now than before g.inp...
-
My BT line with a HH5a resynced today, on the same CAB. It's sync has increased from 61Mb to 65Mb, but it doesn't appear to have G.INP turned on (using the profile/sync rate calculation) It has no interleaving, appearing to be running in "fast" mode.
I'm gonna see if replacing it with an 8800 will make any difference... I assume the CAB will detect a modem capable of support G.INP and turn it on.
Tim
-
Just quickly, are the ECI modems working OK with G.INP on ECI cabs?
Cheers,
-
Hi Tim
Which cabinet are you on? - I use an 8800nl which is detecting g.inp on my line..
Cheers
-
My BT line with a HH5a resynced today, on the same CAB. It's sync has increased from 61Mb to 65Mb, but it doesn't appear to have G.INP turned on (using the profile/sync rate calculation) It has no interleaving, appearing to be running in "fast" mode.
I assume your BT line isn't the one monitored by MDWS. Can I ask what we should call the monitored one, for future reference?
I'm gonna see if replacing it with an 8800 will make any difference... I assume the CAB will detect a modem capable of support G.INP and turn it on.
I can't be sure, but I thought the way it happened on the original Huawei rollout was that detection of valid modems was down to DLM - so wasn't a "live" decision. Therefore swapping between valid and invalid modems caused temporary mismatches of capabilities until DLM caught up. Perhaps that was amplified because, during the rollout, DLM took a while to catch up.
Perhaps this is a figment of my memory, or went away when the mk.II rollout happened. Anyone else remember?
-
Hi Skynewb and WWWombat.
The cabinet is an ECI cabinet in Seaford, East Sussex.
I assume your BT line isn't the one monitored by MDWS. Can I ask what we should call the monitored one, for future reference?
Your assumption is spot on. It's my Plusnet line. They load balance between each other. I did have an HG612 attached to the BT line but it synced at a much lower rate - about 55Mb vs 60Mb for the HH5.
What I find interesting is the Plusnet gained 2Mb with G.INP enabled and the BT line gained 5Mb (was 60Mb now 65Mb) with no G.INP!
I think you're gonna be right... it's going to take a while for the DLM to notice it's not connected to the HH5 anymore.
Tim
-
Hi Skynewb and WWWombat.
The cabinet is an ECI cabinet in Seaford, East Sussex.
I assume your BT line isn't the one monitored by MDWS. Can I ask what we should call the monitored one, for future reference?
Your assumption is spot on. It's my Plusnet line. They load balance between each other. I did have an HG612 attached to the BT line but it synced at a much lower rate - about 55Mb vs 60Mb for the HH5.
What I find interesting is the Plusnet gained 2Mb with G.INP enabled and the BT line gained 5Mb (was 60Mb now 65Mb) with no G.INP!
I think you're gonna be right... it's going to take a while for the DLM to notice it's not connected to the HH5 anymore.
Tim
I've experienced the same thing with the exact same line, it gained 2mbps with the HG612 but with the HH5a it gained 5.
Interesting thing is even when I swap between the two G.INP still hasn't been turned off on the HG612.
-
Are you judging that G.INP isn't active (in some cases) based purely on looking at the IP profile ratio?
Personally, I wouldn't be so quick to judge on that alone. We already know that the outcome of ECI G.INP exhibits some visible differences, and I wouldn't be surprised if there were some invisible ones too.
I would say the technique has the potential to give us the answer, but like most things with the HH5A and the ECI modems, the details for the proof is lacking.
I'm trying to use the detailed stats to see if I can see more, so I'd welcome more examples...
-
Hi,
Just wondered if someone could clarify that since my last re-sync according to the traffic light system everything is now back at 86400s and 0es so would there be any possibility of a re-sync upwards as my upstream has come down from 20mb to 17mb or is this the way dlm will leave it - just wondered if you are at the top end will it try to increase your speed etc.. My upstream does have delay,interleave and g.inp.... ???
cheers
-
would there be any possibility of a re-sync upwards as my upstream has come down from 20mb to 17mb or is this the way dlm will leave it
All those errors that caused the bursts of CRCs and ES's (upstream) that triggered the DLM intervention have now become FEC's, leaving a zero ES rate. That means DLM has deployed a solution that successfully defeats the noise, but it doesn't mean the noise itself has gone.
I would imagine that DLM could choose to de-intervene if it only looks at the ES rate. However, my gut feeling is that it probably also checks the FEC rate, to see if that isn't too high; this would make sense to me, but has no official confirmation whatsoever.
Unfortunately, the MDWS graphs for FECs auto-scale themselves, and the sporadic, but large, spikes of downstream FECs make the behaviour of the upstream FECs almost invisible, so it is hard to tell.
My upstream does have delay,interleave and g.inp.... ???
Your upstream now has had an old-style DLM intervention, setting an INP of 2.5 and a delay of 8ms; the modems have turned on FEC and interleaving. However, it doesn't look to have G.INP running upstream; I wouldn't expect it, either.
-
btw I updated the list to add MikeZ's stats and attached it below.
Any chance of an updated sheet? Very useful. Any clues on why some users are loosing quite large amounts of speed? Tia
-
Unfortunately, the MDWS graphs for FECs auto-scale themselves, and the sporadic, but large, spikes of downstream FECs make the behaviour of the upstream FECs almost invisible, so it is hard to tell.
The graphs have always had a facility to drag/zoom any area so if you do this between any unwanted peaks....
-
The graphs have always had a facility to drag/zoom any area so if you do this between any unwanted peaks....
I was trying that recently, but it looked like you could only zoom so far, before it just chose to shift the focus forwards or backwards in time. Every change I made ended up with a large peak at the left, or one at the right; I could never focus on just the in-between portion.
-
I've been back and tried again. I was trying to replicate your image, and can only achieve the one attached below. I cannot zoom in a way that gets rid of both spikes.
-
I should also add that sometimes I don't really want to zoom the timeline down either.
When I'm analysing these things, I usually have 2 or 3 frames in use, where the other frames keep track of changes to INP or resyncs, or ES's, CRC's, re-transmission counters, etc - so I can see the interplay between multiple graphs at the same time. Having correlated timelines makes this easy ... and getting matching zoomed timelines ends up quite awkward - especially if you have to fiddle to move a spike off one side.
-
I've been back and tried again. I was trying to replicate your image, and can only achieve the one attached below. I cannot zoom in a way that gets rid of both spikes.
Reduce the time period to 24 hours in that particular case which works... it may not always with Google in control
-
I often have to zoom in on MDWS especially for FECS as large spikes just overpower the smaller ones and you have to use the cursor/mouse pointer on the X axis to see the smaller values.
-
Reduce the time period to 24 hours in that particular case which works... it may not always with Google in control
Ah, right. That works OK. So you can only zoom in so much (down to a 6 hr window) when the original view is set to "24 hours". If it is set to "2 days", the smallest window becomes 12 hr, and if set to "10 days", the smallest window becomes 60 hours.
Great if you only need to zoom into the last few hours, provided there is no spike within 6 hours, but less good when I want to zoom into the equivalent point 3 days ago. I guess we get whatever Google decides...
I often have to zoom in on MDWS especially for FECS as large spikes just overpower the smaller ones and you have to use the cursor/mouse pointer on the X axis to see the smaller values.
That's the alternative - to zoom in as much as you can, then hope that hovering the mouse can produce enough separate results in the pop-up.
-
FWIW, I have attached ongoing stats montages from skynewb's connection for the latest 1, 6 & 21 days.
-
Morning all. I have had G.INP applied overnight with some interesting results. Previously I had been comparing a Vigor 2760 (Lantiq VRX288) in VDSL mode with an HG612 as modem. Synch comparisons pre-G.INP were:
Vigor 2760 48680
HG612 53049
Following the application of G.INP the comparative synchs are:
Vigor 2760 52812
HG612 50320
So, following on from other reported figures regarding HH5a comparisons with HG612, a picture seems to be emerging where with G.INP applied, Lantiq chipsets have the edge over Broadcom on ECI cabs.
In my case there was no interleaving applied either before or after G.INP.
-
I wonder if there's a way of monitoring the stats like DSLStats and MyDslWebStats.
-
I wonder if there's a way of monitoring the stats like DSLStats and MyDslWebStats.
Not that I'm aware. All that is available from the Draytek is shown below. ReTx shown as on at the far end means downstream!
-
Ah, right. That works OK. So you can only zoom in so much (down to a 6 hr window) when the original view is set to "24 hours". If it is set to "2 days", the smallest window becomes 12 hr, and if set to "10 days", the smallest window becomes 60 hours.
I had a look at the API as I haven't changed much for 18 months and there are some new settings... After a bit of fiddling, you can now zoom from 24 hours down to a just over an hour - and don't forget you can zoom several times consecutively until max is reached (== timespan x zoomfactor of 0.05 so 1.2 hours for 24 hours now) and right-click to reset.
I've set this up for SNRM and FEC at the moment and will add others later. The current default zoom is x 0.25 hence the 6 hours from 24 hours.
If you zoom a last hour range - it shows 3 minutes at max zoom i.e. 3 plots ???
Example attached for ayeaye
Edit: I've subsequently changed it to .041 so it's exactly an hour's span for max zoom over 24 hours with a resolution of 10 minutes per division, Example attached for skyECI.
-
Have to say after waiting so long for Ginp why is it slowing sync speeds?
I do not have interleaving but was hoping for some improvement as reported by other users when it was rollout out last year for huawai.
If I have to use my eci modem just to keep approx the same sync speed I will lose mdws unless support is added for eci modems.
-
would there be any possibility of a re-sync upwards as my upstream has come down from 20mb to 17mb or is this the way dlm will leave it
All those errors that caused the bursts of CRCs and ES's (upstream) that triggered the DLM intervention have now become FEC's, leaving a zero ES rate. That means DLM has deployed a solution that successfully defeats the noise, but it doesn't mean the noise itself has gone.
I would imagine that DLM could choose to de-intervene if it only looks at the ES rate. However, my gut feeling is that it probably also checks the FEC rate, to see if that isn't too high; this would make sense to me, but has no official confirmation whatsoever.
Unfortunately, the MDWS graphs for FECs auto-scale themselves, and the sporadic, but large, spikes of downstream FECs make the behaviour of the upstream FECs almost invisible, so it is hard to tell.
My upstream does have delay,interleave and g.inp.... ???
Your upstream now has had an old-style DLM intervention, setting an INP of 2.5 and a delay of 8ms; the modems have turned on FEC and interleaving. However, it doesn't look to have G.INP running upstream; I wouldn't expect it, either.
Thanks for your comments. I have just had BT OR engineer here to have a look. Showed him the data and as our estate DP is outside our house he has connected me on to a new pair. He also confirmed my line length of 320m. He said that at the cabinet there are no lines next to mine with broadband at the moment.
My line has been reset and g.inp is now showing as off. I have never seen my upstream snrm so high (now 9.5).US back to pre g.inp rate. Seen a slight increase in DS . Now at 57/20
Will be interesting to see what happens in the next few days. Thanks to the engineer for helping as he came before some months ago when I started this...
-
Looks like G.INP is rolling out to ECI cabinets in full force now as my cabinet was enabled yesterday. I'm not logging stats but my HG612 is showing this now:
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16897 Kbps, Downstream rate = 68028 Kbps
Bearer: 0, Upstream rate = 16797 Kbps, Downstream rate = 64845 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.3 6.1
Attn(dB): 18.8 0.0
Pwr(dBm): 13.3 6.9
VDSL2 framing
Bearer 0
MSGc: -6 14
B: 243 238
M: 1 1
T: 0 61
R: 10 16
S: 0.1198 0.4529
L: 16959 4504
D: 1 1
I: 254 255
N: 254 255
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
Headline figures show an improved downstream sync (was ~59Mbps previously) but most of this increase is likely down to the modem switching back to fast path instead of interleaved (was approximately 1200 depth) and upload has increased marginally.
-
Hopefully mine will switch over at some point as well
Sent from my MI PAD 2 using Tapatalk
-
Any chance of an updated sheet?
AyeAye and Jasonkruys have also been enabled today. Ive updated the list to show the values for data that we have so far.
We'd need to see a lot more of the before and after raw framing data to figure that out.
Ive added in the R & N values for those that have provided it. Using the R&N values Ive also shown the % of RS overhead. Unfortunately we only have that data for 3 people.
-----
PS
If any of the guys who dont use MDWS want to give me their data in the same format so I can add to the list - please do.
-
Hopefully mine will switch over at some point as well
Neither of mine have switched over yet either :(
-
Any chance of an updated sheet?
AyeAye and Jasonkruys have also been enabled today. Ive updated the list to show the values for data that we have so far.
We'd need to see a lot more of the before and after raw framing data to figure that out.
Ive added in the R & N values for those that have provided it. Using the R&N values Ive also shown the % of RS overhead. Unfortunately we only have that data for 3 people.
-----
PS
If any of the guys who dont use MDWS want to give me their data in the same format so I can add to the list - please do.
Might be worth removing me for now as not g.inp enabled at the mo. Cheers
-
All those errors that caused the bursts of CRCs and ES's (upstream) that triggered the DLM intervention have now become FEC's, leaving a zero ES rate. That means DLM has deployed a solution that successfully defeats the noise, but it doesn't mean the noise itself has gone.
Ive tried to put some data together for SkyECI's line. The only thing I note is that on the 19th he had 1071 Err Secs which should still be ILQ Amber (Sky use Standard profile).
I think Ive pondered before if on g.inp lines it is just the Err/Secs that are monitored. By its nature, the use of g.inp should in theory reduce ErrSecs - however these are upstream which g.inp for the ECI's doesnt do and even if ILQ red had been triggered then the penalty seems rather harsh. I asked last year if any of the parameters which are monitored have changed since g.inp - but the question was glossed over. Since the ASSIA court-case they seem to have become really tight lipped on what they disclose and the only thing you can seem to obtain if you push is the MTBE and MTBR rate :(
From what Ian said last year, the default profiles are harsher (http://www.kitz.co.uk/adsl/ginp-retransmission.htm). Even the open profile now has interleaved applied. We can see this is indeed the case as SkyECI's line is now interleaved despite the reset this morning.
Anyhow attached a breakdown of SkyECI's stats.
-
Might be worth removing me for now as not g.inp enabled at the mo. Cheers
Our above posts crossed. :)
Im leaving yours in - because it shows what happened immediately afterwards.
Yours got worse, and particularly now that you have managed to get a reset then your line is one that is worth watching closer and hence me starting a spreadsheet showing any of your changes.
-
Might be worth removing me for now as not g.inp enabled at the mo. Cheers
Our above posts crossed. :)
Im leaving yours in - because it shows what happened immediately afterwards.
Yours got worse, and particularly now that you have managed to get a reset then your line is one that is worth watching closer and hence me starting a spreadsheet showing any of your changes.
Lol ok. New pair as well. Base sync rates are 57/20 for now. So will see how things progress
-
Hopefully mine will switch over at some point as well
Neither of mine have switched over yet either :(
Nor me. Our representation of members on ECI cabs is comparatively low, so it will be harder to gauge progress than it was with the Huawei's. At one point the ECI cabs almost took over in popularity but since BT have only been installing Huaweis over the past year or so, there are now more Huaweis out in the field.
From MDWS there are 29 active members who are on ECI cabs yet only 9 are so far active.
Bearing in mind it took Openreach just over a month to apply the profile to the Huawei cabs, then took them another few weeks to catch up with the newer Huawei's then there's still another few weeks to go yet.
-
Ive added in the R & N values for those that have provided it. Using the R&N values Ive also shown the % of RS overhead. Unfortunately we only have that data for 3 people.
-----
PS
If any of the guys who dont use MDWS want to give me their data in the same format so I can add to the list - please do.
Attached is my HG612 stats from this morning, before I switched to the Vigor.
Cheers
[Quotes corrected by roseway]
-
Nor me.
The Gods must have heard you - congratulations! You are now a member of the club, I'm not yet though.
-
So if I have read this correctly all cabinets will pretty much get g.inp but it's up to DLM if it's activated on your line?
-
Xmas has come early for kitz ;D
-
The Gods must have heard you - congratulations! You are now a member of the club, I'm not yet though.
Gosh that is late in the day! I cant recall any Huaweis being done at this time. If they are doing them this late in the day, then that could speed things up quite a bit
Jeffers has also been enabled, so attached update.
So if I have read this correctly all cabinets will pretty much get g.inp but it's up to DLM if it's activated on your line?
Its a 2 stage process. First of all the cabs are enabled. Then the DLM is updated.
TBH I suspect the ECIs were done a while ago and its only more recently that they decided to apply the DLM profiles.
Im still on IFTN:0xb204 / v0xb204 so it shows that the 206 update wasnt anything to do with g.inp.
-
Xmas has come early for kitz ;D
It's not really affected my line as Im not interleaved. In theory its those who previously had interleaving who should benefit the most.
Ive just tested my latency and its practically the same - pinging the bbc previously gave me 11ms now Im getting 12ms
More interestingly I realise I must be on the Plusnet's new dedicated WBMC network. 4 ms to the RAS - nice!
I do seem to have lost the direct peering to my server though :/
C:\Users\kitz>tracert www.bbc.co.uk
Tracing route to www.bbc.net.uk [212.58.244.66]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 * * * Request timed out.
4 4 ms 4 ms 4 ms 172.17.8.77
5 12 ms 11 ms 11 ms 172.17.12.2
6 12 ms 11 ms 11 ms be2.pcn-ir01.plus.net [195.166.129.164]
7 11 ms 11 ms 11 ms 195.99.125.136
8 12 ms 11 ms 12 ms peer2-et-1-3-0.telehouse.ukcore.bt.net [195.99.127.23]
9 12 ms 12 ms 12 ms 194.74.65.42
10 * * * Request timed out.
11 * ^C
C:\Users\kitz>tracert kitz.co.uk
Tracing route to kitz.co.uk [185.24.98.37]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 * * * Request timed out.
4 4 ms 4 ms 4 ms 172.17.8.77
5 11 ms 11 ms 11 ms 172.17.12.2
6 11 ms 11 ms 11 ms be2.pcn-ir01.plus.net [195.166.129.164]
7 11 ms 11 ms 11 ms 195.99.125.136
8 11 ms 11 ms 11 ms core1-hu0-1-0-1-1.colindale.ukcore.bt.net [195.99.127.8]
9 11 ms 12 ms 11 ms peer5-hu0-1-0-1.telehouse.ukcore.bt.net [195.99.127.21]
10 11 ms 11 ms 11 ms t2c4-et-3-3-0-0.uk-lon1.eu.bt.net [166.49.211.246]
11 12 ms 11 ms 12 ms 82.112.101.73
12 13 ms 14 ms 12 ms ae-15.r02.londen03.uk.bb.gin.ntt.net [129.250.3.30]
13 13 ms 12 ms 14 ms ae-2.r02.londen01.uk.bb.gin.ntt.net [129.250.3.1]
14 14 ms 13 ms 13 ms ae-1.r03.londen01.uk.bb.gin.ntt.net [129.250.3.37]
15 12 ms 12 ms 13 ms 62.73.179.150
16 14 ms 14 ms 13 ms switch-004.sl5.misp.co.uk [185.52.26.251]
17 13 ms 12 ms 12 ms kitz.servers.eqx.misp.co.uk [185.24.98.37]
Trace complete.
This (the PN network) probably explains the short downtime I had about a week or so ago that I mentioned. I was so busy looking for something g.inp related that I never thought to check my Plusnet routing. ::)
-
I think I've joined G.INP club as well!
I'm still at work so can't get the exact stats but graph looks promising:)
https://i.imgur.com/GobXILY.png
-
PS - should mention with my stats, that my SNRm is currently at 7.4 dB. For a while its been 7.2db
7.4 dBis the best its been for a while barring one of my crosstalkers messing about. I'm not quite sure how any of the g.inp settings could have affected my SNRM.
Im not sure if one of my crosstalkers has come back up yet. Most of my crosstalk is and always has been across the adsl frequencies (U0) and having just looked at this - there's a chance that someone hasnt come back online.
-
All those errors that caused the bursts of CRCs and ES's (upstream) that triggered the DLM intervention have now become FEC's, leaving a zero ES rate. That means DLM has deployed a solution that successfully defeats the noise, but it doesn't mean the noise itself has gone.
Ive tried to put some data together for SkyECI's line. The only thing I note is that on the 19th he had 1071 Err Secs which should still be ILQ Amber (Sky use Standard profile).
I think Ive pondered before if on g.inp lines it is just the Err/Secs that are monitored. By its nature, the use of g.inp should in theory reduce ErrSecs - however these are upstream which g.inp for the ECI's doesnt do and even if ILQ red had been triggered then the penalty seems rather harsh. I asked last year if any of the parameters which are monitored have changed since g.inp - but the question was glossed over. Since the ASSIA court-case they seem to have become really tight lipped on what they disclose and the only thing you can seem to obtain if you push is the MTBE and MTBR rate :(
From what Ian said last year, the default profiles are harsher (http://www.kitz.co.uk/adsl/ginp-retransmission.htm). Even the open profile now has interleaved applied. We can see this is indeed the case as SkyECI's line is now interleaved despite the reset this morning.
Anyhow attached a breakdown of SkyECI's stats.
---
ETA
I'm assuming that unless anything drastic happens with skyeci's line, then he will get g.inp again once all the other updates have been done. In a similar way to how the Huawei catchups for DLM resets didnt start to occur until about a month or so afterwards.
-
Kitz has a G symbol on MDWS :) and those DS errored seconds are going to disappear off the graph after 24 hours.
-
I'm assuming that unless anything drastic happens with skyeci's line, then he will get g.inp again once all the other updates have been done. In a similar way to how the Huawei catchups for DLM resets didnt start to occur until about a month or so afterwards.
And then the G.INP Mk1 rollout was halted in may and we had to wait another 3 months (August) for the Mk2 to arrive minus G.INP on the upstream :( , Its something I won't forget in a hurry and all I did was change ISP provider.
-
stats as promised:
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.6.3
MEI Version: 1.4.8.5
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 8h 52m 32s
Resyncs: 2
DSLAM/MSAN VID: IFTN
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: OFF
G.INP: D: Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 62.042 Mb/s / 18.346 Mb/s
Actual Data Rate: 62.354 Mb/s / 18.163 Mb/s
Impulse Noise Prot: 44.0 sym / 0.0 sym
Interleave Delay: 0.22 ms / 0.0 ms
NFEC: 32 / 255
RFEC: 16 / 16
LSYMB: 16 / 4870
Interleave Depth: 1 / 1
Interleave Block: 32 / 255
LPATH: 0 / 0
Line Attenuation: 17.8dB / 22.1dB
Signal Attenuation: 17.7dB / 22.0dB
Noise Margin: 5.9dB / 6.1dB
Transmit power: 13.4dBm / 6.6dBm
FECS: 0 / 338
ES: 62 / 15324
SES: 0 / 1
LOSS: 5 / 326
UAS: 65 / 65
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 1
15m FEC Errors: 0 / 3
1d Code Violations: 22 / 80
1d FEC Errors: 7533958 / 949
-
Attached is my HG612 stats from this morning, before I switched to the Vigor.
Thanks added those in, although I dont have any pre-stats to compare with.. but your R&N values have been added. Like skyeci's was, your overhead for redundancy is 5%.
-
stats as promised:
Chipset: Lantiq™ XWAY™ VRX268
Ohh... is that an ECI modem there?
Do you have any stats from before the g.inp update for comparison please?
-
Attached is my HG612 stats from this morning, before I switched to the Vigor.
Thanks added those in, although I dont have any pre-stats to compare with.. but your R&N values have been added. Like skyeci's was, your overhead for redundancy is 5%.
Thanks Kitz; interestingly 5% is almost spot on the difference between the HG612 synch and the now much improved Lantiq based Vigor synch. Prior to G.INP the HG612 easily beat any Lantiq based device (ECI, HH5A, Vigor2760) tried on my line. Now the situation has reversed!
-
stats as promised:
Chipset: Lantiq™ XWAY™ VRX268
Ohh... is that an ECI modem there?
Do you have any stats from before the g.inp update for comparison please?
It is.
It's ECI /r 1.2 running Openwrt (my own build, openwrt trunk from late January) based on jsamuel's work (http://forum.kitz.co.uk/index.php/topic,15918.0.html)
my last sync before GINP kicked in this morning was 53940/18392 with interleaving around 800ish. You can see it on the graph on my previous post.
-
I have one Jsamuel converted for me but have not actually used it. Tempted but really dont want to swap modems at the moment. Its a shame it cant upload the stats to mydsl as I would use it if it could.
-
Attached is my HG612 stats from this morning, before I switched to the Vigor.
Thanks added those in, although I dont have any pre-stats to compare with.. but your R&N values have been added. Like skyeci's was, your overhead for redundancy is 5%.
Thanks Kitz; interestingly 5% is almost spot on the difference between the HG612 synch and the now much improved Lantiq based Vigor synch. Prior to G.INP the HG612 easily beat any Lantiq based device (ECI, HH5A, Vigor2760) tried on my line. Now the situation has reversed!
Do I recall that BT OR assumed that all HG612 modems were attached to Huawei cabinets?
Is it possible an assumption has been made that all ECI modems are attached to ECI cabinets?
-
Tony - change appreciated, thanks.
Kitz - thanks for keeping track.
Tomorrow I should be back on a computer where I can read MDWS properly, and compare some of the new lines. Tablets are fine for some things, but not proper work...
-
I've joined the club now too! Stats should be on MDWS switched over lunchtime ish Tues.
Sent with Tapatalk (the crap Windows Phone Version!)
-
But I can comment on the text of rp00's line statistics...
- INP=44 is a new value, lower than I've seen before, I think.
- The R and N values (labeled RFEC and NFEC here?) seem to be 16 and 32. At 50% overhead, this seems huge ... but they match the settings on my Billion 8800NL for bearer 1. Is this a translation issue with OpenWrt?
- Likewise the interleaving depth and block size are 1x32, which are the right scale to be bearer 1 too. On my Billion, I get 3x32 on bearer 1, so perhaps ECI cabs don't do interleaving on bearer 1 either.
For comparison, bearer 0 on my Billion, on a Huawei, has
R=8, N=139
Interleaving D=16, I=139.
- The interleaving delay is reported to be 0.22ms, which matches my calculations for my Broadcom modem on a Huawei cab. I wonder how the interleaving delay can be anything when depth is 1?
-
But I can comment on the text of rp00's line statistics...
- INP=44 is a new value, lower than I've seen before, I think.
FWIW, INP was 41 for both DS & US on my connection for a while (back in April/May 2015)
-
But I can comment on the text of rp00's line statistics...
- INP=44 is a new value, lower than I've seen before, I think.
- The R and N values (labeled RFEC and NFEC here?) seem to be 16 and 32. At 50% overhead, this seems huge ... but they match the settings on my Billion 8800NL for bearer 1. Is this a translation issue with OpenWrt?
- Likewise the interleaving depth and block size are 1x32, which are the right scale to be bearer 1 too. On my Billion, I get 3x32 on bearer 1, so perhaps ECI cabs don't do interleaving on bearer 1 either.
For comparison, bearer 0 on my Billion, on a Huawei, has
R=8, N=139
Interleaving D=16, I=139.
- The interleaving delay is reported to be 0.22ms, which matches my calculations for my Broadcom modem on a Huawei cab. I wonder how the interleaving delay can be anything when depth is 1?
These values reported by my VRX288 based Vigor are:-
INP 230
RFEC 16
NFEC 32
INTLVDep 1
INTLVBlock 32
INTLVDelay 0.26
-
I've decided to try the latest vdsl firmware blob I could find (apparently with vectoring support): gained another 2Mb :)
https://i.imgur.com/Gv5A2NN.png
new stats:
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.5.5.1.7
API Version: 4.16.6.3
MEI Version: 1.4.8.5
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 7h 24m 6s
Resyncs: 1
DSLAM/MSAN VID: ECI
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: OFF
G.INP: D: Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 64.762 Mb/s / 18.292 Mb/s
Actual Data Rate: 64.170 Mb/s / 18.171 Mb/s
Impulse Noise Prot: 43.0 sym / 0.0 sym
Interleave Delay: 0.22 ms / 0.0 ms
NFEC: 32 / 255
RFEC: 16 / 16
LSYMB: 16 / 4872
Interleave Depth: 1 / 1
Interleave Block: 32 / 255
LPATH: 0 / 0
Line Attenuation: 17.8dB / 22.1dB
Signal Attenuation: 17.8dB / 22.0dB
Noise Margin: 6.1dB / 6.1dB
Transmit power: 13.4dBm / 6.6dBm
FECS: 0 / 44142327
ES: 4 / 15383
SES: 0 / 1
LOSS: 0 / 351
UAS: 29 / 29
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 2
15m FEC Errors: 0 / 11
1d Code Violations: 20 / 38
1d FEC Errors: 0 / 29857
I'm very impressed how well it works now.
One thing I've noticed, bitswap is not enabled on upload since G.INP, I'm pretty sure it was ON before that. Does it matter?
-
But I can comment on the text of rp00's line statistics...
I was looking at these last night and started scratching my head as I noticed some of the bearer 0 and bearer 1 figures were possibly mixed up and I too got an RS OH of 50% which I thought could not be right. I'd got a headache so went to bed and left it. Glad that you find them strange too.
- INP=44 is a new value, lower than I've seen before, I think.
We dont have anyone else on 44 on the ECIs. However, for some reason that figure rings a bell.
Was that the default figure that they put on the Hueweis if the modem couldnt fully support G.INP and which gave a ridiculous overhead and why people lost so much sync speed? I'm pretty certain Ive seen 44 before when g.inp mk1 went tits up.
ETA - I just noticed that some others have since commented on this value.
The R and N values (labeled RFEC and NFEC here?) seem to be 16 and 32. At 50% overhead, this seems huge ... but they match the settings on my Billion 8800NL for bearer 1. Is this a translation issue with OpenWrt?
Yep. same conclusion that the downstream R & N values are reporting from Bearer 1.
The downstream values match my bearer 1 figures, the upstream match my own bearer 0 figures.
Likewise the interleaving depth and block size are 1x32, which are the right scale to be bearer 1 too. On my Billion, I get 3x32 on bearer 1, so perhaps ECI cabs don't do interleaving on bearer 1 either.
Whilst my bearer 1 block size is 32, I like you have a depth of 3, indicating that the ECI cabs are capable of interleaving on bearer 1. So this is either a reporting issue or ECI modems behaving differently.
I'll zip and attach my plink stats for both pre g.inp and post g.inp so you can see everything.
- The interleaving delay is reported to be 0.22ms, which matches my calculations for my Broadcom modem on a Huawei cab. I wonder how the interleaving delay can be anything when depth is 1?
Its looking more likely that its possibly the firmware pulling some figures from bearer 0 and some from bearer 1. If Bearer0 =1 (which is what it should be) 1 and if Bearer1 is 3 and not the reported 1, then it would all tie up.
I put rp00's stats in the table as best I could. The attainable figures aren't quite accurate but interpreted as best I could from the graph. Note the massive jump on the sync speed, but not so big on the attainable - it looks like that the additional sync speed was always there, just possibly eaten up by RS overhead.
-
I've decided to try the latest vdsl firmware blob I could find (apparently with vectoring support): gained another 2Mb :)
Nice improvement there :) :thumbs:
Id already put your figures into the table and not updating because the latest increase is more to do with firmware rather than any improvements from g.inp itself.
There seems to still be the Bearer0/Bearer1 issue, showing some from 0 and some from 1.
One thing I've noticed, bitswap is not enabled on upload since G.INP, I'm pretty sure it was ON before that. Does it matter?
From my latest stats
Capability:
bitswap On
sra On
trellis On
Bitswap: 483/484 0/0
Indicating bitswap is being undertaken on for up and down over bearer 0 and not on bearer 1
-
PS
rp00 can you do me a favour please and check your IPprofile against your sync speed as it would be interesting to see what the result is for someone on a lantiq chipset.
Im curious about this
Calculated as 96.79% of the sync speed or 96.69% for g.inp lines.
I know theres mention of this being used to check if g.inp is active or not - but Im not convinced when it comes to say the HH5A.
There's something weird going on with sync speeds of some of the Lantiqs which I cant fathom out yet. The speed jumps on say the HH5As are weird - I am also very unsure as some are quoting that its a definite way to find if the HH5A is g.inp capable or not.
According to Openreach and Ian Lawrence.. they should be capable in downstream direction only. Openreach states that if a modem isnt at least capable in the downstream direction its not supposed to sync. This is why they put out new f/w for the eci modems. :shrug2:
I'm curious about atkinsong's observation about 5% difference and perhaps being the lack of RS overhead.
I really dont know - just chucking thoughts around and it would be interesting to see your results on eci but with custom f/w
-
According to Openreach and Ian Lawrence.. they should be capable in downstream direction only. Openreach states that if a modem isnt at least capable in the downstream direction its not supposed to sync. This is why they put out new f/w for the eci modems. :shrug2:
I've never seen any reference to new firmware for the ECI modems
-
PS
rp00 can you do me a favour please and check your IPprofile against your sync speed as it would be interesting to see what the result is for someone on a lantiq chipset.
Im curious about this
Calculated as 96.79% of the sync speed or 96.69% for g.inp lines.
Sure, I'll do it as soon as I get home.
here's what Zen customer panel is reporting:
(for some reason, my initial G.INP resync is not logged)
-
PS
rp00 can you do me a favour please and check your IPprofile against your sync speed as it would be interesting to see what the result is for someone on a lantiq chipset.
Im curious about this
Calculated as 96.79% of the sync speed or 96.69% for g.inp lines.
Thought I'd jump in with my ratio as well Kitz - sync is 52838, BRAS is 51.08. I reckon that's pretty damned close to 96.69%.
I'm also puzzled regarding the big improvement with Lantiq v Broadcomm with G.INP applied. It's as if the Lantiq implementation of G.INP favours chip matching!
-
Might have to give my unlocked eci modem a bash and see what happens. Maybe my cabinet would prefer it ??
-
Might have to give my unlocked eci modem a bash and see what happens. Maybe my cabinet would prefer it ??
I gain 3 mbps on a Lantiq based modem vs HG612.
-
Might have to give my unlocked eci modem a bash and see what happens. Maybe my cabinet would prefer it ??
I gain 3 mbps on a Lantiq based modem vs HG612.
Did your latency improve out of interest? - mine was worse before a change of pair and a reset... g.inp still switched off at the mo. Latency is my issue - happy to lose some speed if I get a better latency..
thanks
-
Might have to give my unlocked eci modem a bash and see what happens. Maybe my cabinet would prefer it ??
I gain 3 mbps on a Lantiq based modem vs HG612.
Did your latency improve out of interest? - mine was worse before a change of pair and a reset... g.inp still switched off at the mo. Latency is my issue - happy to lose some speed if I get a better latency..
thanks
Ive never had interleaving so my latency is the same, it's a shame about the lack of stats though, if I notice problems I figure I'll switch back to the HG612 to see what's happening.
L
-
Might have to give my unlocked eci modem a bash and see what happens. Maybe my cabinet would prefer it ??
I gain 3 mbps on a Lantiq based modem vs HG612.
Did your latency improve out of interest? - mine was worse before a change of pair and a reset... g.inp still switched off at the mo. Latency is my issue - happy to lose some speed if I get a better latency..
thanks
Ive never had interleaving so my latency is the same, it's a shame about the lack of stats though, if I notice problems I figure I'll switch back to the HG612 to see what's happening.
L
well I have managed to get munin setup on my monitoring pc which Jordan got going so I will be able to get some graphs out of it. Crunch time really as to whether to plug it in or not ??? ??? ???
-
PS
rp00 can you do me a favour please and check your IPprofile against your sync speed as it would be interesting to see what the result is for someone on a lantiq chipset.
Im curious about this
Calculated as 96.79% of the sync speed or 96.69% for g.inp lines.
Due to my stupid mistake, I've resynced the line before I could run IP profile test.
New sync speed and IP profile:
Actual Data Rate: 64.068 Mb/s / 18.175 Mb/s
IP Profile for your line is - 62.01 Mbps
which equals to 96.7877
I've double-checked if R and N values are reported correctly by the script and it appears they are.
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 1
nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 0
nReturn=0 nChannel=0 nDirection=0 nNFEC=255 nRFEC=16 nLSYMB=4872 nINTLVDEPTH=1 nINTLVBLOCK=255 nLPATH=0
-
So you get a ratio of 96.79%, does G.INP show as active on your status???
If it does that shows that G.INP works on Lantiq at a 96.79% ratio.
-
Hi not to clued up on vdsl2 Broadband so please excuse my ignorance, I have been following with interest G.INP on ECI Cabinets forum.
I checked the stats this morning and again this evening and noticed that the sync rates had changed but the modem doesn’t appear to have re synced would this be G.INP on my line, if I rebooted the modem would it improve my download speed, I use Vigor 130 modem to a Netgear router on ECI Cabinet, approx 350 mts from cabinet.
Thanks John
Date 23-Mar 23-Mar
Up Time 752:15:28 846:23:57
Firmware FW 3.7.8.3 FW 3.7.8.3
DS Actual Rate 48996000 51823000
DS Attainable Rate 49506624 52187600
US Actual Rate 17529000 17465000
US Attainable Rate 17153036 17505600
DS Path Mode Fast Fast
US Path Mode Fast Fast
DS Interleave Depth 1 1
US Interleave Depth 1 1
Cur SNR Margin 5 dB 5 dB
Far SNR Margin 6 dB 6 dB
NE Current Attenuation 14 15
Far Current Attenuation 13 db 13 db
DS actual PSD 6.9 dB 6.9 dB
US actual PSD 13. 7 dB 13. 7 dB
Xdsl Reset Times 0 0
Xdsl Link Times 1 2
Near End Far End Near End Far End
Trellis 1 1 1 1
Bitswap 1 1 0 1
ReTxEnable 0 0 0 1
VirtualNoise 0 0 0 0
20BitSupport 0 0 0 0
LatencyPath 0 0 0 0
LOS 0 0 2 0
LOF 0 0 0 0
LPR 0 0 0 0
LOM 0 0 0 0
SosSuccess 0 0 0 0
NCD 0 0 0 0
LCD 0 0 0 0
FECS (seconds) 12704118 1172647 0 1176429
ES (seconds) 2240 38293 0 38367
SES (seconds) 0 1644 0 1647
LOSS (seconds) 0 303 0 303
UAS (seconds) 34 110195 34 110235
HECError 0 0 0 0
CRC 2658 58665 0 58804
RsCorrection 0 0 0 0
INP (symbols) 0 0 0 235
InterleaveDelay 0 0 0 27
NFEC 255 255 255 32
RFEC 16 16 16 16
LSYMB 4700 13130 4683 16
INTLVBLOCK 255 255 255 32
AELEM 0 ---- 0 ----
sorry for the poor formatting
-
So you get a ratio of 96.79%, does G.INP show as active on your status???
If it does that shows that G.INP works on Lantiq at a 96.79% ratio.
it does!
root@eci:~# dsl_cpe_pipe.sh lfsg 0
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=0 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0
root@eci:~# dsl_cpe_pipe.sh lfsg 1
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0
-
There are lots of dsl_cpe_pipe.sh commands to experiment with.
For G.INP / ReTx specifically, there are:
rtsg - ReTxStatisticsGet - takes one number, 0=near end, 1=far end
pmrtctg - PM_ReTxCountersTotalGet - takes one number, 0=near end, 1=far end
bitswap stats:
osg - OlrStatisticsGet - takes one number, 0=upstream, 1=downstream
There's fpsg which is like g997fpsg but gives some of the other framing numbers. For some of the commands that require two numbers, perhaps varying the first number, which specifies the "channel", might give the figures for different things? I don't think anything besides 0 works, but it might be worth trying 1 or 2 anyway.
-
Hi not to clued up on vdsl2 Broadband so please excuse my ignorance, I have been following with interest G.INP on ECI Cabinets forum.
I checked the stats this morning and again this evening and noticed that the sync rates had changed but the modem doesn’t appear to have re synced would this be G.INP on my line, if I rebooted the modem would it improve my download speed, I use Vigor 130 modem to a Netgear router on ECI Cabinet, approx 350 mts from cabinet.
Thanks John
Hi wj66. ReTxEnable being set to 1 at the "far end" confirms that G.INP has been switched on on your line. It has resulted in an increase in sync of around 3Mb which is in line with other reports involving Lantiq based modems/routers. I doubt that a reboot would give you any further increase.
-
Thanks atkinsong
-
which equals to 96.7877
Thank you! Its brilliant that we have someone with a hacked ECI who is able to get this additional information.
1) So the ECI modems and therefore most likely the HH5A do NOT follow the 96.69% guideline that weve been using for the Huawei based modems.
The odd thing is that the formula appears to work fine on atkinsongs line - but iirc his modem fully supports g.inp (up & down) and wasnt one of the listed modems that had problems last year.
I'd done a BTw performance test last week, knowing that there was a possibility that I could get g.inp sometime soon and I definitely had 96.79%.
Since I got g.inp it is now at 96.688%, so it is not cabinet related.
I've double-checked if R and N values are reported correctly by the script and it appears they are.
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 1
nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 0
nReturn=0 nChannel=0 nDirection=0 nNFEC=255 nRFEC=16 nLSYMB=4872 nINTLVDEPTH=1 nINTLVBLOCK=255 nLPATH=0
Thank you so much... so the modem is reporting properly but the R & N values don't quite make sense.
The modem is obviously using retransmission BUT unlike with the other modems it is not set to perform interleaving on the Bearer 1 channel.
My line like wombats is good and therefore should have one of the lowest low profiles (46/3), but I definitely have interleaved 3 for retransmission - as does wombat on the Huawei cab.
I know for certain that I have seen INP 44 before and I think it was on the TP-Link TD-W9980 when they were testing with TP-link to get g.inp working. I cant recall for sure though, but I seem to remember wondering if INP 44 is some default setting if the modem isnt fully g.inp compatible.
I'm at a loss to explain the R & N values, but what ever it would appear that there are different framing params for the VRX268 chipset. These framing params (and to a tiny extent the lack of interleaving on Bearer 1) are obviously affecting the overheads.. and this is giving better sync speeds.
Noted that atkinsongs VRX288 modem also has the different framing params, but Im not sure whether those are bearer 0 or bearer 1 either.
Im going to wait for wombat to see and comment on this, because right now I'm stumped as to why this should happen.
I have one possible thought - but then think again and go nah, because its just speculation.
---
ETA - just noticed wj66's stats are are also R & N = 32/16
So it would appear the framing params are making the difference and why the Lantiqs are now getting the better speed.
-
Would the ratio be 96.79% with a ECI modem that had G.INP enabled on a Huawei cabinet?
-
Would the ratio be 96.79% with a ECI modem that had G.INP enabled on a Huawei cabinet?
Its something we haven't been able to prove before - because we hadnt had anyone on a Huawei cab using a hacked ECI modem and able to get the figures we needed to see.
However - yes I suspect they will. Ive seen people with HH5A's reporting the 96.79% method and I've always suspected that the calculation didnt work for the VRX268 chipsets (ie those that supposedly can only do downstream g.inp). As I said in this post (http://forum.kitz.co.uk/index.php/topic,17195.msg316969.html#msg316969) it went against what Openreach was telling me... and its why Ive been asking certain people to check for me.
Now that rp00 has shown that it doesnt work on his VRX268 chipset - we have proof at long last, that on the VRX268's the formula doesnt work.
I think it does work with the TD-W9980, but only since TP-LINK changed the firmware to make it fully support g.inp... so therefore based on the fact that it does work with other VRX modems that are fully g.inp (not just downstream).. it leaves the ECI modems and the HH5A's that the formula doesnt work for.
-
So it looks like matching up a ECI modem and ECI cabinet just got more appealing, apart from the lack of an easy way to get any stats :'(
For me at the moment it's
HG612: 61-62mbpd sync, 10ms ping, 58mbps on speedtest.
ECI/HH5a: 65mbps sync, 10ms ping, 61mbps on speedtest.
So I'm sticking with the HH5a at the moment.
-
So it looks like matching up a ECI modem and ECI cabinet just got more appealing, apart from the lack of an easy way to get any stats
Yep.
I gave my TD-W9980 to my daughter as she wanted an all in one unit, so I dont have it atm to test with.
-
The weird thing is that yours didnt even work with the 96.79% figure. The 96.79% should work for everyone on NGA (except those who are g.inped).
Did you try a resync leaving it disconnected for at least a min so that the bRAS RAP porfiler has chance to pick up your new sync speed.
Not just a minute both HG612 and Router was turned off for 19 hours I like to call it the MSAN relaxation time but it's still showing 91% this was first noticed when the G.INP Interleaving depth got stuck at 4 is was very happy at 8.
this seems to have occured when a DLM intervention by myself on the upstream (G.INP on upstream) started after switching from Mk3 SSFP to Mk1 SSFP the modem would not sync with Mk1 installed and noticed damaged on the A&B extension terminals of SSFP then switched back to Mk3 all working again but DLM damage has been done :(
-
. . . I use Vigor 130 modem to a Netgear router on ECI Cabinet, approx 350 mts from cabinet.
Welcome to the Kitz forum, wj66. :)
You may be able to help enhance the communal knowledge base . . .
Please go to the BT Wholesale Broadband Performance Test (http://speedtest.btwholesale.com/) page, ignore all the instructions in red (just confirm that you have complied) and run the first test. Then once it has finished, select Further Diagnostics and perform the next test. Once that has finished, please post the values of the "Download speed achieved during the test" and the "IP Profile for your line", as shown in the first rectangular box.
It will be interesting to see the ratio of the former to the latter for your Vigor 130 modem & ECI cabinet combination.
-
@rp00, @kitz, @ejs
I have a question about the quoted dsl_pipe.sh commands that show R/N as being 16/32 down and 16/255 up...
Because retransmission has been activated, shouldn't we have two bearer channels to report downstream now, each with their own properties?
Is the 2nd parameter (zero in both commands) for the channel?
What results do you get if that zero is changed?
I'd certainly like to see the results that @ejs was asking for.
-
@rp00, @kitz, @ejs
Is the 2nd parameter (zero in both commands) for the channel?
What results do you get if that zero is changed?
I've already tried that:)
Anything other than 0 returns "nReturn=-22"
root@eci:~# dsl_cpe_pipe.sh fpsg 0 0
nReturn=0 nChannel=0 nDirection=0 nTp=33 nMp=1 nSEQ=20 nBP=238 nMSGC=14 nMSGLP=0
root@eci:~# dsl_cpe_pipe.sh fpsg 0 1
nReturn=0 nChannel=0 nDirection=1 nTp=2 nMp=2 nSEQ=64 nBP=0 nMSGC=58 nMSGLP=0
root@eci:~# dsl_cpe_pipe.sh fpsg 1 0
nReturn=-22
root@eci:~# dsl_cpe_pipe.sh fpsg 1 1
nReturn=-22
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 0
nReturn=0 nChannel=0 nDirection=0 nNFEC=255 nRFEC=16 nLSYMB=4873 nINTLVDEPTH=1 nINTLVBLOCK=255 nLPATH=0
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 1
nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
root@eci:~# dsl_cpe_pipe.sh g997fpsg 1 0
nReturn=-22
root@eci:~# dsl_cpe_pipe.sh g997fpsg 1 1
nReturn=-22
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0
nReturn=-1 (wrong number of parameters/help not available)
root@eci:~# dsl_cpe_pipe.sh g997fpsg 0 0 0
nReturn=-1 (wrong number of parameters/help not available)
root@eci:~# dsl_cpe_pipe.sh fpsg 0
nReturn=-1 (wrong number of parameters/help not available)
root@eci:~# dsl_cpe_pipe.sh fpsg 0 0 0
nReturn=-1 (wrong number of parameters/help not available)
root@eci:~#
@rp00, @kitz, @ejs
I'd certainly like to see the results that @ejs was asking for.
The only command that worked was osg:
root@eci:~# dsl_cpe_pipe.sh osg 0
nReturn=0 nDirection=0 nBitswapRequested=0 nExtBitswapRequested=0 nBitswapExecuted=0 nBitswapRejected=0 nBitswapTimeout=0 nSraRequested=0 nSraExecuted=0 nSraRejected=0 nSraTimeout=0 nSosRequested=0 nSosExecuted=0 nSosRejected=0 nSosTimeout=0
root@eci:~# dsl_cpe_pipe.sh osg 1
nReturn=0 nDirection=0 nBitswapRequested=8726 nExtBitswapRequested=0 nBitswapExecuted=6564 nBitswapRejected=2162 nBitswapTimeout=0 nSraRequested=0 nSraExecuted=0 nSraRejected=0 nSraTimeout=0 nSosRequested=0 nSosExecuted=0 nSosRejected=0 nSosTimeout=0
root@eci:~#
Unfortunately rtsg and pmrtctg return "command not found"
I've attached output of "dsl_cmd_pipe.sh help" with list of available commands if it's any help.
EDIT: " g997fpsg 2 1" etc.. returns the same error
-
Is your version of dsl_cpe_control up-to-date? You might need to build it by passing --enable-model=full to the configure script, or enable everything individually (--enable-dsl-pm-retx-counters and lots of other switches).
-
So it looks like matching up a ECI modem and ECI cabinet just got more appealing, apart from the lack of an easy way to get any stats
Yep.
I gave my TD-W9980 to my daughter as she wanted an all in one unit, so I dont have it atm to test with.
For we Plusnet users on ECI cabs the Hub 1 looks slightly more appealing!
-
The Gods must have heard you - congratulations! You are now a member of the club, I'm not yet though.
Gosh that is late in the day! I cant recall any Huaweis being done at this time. If they are doing them this late in the day, then that could speed things up quite a bit
Jeffers has also been enabled, so attached update.
So if I have read this correctly all cabinets will pretty much get g.inp but it's up to DLM if it's activated on your line?
Its a 2 stage process. First of all the cabs are enabled. Then the DLM is updated.
TBH I suspect the ECIs were done a while ago and its only more recently that they decided to apply the DLM profiles.
Im still on IFTN:0xb204 / v0xb204 so it shows that the 206 update wasnt anything to do with g.inp.
Hi Kitz
Would it be possible to add a column for modem or modem/router type. Be handy to know whats being used.
Many thanks
-
. . . I use Vigor 130 modem to a Netgear router on ECI Cabinet, approx 350 mts from cabinet.
Welcome to the Kitz forum, wj66. :)
You may be able to help enhance the communal knowledge base . . .
Please go to the BT Wholesale Broadband Performance Test (http://speedtest.btwholesale.com/) page, ignore all the instructions in red (just confirm that you have complied) and run the first test. Then once it has finished, select Further Diagnostics and perform the next test. Once that has finished, please post the values of the "Download speed achieved during the test" and the "IP Profile for your line", as shown in the first rectangular box.
It will be interesting to see the ratio of the former to the latter for your Vigor 130 modem & ECI cabinet combination.
Speed achieved 50.01 Mbps
IP Profile 50.1 Mbps
-
Is your version of dsl_cpe_control up-to-date? You might need to build it by passing --enable-model=full to the configure script, or enable everything individually (--enable-dsl-pm-retx-counters and lots of other switches).
Thanks for the info.
I've checked operwrt sources and you're right.
#CONFIGURE_ARGS += --enable-model=full
#CONFIGURE_ARGS += --enable-model=lite
#CONFIGURE_ARGS += --enable-model=footprint
CONFIGURE_ARGS += \
--enable-model=typical \
--enable-dsl-pm-showtime \
--disable-dsl-ceoc
#CONFIGURE_ARGS += --enable-model=debug
I'll try to rebuild it over the weekend.
-
Speed achieved 50.01 Mbps
IP Profile 50.1 Mbps
Thank you. Assuming your sync was still 51823 then:-
50100 /51823 * 100 = 96.68% = G.INP*
---
*near as damn it.
Possible rounding on framing params and sync speed (ie how some modems on the same line and under exactly same conditions will sync at 80,000, 79,999, 79987 etc)
-
Speed achieved 50.01 Mbps
IP Profile 50.1 Mbps
Thank you. Assuming your sync was still 51823 then:-
50100 /51823 * 100 = 96.68% = G.INP*
---
*near as damn it.
Possible rounding on framing params and sync speed (ie how some modems on the same line and under exactly same conditions will sync at 80,000, 79,999, 79987 etc)
That would support Draytek's change log that they added RX and TX G.INP back to the 130 in June (http://www.draytek.co.uk/download/support/readme_v130.txt)
-
I'll try to rebuild it over the weekend.
Perhaps also add --with-channels-per-line=2 - the default value is 1, which may explain the issue with the framing parameter reporting.
-
My cabinet was G.iNP-enabled on Tuesday (WMMAL). My downstream speed has increased from 84000kbits/sec to 88000kbits/sec.
My router log is showing latency fast, downstream G.INP ON, INP 42 downstream/0 Upstream and Bitswap ON downstream. The downstream error counter is a line of 0s (ES,SES, CRC).
The cabinet is an ECI and my line is connected via a Fritz!Box 7490 modem/router. Firmware Fritz!OS 113.06.36-316667 Beta.
-
Speed achieved 50.01 Mbps
IP Profile 50.1 Mbps
Appreciated.Thank you.
I see that Kitz has already performed the calculation and arrived at 96.68%.
-
Would it be possible to add a column for modem or modem/router type. Be handy to know whats being used.
I'd been separating the data based on whether the info came from MDWS. The ones at the bottom were from others who kindly supplied data to us. Ive just gone through each account and added modem data if it was available. I think it can be safely assumed that those in the top section are most likely to be using either HG612s, Billions or Zyxels.
I've also trawled through this thread to see if theres anything else I can add. However I have a headache from hell today (so I skip going to class and sit home looking at figures on the PC instead!) therfore I may have missed something.
If anyone has their R/N data or modem type that I can add manually please say.
I'll attach the figures in a mo as I want to do a couple more things first and add a summary of what weve seen so far.
-
SUMMARY TO DATE
This post is to summarise some of the data and recap on the main findings & observations. It should be borne in mind that we have a lower representation of users on ECI cabs, but based on the statistics so far, I think its safe to say the following:
- Somewhere around 33%-40% of ECI lines have been upgraded so far.
It is probable that those who are on an ECI cab and who have had a DLM reset wont be updated again until the profiles are rolled out to the remaining lines first. In the case of the Huawei's BT tended to mop up the reset/new lines in batches every few weeks. Until then reset lines will be on the new default open profile which is INP=3 & Interleave delay=8 on the downstream.
- The majority of users have seen an uplift in sync speed - As expected, previously interleaved lines have benefited the most.
After what looked to be a disappointing start, more users are now seeing speed increases. For those lines which already sync at maximum, increases have been seen in the max attainable rate.
There are only 2 lines which appear to have lost a significant amount of actual sync speed. One of these has since had a new line (D-side) and DLM reset. Until DLM catches up with g.inp for this line, we are unable to draw any conclusions and I will be watching it closely. There are 2 lines currently syncing at max rate which appear to have lost some attainable speed.
- Lantiq based chipsets now appear to be getting better performance on ECI cabinets.
Pre g.inp, Broadcom based chipsets seemed to outperform the lantiqs when it came to connection speed. However, this seems to have changed since g.inp has been enabled on the ECI cabinets. The lack of full line stats on ECI modems and HH5A have in the past meant its difficult to monitor what is going on with these lines. However rp00 is using a hacked ECI modem which has the ability to look at line stats in greater depth. We are continuing to investigate this area, but several members have now proved much better performance on their lines with a Lantiq based modem since g.inp has been applied. From looking at the information available so far, it would appear that the Lantiq based modems have different framing parameters applied. These framing parameters are used to calculate how much over-head the line needs for Error Protection (RS/FEC). Less overhead means more available speed for sync. It has also been noted that whilst BCM based modems have Interleaved delay of 3 set on the bearer1 channel (which is used for g.inp). The ECI/Lantiqs do not. Investigation is still ongoing. But if the Lantiqs are set to have less RS overheads, then this will explain the better sync speeds.
- The 96.69% method of using IPprofile (http://www.kitz.co.uk/adsl/IPprofile.htm#IP_and_bRAS_profiles) to check for g.inp does not work for VRX268 chipsets.
More specifically it would appear that this may be something to do with it being the ECI modem and HH5A not being able to support upstream g.inp. Both of these modems can support g.inp in the downstream direction only. For other lantiq based modem chipsets and those which have had firmware upgrades to support both up and downstream g.inp and the 96.69 v 96.79 calculation still appears to work. We do not know why this is, but it may have something to do with the different FEC overheads in the framing parameters set (see above). This is confirmed as applying to both ECI and Huawei cabinets.
Attached below is latest table for ECI g.inp line data.
- Those in the top block are all monitored by MDWS if you wish to look at any of the stats in greater depth.
- I have colour coded previous interleaved line data so that it is easier to spot which lines we would expect to achieve the best speed increases after g.inp has been applied.
Note that because of the way modems work out overheads for Interleaved lines - it is perfectly normal to for those lines to lose some attainable.
- Gains and losses have been cell coloured to easily spot positive or negative changes. Yellow indicates no change, or a change of between -100kbps to 100 kbps which is perfectly acceptable.
- Figures in red text are those with losses higher than anticipated.
Thank you to forum members and MDWS (http://www.mydslwebstats.co.uk) users for sharing their data with us.
-
Great summary, Kitz ...... easy to digest. ^^^ :graduate:
-
I've never seen any reference to new firmware for the ECI modems
It was rolled out automatically late 2014 prior to g.inp on the Huaweis. Any modems which missed this update will fail to get a valid PPP session once the line has g.inp applied.
See ECI modem - Issue 1 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).
-
2015?
My firmware on the HH5a is Software version 4.7.5.1.83.8.204.1.11 (Type A) Last updated 23/07/15
-
I take it when a ECI cabinet user sees massive upstream errored seconds the DLM will change the depth from 0 to a higher interleaving depth and a increase in delay on the upstream.
-
i was g.inped this morning. ive an hg612 line capped to 14500, my upload was 489kps before
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 362 Kbps, Downstream rate = 17272 Kbps
Bearer: 0, Upstream rate = 383 Kbps, Downstream rate = 14496 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): 7.9 5.0
Attn(dB): 32.0 0.0
Pwr(dBm): 8.2 5.9
VDSL2 framing
Bearer 0
MSGc: -6 34
B: 130 11
M: 1 1
T: 0 7
R: 8 0
S: 0.2859 0.9505
L: 3890 101
D: 1 1
I: 139 12
N: 139 12
Q: 8 0
V: 6 0
RxQueue: 22 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 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 398099
OHFErr: 3 6
RS: 793817424 3435717
RSCorr: 3186 0
RSUnCorr: 0 0
Bearer 1
OHF: 3545712 0
OHFErr: 0 0
RS: 21273899 0
RSCorr: 7 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 1440 0
rtx_c: 1382 0
rtx_uc: 8 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 14492 0
errFreeBits: 12586336 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1587625757 0
Data Cells: 14746694 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: 59610 14525
SES: 748 3
UAS: 1787 1589
AS: 56954
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 16.69
OR: 0.01 19.16
AgR: 14607.40 402.42
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: 37598/37604 0/0
Total time = 1 days 11 hours 49 min 1 sec
FEC: 5299224 0
CRC: 2211 12351
ES: 59610 14525
SES: 748 3
UAS: 1787 1589
LOS: 2 3
LOF: 16 3
LOM: 0 0
Latest 15 minutes time = 4 min 1 sec
FEC: 16 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: 18 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 11 hours 49 min 1 sec
FEC: 2431 0
CRC: 3 5
ES: 1 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 247313 0
CRC: 1369 453
ES: 24 446
SES: 10 0
UAS: 30 20
LOS: 1 0
LOF: 9 0
LOM: 0 0
Since Link time = 15 hours 49 min 13 sec
FEC: 3186 0
CRC: 3 6
ES: 1 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
If you capped the line for stability it may be worth uncapping it as G.INP should decrease errors on the downstream.
Also do you have any stats from before G.INP to compare; attainables etc.
-
I'll try to rebuild it over the weekend.
Perhaps also add --with-channels-per-line=2 - the default value is 1, which may explain the issue with the framing parameter reporting.
I've managed to find some time tonight and recompiled Openwrt.
with "-with-channels-per-line=2" build fails with error: #error "DSL_CHANNELS_PER_LINE > 1 feature not released yet!!!"
I've tried this on the latest trunk as well, same result.
Here are rtsg and pmrtctg stats (--enable-model=full)
root@eci:~# dsl_cpe_pipe.sh rtsg 0
nReturn=0 nDirection=0 nRxCorruptedTotal=98444 nRxUncorrectedProtected=1388 nRxRetransmitted=0 nRxCorrected=97056 nTxRetransmitted=0
root@eci:~# dsl_cpe_pipe.sh rtsg 1
nReturn=-38
root@eci:~# dsl_cpe_pipe.sh pmrtctg 0
nReturn=0 nDirection=0 nElapsedTime=1106 bValid=1 nEftrMin=8785000 nErrorFreeBits=1019060 nLeftr=61604
root@eci:~# dsl_cpe_pipe.sh pmrtctg 1
nReturn=0 nDirection=1 nElapsedTime=1107 bValid=1 nEftrMin=4294967295 nErrorFreeBits=0 nLeftr=0
And full status again:
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.6.3
MEI Version: 1.4.8.5
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 14m 48s
Resyncs: 1
DSLAM/MSAN VID: ECI
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: OFF
G.INP: D: Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 63.066 Mb/s / 18.121 Mb/s
Actual Data Rate: 63.645 Mb/s / 18.043 Mb/s
Impulse Noise Prot: 43.0 sym / 0.0 sym
Interleave Delay: 0.22 ms / 0.0 ms
NFEC: 32 / 255
RFEC: 16 / 16
LSYMB: 16 / 4838
Interleave Depth: 1 / 1
Interleave Block: 32 / 255
LPATH: 0 / 0
Line Attenuation: 17.8dB / 22.1dB
Signal Attenuation: 17.7dB / 21.9dB
Noise Margin: 5.8dB / 6.1dB
Transmit power: 13.3dBm / 6.6dBm
FECS: 0 / 44578222
ES: 16 / 15528
SES: 0 / 1
LOSS: 0 / 399
UAS: 34 / 34
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 90 / 0
15m FEC Errors: 0 / 0
1d Code Violations: 90 / 16778
1d FEC Errors: 0 / 44578222
IP Profile for your line is - 61.6 Mbps (96.7868%)
-
I take it when a ECI cabinet user sees massive upstream errored seconds the DLM will change the depth from 0 to a higher interleaving depth and a increase in delay on the upstream.
It will most likely increase INP and delay accordingly. Interleaving depth is a value made up from the current INP, delay, sync rate and possibly a few other parameters. As such I don't feel interleaving depth has a whole lot of meaning unless everyone synced at the same rate :P.
-
Bonus and slightly offtopic post:
Eci (Openwrt) modem on Huawei cab with G.INP enabled
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.2.4
MEI Version: 1.4.8.4
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 28m 52s
Resyncs: 1
DSLAM/MSAN VID: IFTN
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: ON
G.INP: D: Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 60.406 Mb/s / 21.143 Mb/s
Actual Data Rate: 58.233 Mb/s / 19.999 Mb/s
Impulse Noise Prot: 43.0 sym / 0.0 sym
Interleave Delay: 0.13 ms / 0.0 ms
NFEC: 32 / 254
RFEC: 16 / 16
LSYMB: 16 / 5374
Interleave Depth: 1 / 1
Interleave Block: 32 / 127
LPATH: 0 / 0
Line Attenuation: 17.6dB / 22.3dB
Signal Attenuation: 17.8dB / 22.0dB
Noise Margin: 5.8dB / 6.8dB
Transmit power: 13.8dBm / 7.3dBm
FECS: 0 / 243983
ES: 0 / 16949
SES: 0 / 36
LOSS: 0 / 0
UAS: 31 / 31
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 0
15m FEC Errors: 0 / 1
1d Code Violations: 0 / 22602
1d FEC Errors: 0 / 243983
Ignore "DSLAM/MSAN VID: IFTN", this seems to be a bug in the script.
echo "g997listrg 0" >/tmp/pipe/dsl_cpe0_cmd ; cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=0 G994VendorID=IFTNWC SystemVendorID=IFTN VersionNumber=0123456789012345 SerialNumber=01234567890123456789012345678901 SelfTestResult=0 XTSECapabilities=(00,00,00,00,00,00,00,07)
echo "g997listrg 1" >/tmp/pipe/dsl_cpe0_cmd ; cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=1 G994VendorID=BDCM SystemVendorID=BDCM VersionNumber=v10.09.12 SerialNumber= SelfTestResult=0 XTSECapabilities=(00,00,00,00,00,00,00,00)
IP profile for this line is 56.37 (96.80%)
-
Bonus and slightly offtopic post:
Eci (Openwrt) modem on Huawei cab with G.INP enabled
IP profile for this line is 56.37 (96.80%)
You sir, are a gem!
Ive long suspected, it didnt work on the HH5A's and ECI modems, not only have you proved it for the ECI cabs, but now we also have solid proof on the Huaweis cabs too.
Thanks for the additional stats. I will look closer later. I skipped going to class today cause I felt rotten, and all Ive done is sit in front of the PC to the point my eyes are blurred and my knacked hand is causing me much grief. I still have some admin stuff I need to do though, so Im best looking when my head is clearer... but a quick glance shows the same odd params of 16/32 for the R&N values. ???
-
I'm waiting for the revelation that the HH5a and ECI modems were the best thing BT ever gave out :lol:
-
I'm waiting for the revelation that the HH5a and ECI modems where the best thing BT ever gave out :lol:
hahaha... you got me rolling. :lol: :lol:
-
SUMMARY TO DATE
This post is to summarise some of the data and recap on the main findings & observations.
Thanks kitz. Good summary.
I'm not in full contact with the internet for the next few days, so seeing this in text mode, cf MDWS, helps lots.
Thank you to forum members and MDWS (http://www.mydslwebstats.co.uk) users for sharing their data with us.
Agreed. It all requires people willing to share
I've managed to find some time tonight and recompiled Openwrt.
with "-with-channels-per-line=2" build fails with error: #error "DSL_CHANNELS_PER_LINE > 1 feature not released yet!!!"
Shame. It definitely looks to be mixing the output up some. Especially after you added the output from the Huawei cab... and compared to @forceware's output, where we see 16/32 on bearer 1 but 8/129 on bearer 0.
Bonus and slightly offtopic post:
Eci (Openwrt) modem on Huawei cab with G.INP enabled
How did you happen to end up on a Huawei cab with a line that has almost identical properties to your own?
but a quick glance shows the same odd params of 16/32 for the R&N values. ???
Agreed. The first thing I checked...
I'm waiting for the revelation that the HH5a and ECI modems were the best thing BT ever gave out :lol:
Oh :fingers: I would so look forward to that!
-
G.Inp activated overnight.
Unlocked HG612 on a ECI cabinet.
Slight improvement in download about 17m to 18m
Ping down from 24 to 21 (now seems to settled to 16)
I'll sort out some stats when the sun stops shining! Too nice to be on a computer at the minute.
-
ECI cab in Southampton appears to have been upgraded to support G.INP, as shown on my mums ASUS DSL-AC68
ITU G.993.2(VDSL2), G.998.4(G.INP, Downstream only)
-
G.Inp activated around 8.30 this morning.
Unlocked HG612 on a ECI cabinet.
This is as good as it's going to get for me I guess, Do you guys think this is going to improve things with my interferer, check my graph.
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 28725 Kbps, Downstream rate = 85968 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 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.7 12.2
Attn(dB): 17.2 0.0
Pwr(dBm): 12.6 6.8
VDSL2 framing
Bearer 0
MSGc: -6 150
B: 178 236
M: 1 1
T: 0 5
R: 6 16
S: 0.0712 0.3771
L: 20780 5410
D: 1 1
I: 185 255
N: 185 255
Q: 16 0
V: 2 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 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 1368057
OHFErr: 20 0
RS: 468751680 2980419
RSCorr: 1704 0
RSUnCorr: 0 0
Bearer 1
OHF: 521711 0
OHFErr: 0 0
RS: 6259798 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 785 0
rtx_c: 143 0
rtx_uc: 259 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 79982 0
errFreeBits: 10223278 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1289134581 0
Data Cells: 5245399 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: 1912 15
SES: 77 5
UAS: 153 97
AS: 8381
Bearer 0
INP: 46.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.15
OR: 0.01 202.87
AgR: 80111.28 20203.27
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 2814/2814 0/0
Total time = 1 days 57 min 53 sec
FEC: 1704 0
CRC: 20 0
ES: 1912 15
SES: 77 5
UAS: 153 97
LOS: 3 0
LOF: 19 0
LOM: 21 0
Latest 15 minutes time = 12 min 53 sec
FEC: 10 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: 206 0
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 57 min 53 sec
FEC: 604 0
CRC: 7 0
ES: 6 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1100 0
CRC: 13 0
ES: 242 0
SES: 12 0
UAS: 36 25
LOS: 1 0
LOF: 10 0
LOM: 0 0
Since Link time = 2 hours 19 min 39 sec
FEC: 1704 0
CRC: 20 0
ES: 17 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 28774 Kbps, Downstream rate = 84544 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 28774 kbps 84544 kbps
Actual Aggregate Tx Power: 6.8 dBm 12.6 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.9 22.2 32.5 N/A N/A 11.9 27.7 42.9
Signal Attenuation(dB): 0.9 22.0 32.4 N/A N/A 16.0 27.5 42.9
SNR Margin(dB): 11.9 12.5 12.1 N/A N/A 6.3 5.8 6.6
TX Power(dBm): -3.9 -22.1 6.5 N/A N/A 8.5 7.5 7.3
-
How did you happen to end up on a Huawei cab with a line that has almost identical properties to your own?
I've told my mate about the improved syncs after GINP was enabled. He asked me to flash his ECI with Openwrt. I didn't know he is on Huawei cab until I've looked at the stats:)
-
G.INP enabled here at 5am Tuesday morning, look to have gained about 2 Mbps in downstream sync.
Router: VMG8924-B10A
Firmware Version: 1.00(AAKL.13)C0
Cabinet: ECI
Profile: 24.38 Sync: 25.210 == 96.71
New stats:
Max: Upstream rate = 1636 Kbps, Downstream rate = 25819 Kbps
Bearer: 0, Upstream rate = 1511 Kbps, Downstream rate = 25210 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.7 6.4
Attn(dB): 31.2 0.0
Pwr(dBm): 11.6 6.3
VDSL2 framing
Bearer 0
MSGc: -6 33
B: 227 47
M: 1 1
T: 0 5
R: 6 0
S: 0.0000 1.0000
L: 6508 384
D: 1 1
I: 234 48
N: 234 48
Q: 4 0
V: 0 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 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 247813
OHFErr: 102 11
RS: 985089872 1075494
RSCorr: 31246 0
RSUnCorr: 0 0
Bearer 1
OHF: 4427517 0
OHFErr: 0 0
RS: 26564732 0
RSCorr: 94 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 24809 0
rtx_c: 20312 0
rtx_uc: 261 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 25186 0
errFreeBits: 27306571 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3447511267 0
Data Cells: 7464039 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: 17 11
SES: 1 0
UAS: 22 22
AS: 71137
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 16.31
OR: 0.01 19.12
AgR: 25265.81 1530.02
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: 27298/27327 0/0
Total time = 19 hours 45 min 59 sec
FEC: 31246 0
CRC: 102 11
ES: 17 11
SES: 1 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Pre-G.INP stats:
Max: Upstream rate = 1637 Kbps, Downstream rate = 27586 Kbps
Bearer: 0, Upstream rate = 1549 Kbps, Downstream rate = 23260 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): 5.6 6.3
Attn(dB): 31.2 0.0
Pwr(dBm): 11.8 6.8
VDSL2 framing
Bearer 0
MSGc: 22 33
B: 51 48
M: 1 1
T: 64 5
R: 12 16
S: 0.0711 0.9962
L: 7200 522
D: 455 1
I: 64 65
N: 64 65
Counters
Bearer 0
OHF: 2718164 767321
OHFErr: 11 6
RS: 695794556 2625747
RSCorr: 248809 21
RSUnCorr: 688 0
Bearer 0
HEC: 99 0
OCD: 0 0
LCD: 0 0
Total Cells: 555508978 0
Data Cells: 4122613 0
Drop Cells: 0
Bit Errors: 0 0
ES: 6 6
SES: 0 0
UAS: 22 22
AS: 12422
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 4.56 16.25
OR: 49.02 19.19
AgR: 23308.94 1567.90
Bitswap: 6315/6315 19/20
Total time = 3 hours 27 min 24 sec
FEC: 248809 21
CRC: 11 6
ES: 6 6
SES: 0 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
(Work In Progress)
So ... I've been thinking a little about this Sync-Speed: IP-Profile ratio, and trying to figure *why* it could be different.
The difference is 0.1%. When a line is running at 80Mbps, the difference amounts to 80kbps - or perhaps thought of as 1 extra overhead byte per 1000 data bytes. My mind immediately suggests that it could, just as much, be 1 byte in 1024 too - I don't think we measure closely enough to distinguish.
I started by playing around with the different "AgR" figures produced by Broadcom chips, to see if I could find something with that difference, but I can't.
Then, having looked at @maybecrazy's latest statistics, compared to mine, I noticed something else:
- His statistics show, on bearer 0, a non-zero OHFErr count alongside a zero OHF count.
- My statistics show zero for both.
In previous analysis, I had figured that the OH (overhead) had moved into bearer 1, so there was no way to get either a count or an error in bearer 0.
But perhaps this is wrong.
I then went to look into the G.INP specifications, to see what happened to CRC checks: I wondered what happened when you moved the OH (which holds the CRC) out of bearer 0.
It turns out that there are considerable limitations on the framing structure that can apply with G.INP in place, and the formulation of the existing frame structure in re-transmittable DTU's.
But, significantly, one of the options they *do* allow for is whether to include a CRC byte within a DTU.
If we end up with a DTU of around 1,000 bytes, and some implementations use a CRC byte, and some implementations don't use one ... could that explain the difference? This sounds a promising avenue to approach, I thought...
In the G.INP specification, the restriction on DTU size is that the user-data portion made up of an integer number of 65-octet PTM "codewords" (ie a 65-byte block), while the encoded/FEC-protected output (including header and CRC byte) must be an integer number of RS blocks. The specification embodies this in a formula:
- Q * H - 2 -V - W = A * 65, where
- Q = the integer number of RS blocks; can be seen in Broadcom line statistics.
- H = number of "proper" bytes in an RS codeword. Is this the same as "N-R"?
- V = extra bytes stuffed into the datastream, to round it. Can be seen in Broadcom line statistics.
- W = the CRC bytes, if used. Guesswork?
- A = integer number of PTM codewords. Guesswork?
For my line, the formula might work out as follows:
- Q * H - 2 -V - W = A * 65, where
- Q = 16
- H = 131
- V = 14
- W = 0
- A = 32
- Total DTU size = 16 * 131 = 2096
For @maybecrazy's line, the formula might work out as:
- Q * H - 2 -V - W = A * 65, where
- Q = 16
- H = 179
- V = 2
- W = 0
- A = 44
- Total DTU size = 16 * 179 = 2864
Now I know the formula, I can see that "V" is also significant. It represents empty space in a DTU: perhaps more empty space affects that % calculation.
Anyway, I have to leave my investigation for a few days, but I thought someone might find this train of thought interesting, even if incomplete. Unfortunately, I can't see that we'll ever get the right level of detail out of the ECI/H5A boxes to compare....
-
@maybecrazy @npr
Thanks both for those stats (& IPprofile) - Ive added to the table :)
-
@wombat.
Thanks for your thoughts. Im beginning to think we perhaps should start a new thread on this info we are slowly accumulating about the overheads. Theres another few topics scattered which also contains some interesting snippets.
btw - one other thought that struck me last night when looking at some stats is that g.inp has got to set a maximum delay parameter. This is basically the limit of time that the DTU should keep trying to retransmit before it returns an error to what I understood to be dealt with at a higher level (CRC). It was a while ago since I read the specs but I seem to recall something about this and due to limitations not all modems did this (memory size?) and basically worked on a one shot try basis. I shall have to go read the specs again. Ive had a quick scan of G998.4 but cant find the info now. Im sure it was in a doc that ejs & I was discussing about a year ago. TBH I wasn't feeling too great yesterday, but I stupidly continued to sit at the PC until very late trying to catch up on admin stuff.. and today I have full blown migraine & sickness so its definitely not a day for me to be trying to read technical papers and make sense of anything.
PS - noticed nprs R&N values too.
-
I think this perhaps needs bringing to attention.
Theres 2 lines so far which have recorded higher than anticipated losses in sync speed after g.inp.
These are skyECI & simon194
SkyECI has recently had a new line and DLM reset, so I shall be looking at his stats in more detail to see what happens, although I dont expect it to move quite yet.
Out of curiosity I when to check and see how simon194's line is performing - this certainly looks messy :ouch:
-
I found a white paper written by Ikanos about G.INP, I don't think anything can be obtained from the Ikanos website itself without a login any more, but I found a copy here (https://doc.lagout.ovh/electronics/doc/ikanos/DO-435935-WP-1_Improved-Impulse-Noise-Protection_ReTx1.pdf).
It explains a bit about the development of G.INP, there were two different retransmission schemes, with the retransmission queues at different protocol layers within the modem. G.INP unified both standards, so that the equipment at one end can work with different equipment at the other end, even though exactly where they implement the retransmission may be different, the modem at one end doesn't even know at which layer the other end has implemented the retransmission. I think that's the reason the DTU payload contains an integer number of PTM fragments, and the DTU has to consist of an even number of RS codewords.
-
If you capped the line for stability it may be worth uncapping it as G.INP should decrease errors on the downstream.
Also do you have any stats from before G.INP to compare; attainables etc.
Yes I have thought of doing this but my line is mainly used for online gaming and I see that my delay is set to 0. I don't want dlm to change me to a delayed error correction. Maybe I'm not understanding how this works. I'm far more conserned as to where some of my upload has gone as I did have much to start with
-
If I get g.inp'd I dont mind testing on my lantiq fritzbox to see if it syncs higher than my broadcom based 8800nl.
To me it wouldnt be unsurprising lantiq chipsets peform better as usually with advanced dsl features chipset matching is beneficial.
-
If I get g.inp'd I dont mind testing on my lantiq fritzbox to see if it syncs higher than my broadcom based 8800nl.
To me it wouldnt be unsurprising lantiq chipsets peform better as usually with advanced dsl features chipset matching is beneficial.
My 8800nl synced me down twice. Since dlm reset I am now on an open eci modem so waiting to see if the figures go up this time round...
-
I have a locked eci modem I got off eBay a year ago but I don't know if it's had the update, I've not plugged it in since owning it. I would buy lantiq modem if I could find one I could cap my line with
-
I have a locked eci modem I got off eBay a year ago but I don't know if it's had the update, I've not plugged it in since owning it. I would buy lantiq modem if I could find one I could cap my line with
I bought a locked ECI Type 1B modem last year as well.
I was G.INP'd today - running a unlocked HG612.
I have tried the ECI and it works BUT my download speed goes down from 18M to about 15M
Latency is much the same.
-
Steve what is your upload? Uncapped my download would be 17-18mb and I'm 1.6km from the cabinet.
-
Steve what is your upload? Uncapped my download would be 17-18mb and I'm 1.6km from the cabinet.
Upload is 1.2M
-
Just had a re-sync about 7:30 this morning and G.INP is now enabled downstream only on my connection, sync has jumped to 70890kbps from about 65000kbps with snrm around 6.5db both up and down. Stats are under broadstair on MDWS.
Stuart
-
Which modem/router are you using please broadstairs?
-
Which modem/router are you using please broadstairs?
ZyXEL VMG8924-B10A using f/w version 11. I am on an ECI cab as well.
Stuart
-
Ok thanks for the info. How do you get that to work with MDWS then? I thought only BCM chipset could be used?
-
Ok thanks for the info. How do you get that to work with MDWS then? I thought only BCM chipset could be used?
Running DSLStats which supports this and the 8324 version, which then uploads to MDWS.
Stuart
-
OK, my bad. Those both have BCM chipsets. :-X
-
Yesterday evening I was looking at my stats and a lot of the time there were huge numbers of FEC errors for some hours - the unusual thing was that these were on the upstream where I dont have G.INP active. This is unusual for my line as I have never seen these kinds of numbers upstream. I know FECs are not that important but I do think it very unusual to suddenly see this just after G.INP was activated. My actual sync upstream did not change and has always been close to 20000kbps although the snrm did drop from what it was before.
Stuart
-
Hi,
So wanted to update as requested. Following a drop in sync on both directions following g.inp on my billion 8800nl I had bt round who replaced the pair and isolated me in the cabinet away from other enabled lines just to see if it helped.
A couple of days ago I put an unlocked BT eci modem to see if it would help after seeing positive results.
Last night G.INP was re-applied with the unlocked eci attached- a whopping near on 10mb increase on the DS, US is the same. Latency is now 11ms instead of 21ms
The issue now is do I risk putting the billion back on to see if can perform the same and get my stats back or leave it all alone.
I have included stats from the billion post BT engineer and ECI modem post engineer and both with no G.INP applied. I have also included the ECI now with g.inp applied. The missing result is the billion with g.inp on the new pair.
Are results due to the modem or the new pair ?? Probably plugging in the billion again will be the only way to know for sure but do I risk it???
20:43pm - 23/03/16
Billion 8800nl following reset and new pair 24hours afterwards, no g.inp
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 4
Last initialization procedure status: 0
Max: Upstream rate = 28191 Kbps, Downstream rate = 68453 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 57857 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 28191 kbps 68453 kbps
Actual Aggregate Tx Power: 2.4 dBm 2.4 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4
D1 D2 D3
Line Attenuation(dB): 1.1 14.4 24.3 N/A N/A 9.3 20.2 32.2
Signal Attenuation(dB): 1.0 14.4 24.3 N/A N/A 11.9 20.0 32.2
SNR Margin(dB): 11.1 9.6 10.2 N/A N/A 6.3 6.2 6.2
TX Power(dBm): -6.7 -30.8 1.8 N/A N/A 8.2 7.3 7.4
billion
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 4
Last initialization procedure status: 0
Max: Upstream rate = 28087 Kbps, Downstream rate = 68461 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 57857 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.3 9.9
Attn(dB): 14.4 0.0
Pwr(dBm): 2.4 2.4
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 51 236
M: 1 1
T: 64 5
R: 12 16
S: 0.0286 0.3771
L: 17904 5410
D: 1133 1
I: 64 255
N: 64 255
Counters
Bearer 0
OHF: 65963847 616935
OHFErr: 10 104
RS: 4001705061 1577288
RSCorr: 118917 927
RSUnCorr: 912 0
Bearer 0
HEC: 241 0
OCD: 0 0
LCD: 0 0
Total Cells: 600137824 0
Data Cells: 164942123 0
Drop Cells: 0
Bit Errors: 0 0
ES: 63 2073
SES: 56 0
UAS: 3610 3554
AS: 121221
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.83 6.15
OR: 104.49 202.87
AgR: 57961.58 20203.27
Bitswap: 1564/1564 9/9
***ECI unlocked 20:42pm 23/03/16 - no g.inp***
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.2.4
MEI Version: 1.4.8.4
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 34s
Resyncs: 1
DSLAM/MSAN VID: IFTN
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: ON
G.INP: D: Not Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 65.326 Mb/s / 29.202 Mb/s
Actual Data Rate: 56.458 Mb/s / 20.000 Mb/s
Impulse Noise Prot: 3.0 sym / 0.0 sym
Interleave Delay: 8.0 ms / 0.0 ms
NFEC: 85 / 255
RFEC: 16 / 16
LSYMB: 17469 / 5410
Interleave Depth: 823 / 1
Interleave Block: 85 / 255
LPATH: 0 / 0
Line Attenuation: 14.2dB / 14.0dB
Signal Attenuation: 14.2dB / 13.9dB
Noise Margin: 6.0dB / 12.2dB
Transmit power: 5.7dBm / 5.6dBm
FECS: 0 / 135499
ES: 0 / 11969
SES: 0 / 2
LOSS: 0 / 168
UAS: 299 / 299
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 13874
15m FEC Errors: 0 / 135499
1d Code Violations: 0 / 13874
1d FEC Errors: 0 / 135499
24/03/16 - Open ECI modem - connected awiting g.inp to be re-applied
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.2.4
MEI Version: 1.4.8.4
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 1m 32s
Resyncs: 1
DSLAM/MSAN VID: IFTN
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: ON / U: OFF
G.INP: D: Not Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 65.355 Mb/s / 28.682 Mb/s
Actual Data Rate: 56.284 Mb/s / 20.000 Mb/s
Impulse Noise Prot: 3.0 sym / 0.0 sym
Interleave Delay: 8.0 ms / 0.0 ms
NFEC: 85 / 255
RFEC: 16 / 16
LSYMB: 17415 / 5410
Interleave Depth: 819 / 1
Interleave Block: 85 / 255
LPATH: 0 / 0
Line Attenuation: 14.2dB / 14.0dB
Signal Attenuation: 14.2dB / 14.1dB
Noise Margin: 6.1dB / 12.1dB
Transmit power: 5.8dBm / 5.7dBm
FECS: 109 / 136100
ES: 0 / 12023
SES: 0 / 2
LOSS: 0 / 180
UAS: 277 / 277
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 13936
15m FEC Errors: 109 / 136100
1d Code Violations: 0 / 13936
1d FEC Errors: 109 / 136100
26/03/16 11.25am eci following re-sync as console not being responsive
root@OpenWrt:~# /etc/init.d/dsl_control status
Chipset: Lantiq™ XWAY™ VRX268
Firmware Version: 5.7.4.3.0.6
API Version: 4.16.2.4
MEI Version: 1.4.8.4
Power Management Mode: L0 - Synchronized
Line State: UP [0x801: showtime_tc_sync]
Line Uptime: 8s
Resyncs: 1
DSLAM/MSAN VID: IFTN
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Trellis: D: ON / U: ON
Bitswap: D: OFF / U: OFF
G.INP: D: Not Enabled / U: Not Enabled
Virtual Noise Support: D: Not Supported / U: Not Supported
Attain Data Rate: 65.016 Mb/s / 28.729 Mb/s
Actual Data Rate: 56.087 Mb/s / 20.000 Mb/s
Impulse Noise Prot: 3.0 sym / 0.0 sym
Interleave Delay: 8.0 ms / 0.0 ms
NFEC: 85 / 255
RFEC: 16 / 16
LSYMB: 17354 / 5410
Interleave Depth: 817 / 1
Interleave Block: 85 / 255
LPATH: 0 / 0
Line Attenuation: 14.3dB / 14.2dB
Signal Attenuation: 14.3dB / 14.1dB
Noise Margin: 6.1dB / 12.3dB
Transmit power: 6.0dBm / 5.9dBm
FECS: 0 / 136834
ES: 0 / 12077
SES: 0 / 2
LOSS: 0 / 186
UAS: 81 / 81
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 13996
15m FEC Errors: 0 / 136834
1d Code Violations: 0 / 13996
1d FEC Errors: 0 / 136834
27/03/16 ECI - G.INP BACK ON
***09:47 27/03/2016 - ECI open modem after G.INP
***11 - 12 ms ping time*** 9mb approx improvement
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 10h 56m 23s — Resyncs: 3
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 66.130 Mb/s — 28.471 Mb/s
Actual Line Speed: 66.384 Mb/s — 20.000 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: ON
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.21 ms — 0.0 ms
INP: 44.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5410
LPATH: 0 — 0
Line Attenuation: 14.3 dB / 14.1 dB
Noise Margin/SNR: 5.1 dB / 12.2 dB
Transmit Power: 6.0 dBm / 5.8 dBm
Errors Since Line Up
FECS: 0 — 86
ES: 2 — 12090
SES: 0 — 2
LOSS: 3 — 191
UAS: 163 — 163
HEC: 0 — 0
CRC_P: 1 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 2
Errors in 1 Day
Code Violations: 2 — 4
FECS: 0 — 56
-
I don't know the answer to your question, I'm afraid ?? It all depends on whether there was a fault with your original pair I suppose. I have to say, I'm certainly not in the habit of changing pairs for changes sake, so do wonder if your engineer did indeed find some kind of service affecting fault ??
Also, I don't know how he can "isolate" you away from other workers in the actual Cab ?? The only way he could achieve anything near to this would be to move you to a different pair within the D-side cable (from Cab to DP ..... ie: telegraph pole).
He would check the pairs for 'noise' (disturbers) and go for the best dB reading ..... as near to -60dB as possible.
Either way, you have got a great result. Great news. :)
-
I don't know the answer to your question, I'm afraid ?? It all depends on whether there was a fault with your original pair I suppose. I have to say, I'm certainly not in the habit of changing pairs for changes sake, so do wonder if your engineer did indeed find some kind of service affecting fault ??
Also, I don't know how he can "isolate" you away from other workers in the actual Cab ?? The only way he could achieve anything near to this would be to move you to a different pair within the D-side cable (from Cab to DP ..... ie: telegraph pole).
He would check the pairs for 'noise' (disturbers) and go for the best dB reading ..... as near to -60dB as possible.
Either way, you have got a great result. Great news. :)
I think he just moved me in the cab away from other enabled lines. To be fair he had been before and was happy to get involved once I showed him the results..
Do I risk the billion to get the stats to prove if my cab prefers eci modem lol.. ??? ???
-
You can always try it if it makes it worse you can always go back.
-
& if you do try the Billion & then revert to the ECI again, you could run the script that I've been developing with you for use with ECI modems to see what the stats are like with a fresh ECI reboot ;).
If you do try the Billion & then go back to the ECI, it would be useful to also grab the Billion's stats just before disconnecting it again.
-
I guess it might help the community 😊
Lol. Next question when is best. I leave about 30 mins from power off till power on. Is this too long or too little?
Cheers
-
As DLM apparently looks at 15 minute stats windows, a 30 minute 'rest' should suffice as you will only be carrying out 2 resyncs fairly close together as a maximum.
-
Then it might be possible to compare you billion stats to mine as I have lost a little bit of speed since G.inp has been enabled on my cab.
-
skyeci before you was g.inp you was interleaved, so a sync speed increase is no surprise, it will very likely also see an increase on the 8800nl, but by the same amount? you wont know until you try it.
Its very important to check for and specify here if its apple vs apple comparison, apple vs apple been fast path vs g.inp.
-
Then it might be possible to compare you billion stats to mine as I have lost a little bit of speed since G.inp has been enabled on my cab.
I lost 3mb on upload so it was a lot really. Just hoping the new pair bt did may of helped and help the billion. Just pondering doing it tonight.
-
skyeci before you was g.inp you was interleaved, so a sync speed increase is no surprise, it will very likely also see an increase on the 8800nl, but by the same amount? you wont know until you try it.
Its very important to check for and specify here if its apple vs apple comparison, apple vs apple been fast path vs g.inp.
But when the billion first got g.inp I lost sync speed both ways hence getting bt out.
-
I don't know the answer to your question, I'm afraid ?? It all depends on whether there was a fault with your original pair I suppose. I have to say, I'm certainly not in the habit of changing pairs for changes sake, so do wonder if your engineer did indeed find some kind of service affecting fault ??
Also, I don't know how he can "isolate" you away from other workers in the actual Cab ?? The only way he could achieve anything near to this would be to move you to a different pair within the D-side cable (from Cab to DP ..... ie: telegraph pole).
He would check the pairs for 'noise' (disturbers) and go for the best dB reading ..... as near to -60dB as possible.
Either way, you have got a great result. Great news. :)
I think he just moved me in the cab away from other enabled lines. To be fair he had been before and was happy to get involved once I showed him the results..
Do I risk the billion to get the stats to prove if my cab prefers eci modem lol.. ??? ???
He can't do that. We are at the behest of the DCoE (Diagnostic Centre of Excellence) regarding DSLAM port allocation. If they deem a 'Lift & Shift' (New port) is necessary, they will allocate the next available one their systems tell them. They would otherwise have to mark up all available ports as faulty on their systems for it to auto-allocate another port well away from the masses ................ believe me, they will never, ever do this.
-
Ah well I believe what you say but I am only quoting what he told me.. ::)
-
No worries. I feel duty-bound to put the relevant info out there, otherwise folk might think they can just ask the engineers to move them onto a different DSLAM card, and I wouldn't want them to be disappointed now. ::)
-
Early this morning went onto G.Inp. Slight reduction in latency 10% increase in sync DS no change U/S as to be expected. ES DS gone to zero after daily average of circa 650.
All this bonus and still using SP06 firmware.
Long wait but initially seems worth it
-
Early this morning went onto G.Inp. Slight reduction in latency 10% increase in sync DS no change U/S as to be expected. ES DS gone to zero after daily average of circa 650.
All this bonus and still using SP06 firmware.
Long wait but initially seems worth it
Being on a long line the DS errored seconds is the enemy and G.INP does a great job to eliminate them almost by 99.6% :)
-
skyeci before you was g.inp you was interleaved, so a sync speed increase is no surprise, it will very likely also see an increase on the 8800nl, but by the same amount? you wont know until you try it.
Its very important to check for and specify here if its apple vs apple comparison, apple vs apple been fast path vs g.inp.
Managed to try the billion out tonight. It synced lower than the eci but latency was the same. Some difference in snrm values between the 2 modems.
Billion synced at 62 where as the eci synced at 66mb. Went back to the eci 40 mins later and it synced higher than the 8800nl, just shy of 66mb. Maybe the eci modems do sync higher....
So far for me the billion synced faster than eci pre g.inp but with high latency. Eci wins after g.inp for sync speed. Latency appears to be the same post g.inp at 11ms
-
My #CI not unlocked so I can only go of sync speed and IP profile. To me the eci sync about the same down as my billion but up was. 6.5 instead of around 7.9 with billion. So for me waited all this time for G.inp on ECI and apart from lot lower ES errors sync speed is slightly worse oh well better speed than some.
-
My #CI not unlocked so I can only go of sync speed and IP profile. To me the eci sync about the same down as my billion but up was. 6.5 instead of around 7.9 with billion. So for me waited all this time for G.inp on ECI and apart from lot lower ES errors sync speed is slightly worse oh well better speed than some.
How far from cab - I am about 330m
-
skyeci before you was g.inp you was interleaved, so a sync speed increase is no surprise, it will very likely also see an increase on the 8800nl, but by the same amount? you wont know until you try it.
Its very important to check for and specify here if its apple vs apple comparison, apple vs apple been fast path vs g.inp.
Managed to try the billion out tonight. It synced lower than the eci but latency was the same. Some difference in snrm values between the 2 modems.
Billion synced at 62 where as the eci synced at 66mb. Went back to the eci 40 mins later and it synced higher than the 8800nl, just shy of 66mb. Maybe the eci modems do sync higher....
So far for me the billion synced faster than eci pre g.inp but with high latency. Eci wins after g.inp for sync speed. Latency appears to be the same post g.inp at 11ms
Well my line is basically the same length as yours 320-350m(14.2dB) and I sync at 62mbps on the HG612 and 65mbps on an ECI modem.
-
skyeci before you was g.inp you was interleaved, so a sync speed increase is no surprise, it will very likely also see an increase on the 8800nl, but by the same amount? you wont know until you try it.
Its very important to check for and specify here if its apple vs apple comparison, apple vs apple been fast path vs g.inp.
But when the billion first got g.inp I lost sync speed both ways hence getting bt out.
yes but different pair, on this pair you was interleaved. hence the large jump.
-
My #CI not unlocked so I can only go of sync speed and IP profile. To me the eci sync about the same down as my billion but up was. 6.5 instead of around 7.9 with billion. So for me waited all this time for G.inp on ECI and apart from lot lower ES errors sync speed is slightly worse oh well better speed than some.
shame as now us ECI users choose between max sync speed or having a proper chipset for monitoring. Not just for monitoring either, I dont know of any ECI device other than the openreach one that can be used in bridge mode.
if chaos calmer is stable I guess I will be paying someone to put that on one of my ECI modems. :)
-
I would accept a small drop in ds(was about 4mb)if the latency is as good as the eci as I am more bothered about latency for gaming. Going to do some more tests with the billion at some point to see if it can keep the better latency at the acceptance of a small drop in ds. Would like to keep the monitoring so it might be an option I can live with. More tests later in the week...
-
Around 450 - 500m from cab
-
Around 450 - 500m from cab
How much did you lose on ds or us out of interest. Mine on 8800 was just under 4mb on ds only with g.inp and on the new pair. Cheers
-
activations seem to have slowed to a cruel now. Quite possibly due to the bank holiday.
-
I wonder how an unlocked ECU modem performs on an a huawei cabinet, I would like to know if it would perform better than a billion 8800nl.
-
Skyeci with the ECI I lost 1.5MB upstream and around 2 MB Downstream but don't know what attainable sync was. With the billion I get 7.5MB upstream and 40MB Downstream but I am one BT infinity 1. The attainable rate on the Billion is 46134 and 7999 which have reduced by 2MB and just over .5MB Upstream.
-
My HH5A lost sync/rebooted not long ago and it looks like I have G.INP enabled.
The Home Hub 5 reads now:
Data rate: 20000 / 79906
Maximum data rate: 32961 / 111252
*My data rate used to be 20000/79995 before the resync/reboot.*
On the BRAS checker it reports the following:
Downstream BRAS rate is: 77.35 Mbps
Upstream BRAS rate is: 20 Mbps
*My downstream BRAS used to be 77.44 Mbps.*
So it looks like all is well and follows the general ECI G.INP outcomes as of late.
Mark.
-
Just trying a Links dsl n66u and my Downstream has dropped to 33MB but upstream has increased to 9994 with attainable rates of 46MB down and 10590 UP. Shame it wont run on DSLstats so easy to monitor then
-
Early this morning went onto G.Inp. Slight reduction in latency 10% increase in sync DS no change U/S as to be expected. ES DS gone to zero after daily average of circa 650.
All this bonus and still using SP06 firmware.
Long wait but initially seems worth it
Being on a long line the DS errored seconds is the enemy and G.INP does a great job to eliminate them almost by
99.6% :)
Yes my line is 800m so I beleive
-
I only have access to the luci gui on my unlocked eci modem but it has re-synced twice today gaining another few hundred k on the DS. I also noticed that first thing this morning bitswap was off on the upstream. Its now on so at some point during one of those re-syncs its been applied along with the slightly faster DS..
Latest output
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 51m 10s — Resyncs: 3
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 66.272 Mb/s — 28.251 Mb/s
Actual Line Speed: 65.962 Mb/s — 20.000 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: ON
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.21 ms — 0.0 ms
INP: 44.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5410
LPATH: 0 — 0
Line Attenuation: 14.2 dB / 14.1 dB
Noise Margin/SNR: 5.8 dB / 9.9 dB
Transmit Power: 4.0 dBm / 3.8 dBm
Errors Since Line Up
FECS: 0 — 121
ES: 0 — 12109
SES: 0 — 2
LOSS: 0 — 216
UAS: 149 — 149
HEC: 0 — 0
CRC_P: 0 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 0
Errors in 1 Day
Code Violations: 0 — 3
FECS: 0 — 158
-
I think the bitswap status reported there (from the lfsg command) says enabled if it has actually done some bit swapping, and it will say disabled if it hasn't done any bit swaps yet, so it might not really indicate that the ability to bit swap has been switched off.
-
Yes my line is 800m so I beleive
But it won't stop DS errored seconds coming in when there is a line issue
poor old derekh is having a bad time of it :(
-
I guess nothing will. Not helped by my 800 having 600m of AL 😠 Still I recon I'm in a good place.
Any views if SP08 would be any advantage ?
Tony
-
I only have access to the luci gui on my unlocked eci modem but it has re-synced twice today gaining another few hundred k on the DS. I also noticed that first thing this morning bitswap was off on the upstream. Its now on so at some point during one of those re-syncs its been applied along with the slightly faster DS..
Latest output
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 51m 10s — Resyncs: 3
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 66.272 Mb/s — 28.251 Mb/s
Actual Line Speed: 65.962 Mb/s — 20.000 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: ON
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.21 ms — 0.0 ms
INP: 44.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5410
LPATH: 0 — 0
Line Attenuation: 14.2 dB / 14.1 dB
Noise Margin/SNR: 5.8 dB / 9.9 dB
Transmit Power: 4.0 dBm / 3.8 dBm
Errors Since Line Up
FECS: 0 — 121
ES: 0 — 12109
SES: 0 — 2
LOSS: 0 — 216
UAS: 149 — 149
HEC: 0 — 0
CRC_P: 0 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 0
Errors in 1 Day
Code Violations: 0 — 3
FECS: 0 — 158
Back on the billion for a few days. The ds drop is about 2.4mb compared the eci. Latency is same or 1ms slower than eci depending on which test I use.Interestingly though on various other tests the eci would not go above 19.50mb on the upstream. The billion however has managed a throughput of 22mb on the us. Perhapa the billion is better for US...
-
It would appear that g.inp has just been enabled on our line at work at about 09:30. Sync has stayed about the same as we are on a 40/10 package there was room for improvement on the US, but that's about the same as well. Stats are under Ronskiwork and we're using a hg612.
-
Just had a resync this morning and g.inp is now enabled. i'm in Cove, Aberdeen, where we've big problems with aluminium. will keep an eye on the errors as i have a good idea of the averages.
router is fritz.box 7490 so not got access to other stats
Negotiated Connection Properties
Receive direction Send direction
Max. DSLAM throughput kbit/s 20000 5000
Min. DSLAM throughput kbit/s 128 128
Attainable throughput kbit/s 21914 4879
Current throughput kbit/s 19998 4805
Seamless rate adaptation off off
Latency fast fast
Impulse noise protection 42 0
G.INP on off
Signal-to-noise ratio dB 9 6
Bitswap on off
Line attenuation dB 27 41
Profile 17a
G.Vector off off
Carrier record A43 A43
Error counter Seconds with Unrecoverable errors (CRC)
errors (ES) many Errors (SES) perminute Last15 minutes
FRITZ!Box 0 0 0 0
Central exchange 0 0 0 0
-
if there is an option i suggest enabling bitswap on your US in the fritzbox. Odd that is showing as disabled.
-
G.INP is enabled this morning as of a few minutes ago, woo! About a 3Mbps attainable downstream rate gain, 0.3Mbps upstream rate gain. Downstream sync rate is currently capped by DLM at 55Mbps but I might switch from the Draytek Vigor 2860 to the ASUS DSL-AC68U again as it works fine as long as G.INP is on the line. Not to mention if I go into debugging mode on the DSL-AC68U I could actually force the cap to 80/20 again, if I wanted to that is, rather than wait for DLM to take insanely long at doing so.
P.S. The downstream attainable rate is probably calculating to a target SNRM of 4dB, as that's what I have forced as the target SNRM on the Draytek Vigor 2860. As I'm banded it obviously can't go there at the moment though.
Stats from 2860:
> vdsl status
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 54997000 bps US Actual Rate : 15243000 bps
DS Attainable Rate : 72897864 bps US Attainable Rate : 15248450 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 19 dB Cur SNR Margin : 9 dB
DS actual PSD : 6. 7 dB US actual PSD : 12. 8 dB
NE CRC Count : 2 FE CRC Count : 14019
NE ES Count : 2 FE ES Count : 12306
Xdsl Reset Times : 0 Xdsl Link Times : 2
ITU Version[0] : b5004946 ITU Version[1] : 544e0000
VDSL Firmware Version : 05-07-06-0D-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 24 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb204
DSLAM CHIPSET VENDOR : < IFTN >
> vdsl status more
Near End Far End Note
Trellis : 1 1
Bitswap : 0 1
ReTxEnable : 0 1
VirtualNoise : 0 0
20BitSupport : 0 0
LatencyPath : 0 0
LOS : 2 0
LOF : 0 0
LPR : 0 0
LOM : 0 0
SosSuccess : 0 0
NCD : 0 0
LCD : 0 0
FECS : 0 73006 (seconds)
ES : 2 12306 (seconds)
SES : 1 5 (seconds)
LOSS : 0 174 (seconds)
UAS : 34 232133 (seconds)
HECError : 0 0
CRC : 2 14019
RsCorrection : 0 0
INP : 0 210 (symbols)
INTLVDelay : 0 15 (1/100 ms)
NFEC : 255 32
RFEC : 16 16
LSYMB : 4088 16
INTLVBLOCK : 255 32
AELEM : 0 ----
-
I am beginning to believe my eci cabinet will be the last in the country to get ginp! Come on BT.
-
if there is an option i suggest enabling bitswap on your US in the fritzbox. Odd that is showing as disabled.
not sure i can do this.
how common are resyncs shortly after G.INP is enabled? had 1 at 10am to enable then 4 during 1200-1300. i've been connected for an hour now but just wondering if this is normal?
-
if there is an option i suggest enabling bitswap on your US in the fritzbox. Odd that is showing as disabled.
not sure i can do this.
how common are resyncs shortly after G.INP is enabled? had 1 at 10am to enable then 4 during 1200-1300. i've been connected for an hour now but just wondering if this is normal?
Bitswapping option is either automatic (Fritz!Box decides when it is required) or isn't shown as 'on' unless a bitswap has occurred. Should only be one resync I thought.
-
ok thanks for that information ixel.
-
My line had G.INP enabled today. It's completely eliminated ES on the downstream, and increased my SNR by a solid 3-4.
I'm still banded at 27.4mbit sync rate, though now with 12DB SNR instead of the usual 8.5.
I'm hoping DLM will remove the banding on my downstream soon - it's likely that many thousands of lines that have recently had G.INP enabled will also benefit from banding removal/reduction due to the increased stability and less errors etc.
Fingers crossed it happens quickly ;D
-
Hey look daveesh1's ECI cab has interleaving on the up stream now INT: 89 INP: 2.50 DLY: 8 as predicted
-
Is there any pattern to which cabinets are getting G.INP enabled or is it just random?
Sent from my iPhone using Tapatalk
-
Is there any pattern to which cabinets are getting G.INP enabled or is it just random?
Sent from my iPhone using Tapatalk
Very random I did try to find a pattern when the Huawei's got activated with G.INP and burnt my fingers trying to find a pattern but it seems to be larger exchanges first and then the smaller ones
-
NS I don't think exchange size has anything to do with it either. @Broadstairs had g.inp applied yesterday I think, I'm on the same exchange but different cab and still don't have it, whilst at work (Sandwich) had it applied this morning and that's a much smaller exchange.
-
I tried my ASUS DSL-AC68U now G.INP appears to be enabled on my line/circuit and to my amazement there must be a bug in the firmware regarding supporting G.INP from ECI DSLAM's. It reports odd INP values and is acting as if I'm on the fallback to if G.INP isn't supported by the modem.
http://i.imgur.com/venI00D.png
NewtronStar: I'm on SDESTBR by the way.
-
NS I don't think exchange size has anything to do with it eirher. @Broadstairs had g.inp applied yesterday I think, I'm on the same exchange but different cab and still don't have it, whilst at work (Sandwich) had it applied this morning and that's a much smaller exchange.
I did say seems to be :) It was the same question I asked Kitz and that was the observation at that time.
-
NS, just giving you some more info from my observations and frustrations of not yet having it. There must be some order to it though, it could just be as simple as cab installation number/order.
-
The reason I think I have Interleaving is I tried my Asus DSL n66u yesterday and on the face of it it seemed to be ok but DLM must of taken a dislike to what was going on. So went back to Billion 8800AXL at 07.30 this morning. All I can hope for is DLM is kind.
-
Just to clarify mine was enabled about 07:40 Saturday downstream only. I'd sure like to know why the upstream was not enabled at the same time though, my router should be capable of both and if other ECI cabs have both enabled why not mine?
Stuart
-
No g.inp on upstream. Ds only.
Cheers
-
Apparently the ECI cabs won't support G.INP on the upstream (upstream as in from end user to cabinet, the 20 of 80/20). The ECI modems running OpenWRT should be able to do upstream G.INP (on Huawei cabs and if the DLM decides to enable it).
-
I did say seems to be :) It was the same question I asked Kitz and that was the observation at that time.
I cant recall saying it was... I can recall saying it wasn't alphabetical. In days of old they used to upgrade the larger exchanges first when it came to physical upgrading of equipment. With FTTC, although on a small exchange, your cab's Head end often resides at a much larger exchange... many of which also have a MSE bRAS now.
I've no idea how they decide for G.INP, which is a two stage process 1)The cab upgrade 2)Roll out the DLM profile to the EU. Neither of these require physical intervention as they are software config related and carried out remotely.
If there is a logical pattern I dont think we have found out what it was. Stage 2) may even be something line specific.. because we know that all the cabs have been upgraded before they start stage 2.
-
Hey look daveesh1's ECI cab has interleaving on the up stream now INT: 89 INP: 2.50 DLY: 8 as predicted
No g.inp on upstream. Ds only.
Cheers
OK so who is wrong,
Stuart
-
Neither, interleaving isn't G.INP. Interleaving and FEC is the older method of providing error correction.
-
This is what happened to my line pre new pair.
"Your upstream now has had an old-style DLM intervention, setting an INP of 2.5 and a delay of 8ms; the modems have turned on FEC and interleaving. However, it doesn't look to have G.INP running upstream; I wouldn't expect it, either"
-
Neither, interleaving isn't G.INP. Interleaving and FEC is the older method of providing error correction.
My bad .... I mis-read it.....
Stuart
-
Updated table.
Thanks for those who have also provided stats in the thread, but I need before and after figures to be able to make comparisons.
Theres also possibly a couple more, but I cant check their cab status if they are offline to make sure that they are ECI.
Going from MDWS, about 2/3rds of lines have now been activated.
-
Here are my new stats:
BT OpenReach VDSL Modem
OpenWrt Chaos Calmer r46559 / LuCI Master (git-15.216.69575-bb7ea3e)
Kernel Version 3.18.19
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 1d 11h 45m 53s — Resyncs: 2
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 72.771 Mb/s — 21.236 Mb/s
Actual Line Speed: 72.371 Mb/s — 18.999 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: OFF
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.19 ms — 0.0 ms
INP: 43.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5134
LPATH: 0 — 0
Line Attenuation: 16.5 dB / 17.1 dB
Noise Margin/SNR: 6.0 dB / 6.4 dB
Transmit Power: 12.6 dBm / 6.0 dBm
Errors Since Line Up
FECS: 0 — 3650820
ES: 59 — 65794
SES: 0 — 279
LOSS: 7 — 345
UAS: 73 — 73
HEC: 0 — 0
CRC_P: 179 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 9
Errors in 1 Day
Code Violations: 0 — 0
FECS: 0 — 9
Looks like G.INP was enabled about 1 days 11 hours ago on my ECI cab, and it brought a significant speed improvement for me :yay:
Previously I had speeds in the region of 61.300 and 62.500 Mb/s for downstream and 18.999 Mb/s for upstream, with downstream interleaving in the region of 700-1000 (for this modem). With an unlocked H612, interleaving was previously in the region of 1200-1900 and speeds were similar (maybe a tad higher at times).
The attainable speeds were very similar both pre and post G.INP.
-
Kitz, the figures you have in the table are actually my HG612 figures, not the Vigor. For clarification, the figures for both the Draytek and the HG612 are as follows:-
Vigor 2760
Pre-G.INP Down 48680 Up 12104
Post-G.INP Down 52838 Up 12104
HG612
Pre-G.INP Down 53049 Up 13160
Post-G.INP Down 50320 Up 13160
-
I thought I had it earlier, a video stopped streaming mid video, and thought ooookay is modem resyncing. Wasnt so I guess was just a temporary network glitch. :(
-
i would leave my line stats off the comparison as my line has been limited to 20mb since i moved to plus net, but thats a diff story!
also G.INP seems to have killed my connection and have opeanreach eng being arranged due to constant disconnects (24 since it was enabled yesterday :/)
-
Had to reboot my router after G.INP got enabled (zero network connectivity) so cannot provide full old stats but here are the new ones.
Old stats pulled from mydslwebstats (username is Durkasmurk)
Downstream 70059
Upstream 18610
New stats.
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pvbH042g2.d26b
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hour 46 min 35 sec
Resyncs: 2 (since 28 Mar 2016 13:01:06)
Downstream Upstream
Line attenuation (dB): 18.1 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 77778 18525
SNR margin (dB): 6.4 6.3
Power (dBm): 13.8 6.8
Interleave depth: 1 1
INP: 49.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0636 0.0006
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0.87 1.07
adslctl info --stats
adslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 18899 Kbps, Downstream rate = 79141 Kbps
Bearer: 0, Upstream rate = 18525 Kbps, Downstream rate = 77778 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.4 6.3
Attn(dB): 18.1 0.0
Pwr(dBm): 13.8 6.8
-
hi has any one in Coventry had an update on there ECI cab yet I'm on tile hill exch cab9 and really need an update.to improve my line. don't have Ginp Yet
if any one could help with my states
eci cab
cracked hg612 modem
Sky 40/10
ta
Stats recorded 30 Mar 2016 23:32:22
DSLAM/MSAN type: IFTN:0xb206 / v0xb206
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 10 days 15 hours 51 min 25 sec
Resyncs: 0 (since 21 Mar 2016 23:13:18)
Downstream Upstream
Line attenuation (dB): 27.9 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 24139 6420
SNR margin (dB): 5.8 6.0
Power (dBm): 7.1 7.1
Interleave depth: 473 1
INP: 3.00 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 32.4972 0.0162
RSUnCorr/RS (%): 0.0109 0.0000
ES/hour: 5.74 0.64
:(
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 6425 Kbps, Downstream rate = 26924 Kbps
Bearer: 0, Upstream rate = 6420 Kbps, Downstream rate = 24139 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): 5.8 6.0
Attn(dB): 27.9 0.0
Pwr(dBm): 7.1 7.1
VDSL2 framing
Bearer 0
MSGc: 22 33
B: 51 201
M: 1 1
T: 64 5
R: 12 16
S: 0.0685 1.0000
L: 7472 1744
D: 473 1
I: 64 218
N: 64 218
Counters
Bearer 0
OHF: 208882102 841586
OHFErr: 9416 196
RS: 1934152947 2089774
RSCorr: 655744738 576
RSUnCorr: 219616 0
Bearer 0
HEC: 49135 0
OCD: 2735 0
LCD: 2735 0
Total Cells: 4020879628 0
Data Cells: 2671895409 0
Drop Cells: 0
Bit Errors: 0 0
ES: 165293 436
SES: 151 0
UAS: 1018 967
AS: 919647
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 4.40 16.31
OR: 50.87 19.12
AgR: 24189.50 6438.84
Bitswap: 589726/590184 1751/1821
Total time = 1 days 10 hours 6 min 12 sec
FEC: 1675880127 1433
CRC: 26393 408
ES: 165293 436
SES: 151 0
UAS: 1018 967
LOS: 5 0
LOF: 37 0
LOM: 0 0
Latest 15 minutes time = 6 min 12 sec
FEC: 1722 1
CRC: 1 0
ES: 1 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: 8334 0
CRC: 4 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 10 hours 6 min 12 sec
FEC: 35403393 38
CRC: 338 4
ES: 62 4
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 125294950 62
CRC: 596 22
ES: 149 19
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 10 days 15 hours 27 min 25 sec
FEC: 655744738 576
CRC: 9416 196
ES: 5065 187
SES: 5 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Kitz, the figures you have in the table are actually my HG612 figures, not the Vigor. For clarification, the figures for both the Draytek and the HG612 are as follows:-
Thanks - it was only later that someone requested adding the modem type.. so I scanned through about 20+ pages looking for any posts which mentioned a modem make.
I'll update the chart later when I add in todays new g.inped.
-
Quick update ... some more stats taken just under 24h later (since the stats I posted yesterday were taken just after the 'Errors in 1 Day' counter reset itself for the day):
BT OpenReach VDSL Modem (ECI/r v2)
OpenWrt Chaos Calmer r46559 / LuCI Master (git-15.216.69575-bb7ea3e)
Kernel Version 3.18.19
Uptime: 9d 21h 36m 22s
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 2d 8h 0m 36s — Resyncs: 2
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 72.640 Mb/s — 21.198 Mb/s
Actual Line Speed: 72.371 Mb/s — 18.999 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: OFF
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.19 ms — 0.0 ms
INP: 43.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5134
LPATH: 0 — 0
Line Attenuation: 16.5 dB / 17.1 dB
Noise Margin/SNR: 5.9 dB / 6.4 dB
Transmit Power: 12.6 dBm / 6.0 dBm
Errors Since Line Up
FECS: 0 — 6150665
ES: 60 — 65914
SES: 0 — 279
LOSS: 7 — 345
UAS: 73 — 73
HEC: 0 — 0
CRC_P: 179 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 4
Errors in 1 Day
Code Violations: 2 — 131
FECS: 0 — 2499830
No resyncs since 2d 8h ago when G.INP got enabled for me (just the original resync when the modem was connected ~10 days ago and then the resync due to G.INP being enabled which occurred 2d 8h ago). So far so good and still a very happy bunny ;D
I'll give it a few more days to settle and then I'll try reconnecting my HG612 back and see what I get... and post the results here.
-
At last!!
Latency down to 8ms from 18ms. Sync d/s about 3Mb/s higher but actual d/l speed much as it was currently.
Here are telnet stats for those interested:
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 17 min 7 sec
Resyncs: 1 (since 28 Mar 2016 07:15:35)
Downstream Upstream
Line attenuation (dB): 23.2 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 37947 4645
SNR margin (dB): 6.3 6.0
Power (dBm): 11.8 0.4
Interleave depth: 1 1
INP: 49.00 0
G.INP: Enabled Not enabled
RSCorr/RS (%): 0.0026 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 3.21 0
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 4741 Kbps, Downstream rate = 39732 Kbps
Bearer: 0, Upstream rate = 4645 Kbps, Downstream rate = 37947 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.3 6.0
Attn(dB): 23.2 0.0
Pwr(dBm): 11.8 0.4
VDSL2 framing
Bearer 0
MSGc: -6 33
B: 227 145
M: 1 1
T: 0 5
R: 6 16
S: 0.1911 0.9977
L: 9796 1299
D: 1 1
I: 234 162
N: 234 162
Q: 4 0
V: 0 0
RxQueue: 66 0
TxQueue: 22 0
G.INP Framing: 18 0
G.INP lookback: 22 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 67057
OHFErr: 0 0
RS: 22664144 63096
RSCorr: 569 0
RSUnCorr: 0 0
Bearer 1
OHF: 67735 0
OHFErr: 0 0
RS: 406039 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 76 0
rtx_c: 52 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 37940 0
errFreeBits: 629329 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 79378392 0
Data Cells: 2674618 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: 200 1
SES: 11 0
UAS: 57 46
AS: 1088
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 16.27
OR: 0.01 19.16
AgR: 38030.72 4664.59
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: 744/744 0/0
Total time = 1 days 9 hours 28 min 41 sec
FEC: 1129245 51
CRC: 3704 2
ES: 200 1
SES: 11 0
UAS: 57 46
LOS: 1 0
LOF: 10 0
LOM: 0 0
Latest 15 minutes time = 13 min 41 sec
FEC: 425 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: 4319 0
CRC: 3246 0
ES: 12 0
SES: 11 0
UAS: 34 23
LOS: 1 0
LOF: 10 0
LOM: 0 0
Latest 1 day time = 9 hours 28 min 41 sec
FEC: 176026 4
CRC: 3291 0
ES: 32 0
SES: 11 0
UAS: 34 23
LOS: 1 0
LOF: 10 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 343254 5
CRC: 126 0
ES: 54 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 18 min 7 sec
FEC: 569 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
great news tony, I smiled when I seen your g.inp active email.
Still waiting here sadly :( but at least I am on fast path not interleaved.
-
At last!!
Latency down to 8ms from 18ms. Sync d/s about 3Mb/s higher but actual d/l speed much as it was currently.
Here are telnet stats for those interested:
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
<snip>
As your circuit still shows 0xb204, perhaps you will keep a look-out for a big increase in US FECs?
-
. . . but at least I am on fast path not interleaved.
I thought that all Openreach provided VDSL2 circuits are interleaved, with a minimum depth setting of 1. I.e. An interleave depth of 1:1 ???
-
Hi all!
Just checked mine stats and seems like G.INP has been enabled few days ago here on ECI as well. All I noticed is Downstream is 40000 instead of 39xxx and much less ES on downstream. Haven't noticed any latency and upstream speed improvements unfortunately. Should I expect it with G.INP enabled? Also G.INP has only been enabled on downstream, why not on both?
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 5 days 9 hours 29 min 21 sec
Resyncs: 0 (since 31 mar 2016 19:13:20)
Downstream Upstream
Line attenuation (dB): 21,9 0,0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 40000 7748
SNR margin (dB): 9,6 6,1
Power (dBm): 12,6 5,5
Interleave depth: 1 1
INP: 47,00 0
G.INP: Enabled Not enabled
RSCorr/RS (%): 0,0232 1,3321
RSUnCorr/RS (%): 0,0000 0,0000
ES/hour: 5,32 4,39
///////////////////////////////////////////////////////////////////////////////////////////
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7831 Kbps, Downstream rate = 48844 Kbps
Bearer: 0, Upstream rate = 7748 Kbps, Downstream rate = 40000 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): 9.6 6.1
Attn(dB): 21.9 0.0
Pwr(dBm): 12.6 5.5
VDSL2 framing
Bearer 0
MSGc: -6 33
B: 178 238
M: 1 1
T: 0 22
R: 6 16
S: 0.1424 0.9808
L: 10390 2080
D: 1 1
I: 185 255
N: 185 255
Q: 16 0
V: 2 0
RxQueue: 22 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 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 795823
OHFErr: 30 683
RS: 145516928 1405674
RSCorr: 35744 35028
RSUnCorr: 0 0
Bearer 1
OHF: 29001836 0
OHFErr: 0 0
RS: 174010646 0
RSCorr: 102 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 9728 0
rtx_c: 8368 0
rtx_uc: 56 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 39991 0
errFreeBits: 284155153 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1474080889 0
Data Cells: 1606943776 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: 913 753
SES: 12 0
UAS: 58 48
AS: 465861
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 16.24
OR: 0.01 19.20
AgR: 40055.64 7767.61
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: 286309/286383 0/0
Total time = 1 days 3 hours 26 min 10 sec
FEC: 35744 35028
CRC: 30 683
ES: 913 753
SES: 12 0
UAS: 58 48
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 11 min 10 sec
FEC: 6 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: 7 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 3 hours 26 min 10 sec
FEC: 329 35
CRC: 0 10
ES: 0 10
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 5694 3824
CRC: 0 94
ES: 0 88
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 days 9 hours 24 min 21 sec
FEC: 35744 35028
CRC: 30 683
ES: 10 582
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Went to check if my ECI cab was enabled and realised I'd forgot to plug the cable back in after a move ages ago. A quick cable connect and update the software and I am indeed g.inp enabled too.
I'm quite close to the cab, so not sure of any difference to me anyhow.
-
I also got G.INP this afternoon. S/N has increased by aprox 2 dB however as I am banded have seen no improvement.
-
. . . but at least I am on fast path not interleaved.
I thought that all Openreach provided VDSL2 circuits are interleaved, with a minimum depth setting of 1. I.e. An interleave depth of 1:1 ???
they are but that is pretty much fast path anyway so I just call it fast path (as do many others).
-
Ronski is the next one to get ECI G.INP at 18:06 such weird times for the switch over
-
I see NS beat me to it, but finally I have G.INP, must be a welcome home present from BT ;D
A healthy improvement of 3908Kbps on the downstream, and a decrease of 170Kbps on the upstream, was hoping for a bit more but it was 6pm after all, might see what the attainable looks like around midday tomorrow.
Kitz if you need any info that's not on MDWS then give me a nudge.
-
Is is normal since ginp to have a large gap between sync speed and attainable rate?
-
I am still on target to get this g.inp last :p Not many live users on MDWS left now.
I even did a 30 min power off a couple of days ago (on the advice of someone who it worked for) but it had no affect.
-
So now I know why I resynched a couple of days ago & my download jumped by 4 Mbps to within 1 of maximum. I've been GIMPED!! ;)
-
Hey all. I was recently G.INP'd whilst using my Billion 8800NL. The stats are below. I bought a Draytek 2860n yesterday, and whilst it does sync higher (stats below) - it seems less reliable. This morning I had no internet throughput and the Draytek said my downstrem SNRM was -5!? One power cycle later and I resync'd at: Down Stream : 68116Kbps / Up Stream : 20000Kbps.
Billion stats:
Stats recorded 01 Apr 2016 10:36:23
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 day 15 hours 54 min 37 sec
Resyncs: 0 (since 30 Mar 2016 18:43:20)
Downstream Upstream
Line attenuation (dB): 16.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 66784 20000
SNR margin (dB): 6.8 9.5
Power (dBm): 13.4 6.3
Interleave depth: 1 1
INP: 49.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.2472 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0.19 0
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 25612 Kbps, Downstream rate = 68650 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66784 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.8 9.5
Attn(dB): 16.9 0.0
Pwr(dBm): 13.4 6.3
VDSL2 framing
Bearer 0
MSGc: -6 150
B: 243 236
M: 1 1
T: 0 5
R: 6 16
S: 0.1163 0.3771
L: 17191 5410
D: 1 1
I: 250 255
N: 250 255
Q: 8 0
V: 0 0
RxQueue: 54 0
TxQueue: 18 0
G.INP Framing: 18 0
G.INP lookback: 18 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 1534592
OHFErr: 956 0
RS: 622802808 2928241
RSCorr: 1544682 0
RSUnCorr: 0 0
Bearer 1
OHF: 8939641 0
OHFErr: 0 0
RS: 89395797 0
RSCorr: 153 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 280643 0
rtx_c: 246733 0
rtx_uc: 4940 0
G.INP Counters
LEFTRS: 12 0
minEFTR: 66778 0
errFreeBits: 146204596 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1253328137 0
Data Cells: 757849452 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: 35 0
SES: 19 0
UAS: 25 25
AS: 143618
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.15
OR: 0.01 202.87
AgR: 66852.52 20203.27
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: 28610/28610 0/0
Total time = 1 days 15 hours 54 min 3 sec
FEC: 1544682 0
CRC: 956 0
ES: 35 0
SES: 19 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 3 sec
FEC: 0 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: 85 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 15 hours 54 min 3 sec
FEC: 785861 0
CRC: 469 0
ES: 15 0
SES: 8 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 758821 0
CRC: 487 0
ES: 20 0
SES: 11 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 15 hours 53 min 37 sec
FEC: 1544682 0
CRC: 956 0
ES: 35 0
SES: 19 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
Draytek Stats:
> vdsl annex
% hardware is annex A.
% VDSL2 modem code is annex A/B/C with Vectoring support
> vdsl status
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 67646000 bps US Actual Rate : 20000000 bps
DS Attainable Rate : 66728764 bps US Attainable Rate : 24435180 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 17 dB Cur SNR Margin : 5 dB
DS actual PSD : 4. 8 dB US actual PSD : 13. 4 dB
NE CRC Count : 37 FE CRC Count : 1785
NE ES Count : 6 FE ES Count : 224
Xdsl Reset Times : 0 Xdsl Link Times : 3
ITU Version[0] : b5004946 ITU Version[1] : 544e0000
VDSL Firmware Version : 05-07-04-03-00-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DRIVER
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 17 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb204
DSLAM CHIPSET VENDOR : < IFTN >
>
>
> vdsl status more
Near End Far End Note
Trellis : 1 1
Bitswap : 0 1
ReTxEnable : 0 1
VirtualNoise : 0 0
20BitSupport : 0 0
LatencyPath : 0 0
LOS : 0 0
LOF : 0 0
LPR : 0 0
LOM : 0 0
SosSuccess : 0 0
NCD : 0 0
LCD : 0 0
FECS : 0 67840 (seconds)
ES : 6 224 (seconds)
SES : 1 35 (seconds)
LOSS : 0 336 (seconds)
UAS : 57 53739 (seconds)
HECError : 0 0
CRC : 37 1785
RsCorrection : 0 0
INP : 0 215 (symbols)
INTLVDelay : 0 21 (1/100 ms)
NFEC : 255 32
RFEC : 16 16
LSYMB : 5410 16
INTLVBLOCK : 255 32
AELEM : 0 ----
>
> vdsl annex
% hardware is annex A.
% VDSL2 modem code is annex A/B/C with Vectoring support
Can anyone recommend a VRX268 modem/router that in their experience has been reliable? Thanks
-
[Moderator edited to remove the unnecessary entire quotation of the previous post.]
My 8800nl has been fine for 4 days with g.inp. The only issue is it syncs 2-5mb less than an unlocked eci modem depending on whats happening. The latency is the same but I can live with a slight decrease just to have some stats from the billion
Cheers
-
Yeah that is why I thought I would like to try VRX268 modem/router that is perhaps more reliable maybe.
-
My Draytek 2760 (VRX288 same as 2860) has been rock solid on latest firmware 3.8.1_VT2 with modem code 574307.
There are reports on the Draytek forum of problems with the 2860 latest firmware, although some people seem ok with it. There are no reports of 2760 issues.
-
Thanks Atkinsong, I will persist a bit longer and have a fiddle ;D
-
I forced a resync on my line this morning, left it off for just over half an hour, lost a little bit of speed but at least my Plus Net profile is now at 49.6 instead of 46 as it hadn't updated after G.INP was applied.
-
I've joined the club at some point this last week too, gained about 4meg sync down but upstream has dropped about 800kbps
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 6133 Kbps, Downstream rate = 38720 Kbps
Bearer: 0, Upstream rate = 6172 Kbps, Downstream rate = 36837 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.5 6.0
Attn(dB): 23.7 0.0
Pwr(dBm): 12.1 2.1
VDSL2 framing
Bearer 0
MSGc: -6 33
B: 227 193
M: 1 1
T: 0 5
R: 10 16
S: 0.1969 0.9988
L: 9672 1682
D: 1 1
I: 238 210
N: 238 210
Q: 4 0
V: 0 0
RxQueue: 63 0
TxQueue: 21 0
G.INP Framing: 18 0
G.INP lookback: 21 0
RRC bits: 0 24
-
Tomorrow taking delivery of some metal covers for the windows to prepare for the bombardment against my line from openreach agents who want it to stop been stubborn staying on fast path instead of g.inp.
-
Dont know if its a coincidence put as soon as I hooked up my OpenWRT ECI modem the INP went from 49 to 45.
Also just generally HG612 vs ECI modem stats.
How can the Line attenuation vary?
-
I can't explain why but I too see large differences on my line between the 8800nl and unlocked ECI. The eci comes out better all round for me where as it was the 8800nl pre g.inp
Can only assume its the chipset of the eci working better with my eci cabinet than the 8800nl after g.inp.
I have sent stats pre and post g.inp showing the 8800nl underperforming compared to the eci via a support ticket with billion so be inteteresting to see what they come back with..
-
Just out of interest you with sky?
If so how does the Sr102 stack up?
-
Yes with sky. The sr102 always syncs lower than the other 2 post and pre g.inp.
Pre g.inp was
880nl
Sr102
Eci unlocked
Post
Eci (66 -68mb)
8800nl (62-65mb, depending on conditions it seems and large snrm variance between the 8800 & eci)
Sr102(60mb)
-
Thanks...
I 'think' I've had G.inp applied.
Due to noise caused by crosstalk and presumably my Homeplugs I was stuck on 15 down and 5 up.
It resynced a few days back and I've jumped to 20 down and 5 up.
I have a non modded ECI modem and modded hg612, but no way of passing on my Sky Password at the moment.
My neighbour also resynced and is on BT, so I may go over and plug in the hg612.
Just weighing up if I should get a Asus RT-N66U, to use with the ECI.
-
Is is normal since ginp to have a large gap between sync speed and attainable rate?
I have restarted the modem a few times (30m rule) but the is still a big gap between actual and attainable. Looking over eci on mdws quite a few users seem to have the same issue. Why is this? Thanks
-
Thanks...
I 'think' I've had G.inp applied.
Due to noise caused by crosstalk and presumably my Homeplugs I was stuck on 15 down and 5 up.
It resynced a few days back and I've jumped to 20 down and 5 up.
I have a non modded ECI modem and modded hg612, but no way of passing on my Sky Password at the moment.
My neighbour also resynced and is on BT, so I may go over and plug in the hg612.
Just weighing up if I should get a Asus RT-N66U, to use with the ECI.
Do you have your sr102? as you can use a simple util from skyuser to get your username and password and then use this on your router.
I use 8800nl or eci unlocked depending on how I feel alonside the asus rt-ac87u running merlin on sky fibre pro
the util is very easy to use - if you need any help let me know.
-
Yes, I've wiresharked my password...
At the moment I use my sr102 and homehub 5 to handle the wifi.
But was waiting for G.inp to be applied to see what the best option was.
-
I don't know if you're aware you can simply plug your Openreach modem LAN1 into any yellow LAN port on your SR102?
-
Really?
And the Sr102 provides the password?
-
Using the ECI modem with another router will not increase speeds, except for maybe WI-FI.
-
How can the Line attenuation vary?
Attenuation varies according to frequency, so there isn't just a single figure that describes the complete spectrum. If you look at the output from "--pbParams", it will give attenuation values for each band, for example.
So ... the modem has to aggregate all the attenuation values for all tones, in some way, to come up with a single value. That task probably leaves the modem firmware a little scope for doing things differently.
And, of course, the more complicated the job is, the more scope there is for bugs. Or subtle interpretations of specs. Or differences in receiver sensitivity. Or even just a dodgy connector pin on the modem.
-
Using the ECI modem with another router will not increase speeds, except for maybe WI-FI.
But looking at "skyeci"
he sees:
Eci (66 -68mb)
8800nl (62-65mb, depending on conditions it seems and large snrm variance between the 8800 & eci)
Sr102(60mb)
Do you not think I'll see extra speed passed on from the eci modem to a separate router on my ECI cabinet as opposed to using the Sr102 and hh5?
-
Really?
And the Sr102 provides the password?
Yes, this is one of the ways of finding the username and password - using an app to fool the SR102 into thinking it's connected to a modem when it's connected to your PC which captures the username and password. But if you connect the SR102 to a modem, it just acts as a router only.
-
Using the ECI modem with another router will not increase speeds, except for maybe WI-FI.
But looking at "skyeci"
he sees:
Eci (66 -68mb)
8800nl (62-65mb, depending on conditions it seems and large snrm variance between the 8800 & eci)
Sr102(60mb)
Do you not think I'll see extra speed passed on from the eci modem to a separate router on my ECI cabinet as opposed to using the Sr102 and hh5?
Pretty sure he was in about the inbuilt modems in those routers, the ECI modem should sync at around the same rate no matter the router.
-
Using the ECI modem with another router will not increase speeds, except for maybe WI-FI.
But looking at "skyeci"
he sees:
Eci (66 -68mb)
8800nl (62-65mb, depending on conditions it seems and large snrm variance between the 8800 & eci)
Sr102(60mb)
Do you not think I'll see extra speed passed on from the eci modem to a separate router on my ECI cabinet as opposed to using the Sr102 and hh5?
I do see faster sync using the eci unlocked modem (bt ) against my hg612 &8800nl & the sr102 but this was ONLY after g.inp was activated on my eci cab. You will only know if it truly helps by testing as no other way of knowing..
Jsamuel on this forum will load openwrt and mod the locked modem so you can get stats from it and lists on ebay. He did mine (as I didnt want to do it myself)and it does allow the stats and gave me the higher sync compared to all the others so for me it works but cant really say for yours...
You could try the modem first or get it modded so you can see the stats and see if it helps...
Note my figures are when using a modem and router as seperates and not as all in ones apart from the sr102..The sync rates are from the modem stats and not through the router on speed tests etc..
I use the 8800nl in bridge mode only (as a modem) and sent the stats to billion as it does not sync as high as the eci on the several syncs done at different times post g.inp. I am waiting for a response as they asked for the stats for both which they are now looking at so I await a response..
-
Using the ECI modem with another router will not increase speeds, except for maybe WI-FI.
But looking at "skyeci"
he sees:
Eci (66 -68mb)
8800nl (62-65mb, depending on conditions it seems and large snrm variance between the 8800 & eci)
Sr102(60mb)
Do you not think I'll see extra speed passed on from the eci modem to a separate router on my ECI cabinet as opposed to using the Sr102 and hh5?
I do see faster sync using the eci unlocked modem (bt ) against my hg612 &8800nl & the sr102 but this was ONLY after g.inp was activated on my eci cab. You will only know if it truly helps by testing as no other way of knowing..
Jsamuel on this forum will load openwrt and mod the locked modem so you can get stats from it and lists on ebay. He did mine (as I didnt want to do it myself)and it does allow the stats and gave me the higher sync compared to all the others so for me it works but cant really say for yours...
You could try the modem first or get it modded so you can see the stats and see if it helps...
Note my figures are when using a modem and router as seperates and not as all in ones apart from the sr102..The sync rates are from the modem stats and not through the router on speed tests etc..
I use the 8800nl in bridge mode only (as a modem) and sent the stats to billion as it does not sync as high as the eci on the several syncs done at different times post g.inp. I am waiting for a response as they asked for the stats for both which they are now looking at so I await a response..
You have a link to his ebay page? I may do this, as I'm interested in the stats.
-
Yeap. This should work hopefully.
http://www.ebay.co.uk/itm/231887970610
You just post your bt eci modem with psu.
If the link does not work then search for
Upgrade your BT Openreach FTTC VDSL2 Modem ECI B-FOCuS V-2FUb/R Rev.B OpenWrt
Seller lisa*alexander
The stats are from the luci console.
-
Yeap. This should work hopefully.
http://www.ebay.co.uk/itm/231887970610
You just post your bt eci modem with psu.
If the link does not work then search for
Upgrade your BT Openreach FTTC VDSL2 Modem ECI B-FOCuS V-2FUb/R Rev.B OpenWrt
Seller lisa*alexander
The stats are from the luci console.
Cheers...
That works fine.
-
Seems i am now G.INP enabled confirmed from plusnet 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
but it has had a negative effect rather than a positive one my ping has gone from 13-15ms to around 21-25ms and i have lost down speed my BTW IP profile has dropped from 46.8 to 42.55 so lost almost 4Mb not happy was hoping i would gain not loose, I'm using the Openreach ECI modem and wondering if that is the issue i don't remember at all of it updating firmware etc then again i have no way of knowing due to it being locked and i don't have the skills to unlock one either :(
-
You could always buy a modem that does support G.INP
-
Terranova, going by the figures it sounds more like you've had interleaving applied rather than g.inp ???
-
But the Plusnet profile shows G.INP is enabled.
-
Seems i am now G.INP enabled confirmed from plusnet 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
but it has had a negative effect rather than a positive one my ping has gone from 13-15ms to around 21-25ms and i have lost down speed my BTW IP profile has dropped from 46.8 to 42.55 so lost almost 4Mb not happy was hoping i would gain not loose, I'm using the Openreach ECI modem and wondering if that is the issue i don't remember at all of it updating firmware etc then again i have no way of knowing due to it being locked and i don't have the skills to unlock one either :(
I too have lost my g.inp on my 8800nl today. Sadly my monitoring pc was down as I was replacing the hard drive.
Lost sync rate on ds with delay and no g.inp.
I wonder what has caused this as it was fine until today..
Update spoke to billion - have sent a newer firmware to try on the 8800nl as seems to be an ongoing issue..unless bt have turned it off ??
-
The guy (billion_fan) on the Billion forum said to try version 2.32d.dm2 on my 8800NL with ECI cab...
https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32d.dm2.afw (https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32d.dm2.afw)
It does seem to produce less FEC errors...
-
Yes thanks. Support just sent me that version so will load it late tonight..
Monitoring back up so will see what happens...
-
You could always buy a modem that does support G.INP
yeah i'm thinking that but I would rather know if the Openreach ECI modem supports G.INP before splashing out and if it does why it's not helping me and instead made things worse i don't want to spend Money for something that isn't going to improve anything.
Also If i was to get a new modem I much prefer the separate setup due to how things are layed out at home which is ECI Openreach modem in the master socket in the hallway and the router is upstairs where the main PC is, pretty much everything of importance to me that i use the most PC PS4,PS3 is connected to the router via Ethernet so if i were to use an all in one i would need a Switch box on top of the expense unless anyone knows of just a ECI modem to replace the Openreach one that is G.INP enabled.
@Ronski I'm for sure G.INP enabled as noted by Retransmission on the download for my DLM profile if it were Interleaving it would show Error protection as it does for the upload as for the figures yeah It looks to me like it was when G.INP was first enabled for those who had ECI modems on Huawei cabs and they had ping increases and lost some Down speed, i'm guessing my ECI openreach modem maybe isn't compatible but as i say i have no way of testing that.
-
You could always buy a modem that does support G.INP
yeah i'm thinking that but I would rather know if the Openreach ECI modem supports G.INP before splashing out and if it does why it's not helping me and instead made things worse i don't want to spend Money for something that isn't going to improve anything.
Also If i was to get a new modem I much prefer the separate setup due to how things are layed out at home which is ECI Openreach modem in the master socket in the hallway and the router is upstairs where the main PC is, pretty much everything of importance to me that i use the most PC PS4,PS3 is connected to the router via Ethernet so if i were to use an all in one i would need a Switch box on top of the expense unless anyone knows of just a ECI modem to replace the Openreach one that is G.INP enabled.
@Ronski I'm for sure G.INP enabled as noted by Retransmission on the download for my DLM profile if it were Interleaving it would show Error protection as it does for the upload as for the figures yeah It looks to me like it was when G.INP was first enabled for those who had ECI modems on Huawei cabs and they had ping increases and lost some Down speed, i'm guessing my ECI openreach modem maybe isn't compatible but as i say i have no way of testing that.
Well I was going to say you could risk using a billion 8800nl in modem mode which is what I do alongside my asus router. Its supposed to be g.inp compatiable and allows you to get the stats from a pc if you want to using hg612 stats.
Mine has definetly been g.inp but hopefully the new firmware might help as its currently gone.. ???
I have had my line checked and a new dp pair just prior to g.inp and saw better figures after g.inp so fingers crossed it will be back as it was at some point...
I find its handy having the 8800 as it can be a modem (bridge mode) or modem + router combined so its handy to have should my asus go down...
I have also used bt eci modem which had been unlocked and configured with openwrt and it showed g.inp as on plus a higher sync rate than the billion but due to the lack of stats gathering I sent my modem to fellow forum member as he is trying to resolve the stats issue. Just hope the new firmware will provide a good result on my 8800nl as I am now not totally convinced its compatiable.... ???
-
what is the "DSL PHY and Driver Version" for that .dm2 firmware? as .dm2 is the first firmware, the old one.
-
what is the "DSL PHY and Driver Version" for that .dm2 firmware? as .dm2 is the first firmware, the old one.
I can't see it in DSL stats. Is there a telnet command to see?
-
what is the "DSL PHY and Driver Version" for that .dm2 firmware? as .dm2 is the first firmware, the old one.
Yeah I queried that and support said to me it was a later version.... Will see later when I have loaded it..
-
Sorry, brain fart. The info is in the web interface:
Software Version 2.32d.dm2
DSL PHY and Driver Version A2pv6F038j.d24h
Wireless Driver Version 6.30.102.7.cpe4.12L08.4
-
I had a re-read of the G.INP roll out thread of when the Huawei cabs were first enabled and the issues with Openreach ECI modems not being G.INP compatible is that still true even with the change BT did and with a ECI cab, if that's the case then a new modem would be the only way to get my speed & latency back to where it was or maybe even fingers crossed a little better, it would be nice to know before splashing out on new gear.
If new gear is required any recommendations on a ECI G.INP enabled modem to replace the Openreach one if there is one, I would still prefer the separate modem router setup as that requires me spending less money.
-
A2pv6F039g1.d24m
Sorry, brain fart. The info is in the web interface:
Software Version 2.32d.dm2
DSL PHY and Driver Version A2pv6F038j.d24h
Wireless Driver Version 6.30.102.7.cpe4.12L08.4
thanks, for reference this is the DSL driver version on my 8800nl using the newer firmware.
A2pv6F039g1.d24m
So billion support staff indicating g.inp has regressed on the newer driver?
-
Pretty much. The 8800NL performance with a BCM cab/PCP would likely be improved with the newer firmware, however for us guys on ECI cabs/PCP's this old firmware does seem to produce less line errors...
-
Seems i am now G.INP enabled confirmed from plusnet 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
but it has had a negative effect rather than a positive one my ping has gone from 13-15ms to around 21-25ms and i have lost down speed my BTW IP profile has dropped from 46.8 to 42.55 so lost almost 4Mb not happy was hoping i would gain not loose, I'm using the Openreach ECI modem and wondering if that is the issue i don't remember at all of it updating firmware etc then again i have no way of knowing due to it being locked and i don't have the skills to unlock one either :(
I too have lost my g.inp on my 8800nl today. Sadly my monitoring pc was down as I was replacing the hard drive.
Lost sync rate on ds with delay and no g.inp.
I wonder what has caused this as it was fine until today..
Update spoke to billion - have sent a newer firmware to try on the 8800nl as seems to be an ongoing issue..unless bt have turned it off ??
a cryptic post on the plusnet forums from a staff member has said someone else had a openreach initiated DLM change to remove g.inp and he isnt sure when it will come back.
Looks like openreach may have temporarily suspended the rollout. I am hoping someone here may leak the truth,but as most people now are on g.inp it might not be big enough news to chase up.
I see no migrations since 31 march on MDWS.
I think what has not been helping matters, is those who got activated, panicing, quickly reporting faults and swapping out modems etc. openreach then in turn panic with flood of support requests and suspending rollout.
-
What actual problems has there been with G.INP on ECI other than the strange FEC errors on upstream?
Surely if there was a good reason to halt we'd have seen it ???
-
Some of us saw loss of ds sync rate when using non eci modems after g.inp was applied..my eci unlocked synced at 68 originally. The billion is now down to 57 with the loss of g.inp etc etc... dropped out at about 1.30pm
-
and of course you even had an engineer call out for it as well.
-
and of course you even had an engineer call out for it as well.
Yeap. Along with the hours spent testing different modems to see which worked best its back to square one again ???
Be interesting to see if other eci users start to lose g.inp if its been removed or maybe I am just unlucky...
Modem downgraded as advised so see what happens..
-
yeah so the answer to s.stephonson is a rise in support queries can be a big enough reason to put a halt to these things.
for a suspension tho I wouldnt expect them to be removing it from people, that would seem very harsh. But I have found other reports not just yourself of people losing g.inp on eci cabs, the pattern seems to be as a result of changing modems around mostly (but not always) with at least one of the modems been a eci chipset.
-
What actual problems has there been with G.INP on ECI other than the strange FEC errors on upstream?
Surely if there was a good reason to halt we'd have seen it ???
I've seen plenty of issues; loss of speed, loss of stability - just like when G.INP mk1 was rolled out.
-
What actual problems has there been with G.INP on ECI other than the strange FEC errors on upstream?
Surely if there was a good reason to halt we'd have seen it ???
I've seen plenty of issues; loss of speed, loss of stability - just like when G.INP mk1 was rolled out.
its going to be a micky take if they start rolling out this 3db g.inp profile whilst people are still waiting for them to unsuspend the g.inp rollout.
-
yeah so the answer to s.stephonson is a rise in support queries can be a big enough reason to put a halt to these things.
for a suspension tho I wouldnt expect them to be removing it from people, that would seem very harsh. But I have found other reports not just yourself of people losing g.inp on eci cabs, the pattern seems to be as a result of changing modems around mostly (but not always) with at least one of the modems been a eci chipset.
But from the tests I have done the ECI unlocked modem did give the highest sync on my line but I did not run it long enough for a long term test as missed having the stats so went back to billion. The billion lasted 10 days before g.inp was taken off.
-
What actual problems has there been with G.INP on ECI other than the strange FEC errors on upstream?
Surely if there was a good reason to halt we'd have seen it ???
I've seen plenty of issues; loss of speed, loss of stability - just like when G.INP mk1 was rolled out.
its going to be a micky take if they start rolling out this 3db g.inp profile whilst people are still waiting for them to unsuspend the g.inp rollout.
Who said it's suspended? There have been several ECIs this week
-
tony please check them, all had no previous data or long outage before the alert.
Have you seen any migrated ECI's this week which were running 24/7 before the alert?
-
Bob pullen on Plusnet forum has responded this is what he had to say
"To my knowledge, retransmission has been disabled from certain ECI lines it was recently enabled on. If you're one of those affected, it doesn't necessarily mean you were having problems.
If you did benefit from the change, then I'm fairly certain you'll see g.inp reapplied at some point".
I asked him why they did that and what about those where it had a negative effect he said
"Don't take my word for it, but probably an exercise in caution. Hopefully to sort issues like yours"
-
tony please check them, all had no previous data or long outage before the alert.
Have you seen any migrated ECI's this week which were running 24/7 before the alert?
Only just seen this and have posted elsewhere but I said:
==
Only one of those two [on Friday] (spotter) was ECI with G.INP and he was a NEW user so no previous stats - his last resync was 17 hours prior to first stats.
On Wednesday, xhemp registered for ECI and has G.INP but no previous stats. His last resync was 93 hours prior to registration.
But there were two new ECI/G.INP activations on Tuesday from existing users as posted elsewhere.
There are only 30 ECI users on MDWS at the moment, and only five of those don't yet have ECI with one currently deactivated (skyECI). Not sure those figures are a reliable basis for evaluating whether it has been delayed or stopped?
==
You can derive all this from the existing MDWS stats.
-
Called sky fibre pro support re losing g.inp again. No idea or information available.
-
A bit more info about what is going on about the suspension of g.inp on some lines.
http://forum.kitz.co.uk/index.php/topic,17446.0.html
-
How low can INP go?
I went from 49 on HG612 to 45 on ECi, and it has dropped to 44 on the ECi now.
-
How low can INP go?
I went from 49 on HG612 to 45 on ECi, and it has dropped to 44 on the ECi now.
Is lower better? Thanks
-
It should be better, maybe it explains the increase in sync on ECi Modems vs HG612 since G.INP rolled out.
-
I think that's down to the modem chipset matching the cab chipset and fastpath being the default profile.
-
Just wondered if there was any point in connecting up a spare eci modem I have just unlocked???
-
Just thought it might be of interest. Modem resync this morning, whilst g.inp appears not to have been re-applied I have had the delay and interleave removed and an increase in ds sync rate. Back to 12ms on the latency which is good.
Not sure how to explain that...
-
Explain what? You're on fastpath..
-
Ok cheers. Learning all the time ::)
-
It should be better, maybe it explains the increase in sync on ECi Modems vs HG612 since G.INP rolled out.
I have tried an unlocked ECI Modem and an unlocked HG612. Latency is the same but the HG612 achieves 18m download and the ECI 15/16M.
I am G.Inped
-
I had a reset last night about 1am, IP profile has risen back up to 46Mb and latency has dropped back down to it's normal 13-15ms It could well be that G.INP has been turned off on my line as Bob on the plusnet forum said was happening Or openreach already has a fix i dunno, I can't confirm if G.INP is off until tomorrow when the Plusnet staff are around to check.
-
hi Today my broadband resynced and I lost my upload stats on up snr and the down load power increased from 7.1 to 11.3 any ideas I also lost some sync speed. and my ping gone up from 21 to 28 ms
help needed please.
Training Status: Showtime
Down Up
SNR (dB): 5.1 0.0
Attn(dB): 28.0 0.0
Pwr(dBm): 11.3 7.2
VDSL2 framing
Bearer 0
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 6342 Kbps, Downstream rate = 28976 Kbps
Bearer: 0, Upstream rate = 6342 Kbps, Downstream rate = 23399 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): 5.2 0.0
Attn(dB): 28.0 0.0
Pwr(dBm): 11.3 7.2
VDSL2 framing
Bearer 0
MSGc: 22 33
B: 47 198
M: 1 1
T: 64 5
R: 16 16
S: 0.0652 0.9971
L: 7848 1725
D: 993 1
I: 64 215
N: 64 215
Counters
Bearer 0
OHF: 7879725 1003261
OHFErr: 5698 0
RS: 2017149751 3631363
RSCorr: 13283556 0
RSUnCorr: 810441 0
-
My mum's line dropped 13 hours ago and no longer has G.INP :-/
-
4 Days since my DLM reset and pair swap and still no G.inp and getting 1500-2000 ES errors per day without it...
-
4 Days since my DLM reset and pair swap and still no G.inp and getting 1500-2000 ES errors per day without it...
Join the club. No g.inp since 8th april :-\
-
Looks like 5 users now that had g.inp are showing as g.inp disabled. Creeping up slowly...
Edit. Make that 7 now..
-
G.INP also taken off my line this morning. Any ideas whats happening? Have BT found issues with the G.INP on ECI cabs or something?
-
As I have said I lost mine on the 8th april. It would appear the removal is gathering a bit of pace now after a lull. There do seem to be some issues so lets hope they sort it eventually.
-
There is two things going on.
The first is removal of g.inp on lines identified to be at risk of the problems. Unknown when these lines will get re enabled.
The second is some lines were never activated for testing purposes (my line is in this group) and in a few weeks these lines will get enabled.
-
mine never got it and has some major issue with syn speed and high laticey wish they enable my cab.
-
I also never got G.inp enabled on my cabinet. I hope it's going to get sorted soon.
-
I believe I still have G.INP on my line, I have a Sky Q hub so have no stats but on 30th March my latency went from 20ms to 12ms having been on 20ms for the whole 3 years I have had FTTC.
Also my line has been banded for 14 months and my sync changed from 59993 to 60000.
-
Another one has just lost it by the looks of it as total now at 8 being disabled. Was 7 earlier this morning...
-
There is two things going on.
The first is removal of g.inp on lines identified to be at risk of the problems. Unknown when these lines will get re enabled.
The second is some lines were never activated for testing purposes (my line is in this group) and in a few weeks these lines will get enabled.
You say people that haven't had G.INP enabled yet will get it in a couple of weeks. Can I ask where you got this information please?
-
Can I ask where you got this information please?
Me to as this could be valuable information for users on the Kitz Forum
-
I have repeatedly asked sky pro fibre team about g.inp re my line status and they told me they had be given no information about it.
-
There is two things going on.
The first is removal of g.inp on lines identified to be at risk of the problems. Unknown when these lines will get re enabled.
The second is some lines were never activated for testing purposes (my line is in this group) and in a few weeks these lines will get enabled.
You say people that haven't had G.INP enabled yet will get it in a couple of weeks. Can I ask where you got this information please?
From within BT, I cannot say the name sadly. If you want some more authenticity, kitz can back me up as I gave her the full info.
-
I can confirm that someone within BT has said that G.INP should be re-enabled within the next few weeks after completion of testing.
Chrys has tried to get permission to quote direct, but met the same stumbling block I sometimes have in that you sometimes get info, but cant quote direct or give a name. All I can do is say that the info he got certainly does look genuine and it comes from a reputable source.
-
When on fast path the well known DLM ES was/is a reliable guide to loosing fast path. The same figures did not seem to work for a return to fast path once interleaved. A much lower ES threshold seemed to apply for the reverse transition. Given the impact of interleaving this seemed reasonable although the apparent absence of a reliable guide figure for a return to fast path was annoying.
My question now is once a line has settled down from any DLM reset or initial imposition of G.INP, how big might downstream ES rates have to get with downstream G.INP applied, for something more aggressive to be imposed by the DLM? Might this be the old criteria or given that G.INP seems effective a stricter criteria.
Also what might the first imposed more aggressive action be? A imposition of interleaving or a speed cap? I find it hard to quickly answer the question from mydslwebstats but with some effort an answer might be guessed at. Looking at Hauwei DSLAM users perhaps a speed cap is first choice for more aggression. It is harder to say for ECI users at this time.
-
I've had g.inp removed from my line. I had no issues when it was active, no DLM instigated reboots and 2-0 es per day.
-
It would seem bizarre to take G.INP away from users not effected and introduce G.INP to others who never got G.INP the word for it is bonkers.
So they remove G.INP on all 206 firmware cabs then they unpause the rollout for 204 cabs they then downgrade the 206 firmware to 204 and then rollout the G.INP again
-
I have, for some time, had a peculiar "tingle in my whiskers".
It was that very same tingle that prompted me to type this post (http://forum.kitz.co.uk/index.php/topic,15283.msg318587.html#msg318587). I think I can now expand it a little and say --
"Discount any firmware update for ECI B-FOCuS /r modems but do not discount a firmware update or an operational configuration change for the ECI Hi-FOCuS M41 Mini-Shelf MSAMs."
Please also consider what Chrysalis has mentioned . . .
And, finally, remember that a watched pot never boils. :D
-
My cabinet is on 204 at the moment
-
Has it ever been 206?
-
No
-
That is the anomaly to all this forceware there are 204 & 206 not effected it all seems very weird and why I wish some of the guys in the know could give a we bit more info without naming names just put it into there own words what is happening
-
I've a sneeky suspion that they are removing from all lines. Unless someone else on my cabinet is having issues and they've removed it on all lines from the offending cabinet.
-
I don't understand how they can segregate one cabinet from another and know who is affected and who is not, the only way would be to remove G.INP from all ECI active users then apply the fix then roll it out again with all fingers crossed can this be done in two weeks I don't think so
-
I don't think so either, I feel the g.inp rollout mk1 and mk2 would give us a good idea of time scales. Maybe a bit shorter as there are less eci cabs.
-
Gezz no been there done it waited for 3 months for G.INP to come back on my line 2015, the way it worked during the G.INP halt was no removal of G.INP unless you had a DLM reset or changed ISP with a different DLM profile.
The change from MK1 to MK2 who still had G.INP applied to their line was seamless they just lost G.INP as standard on the upstream.
Now users are being forced off G.INP on ECI cabs and changed to fastpath with loads of errored seconds
-
More removals today.
It does indeed look like they are now removing across all lines. It all seems a bit messy and I'm seeing some lines which didn't have Interleaving & FEC prior to g.inp now ending up being interleaved and reduced line rate.
Im trying to get more info to find out whats going on, but Ive nothing to tell as yet.
-
Maybe if it gets bad enough they'll replace the ECI cabs with Huawei :lol:
-
Could it be that lines with Broadcom based modems, which would appear to suffer when compared with Lantiq ones, are having G.INP removed? This would, of course, mean all of the MDWS users.
-
Unlikely as BT don't have a clue what type of modem is connected.
-
So the DSLAM doesn't report the modem chipset, unlike the modem which does report the DSLAM chipset?
-
Unlikely as BT don't have a clue what type of modem is connected.
They see the modem's chipset IDs just as the modems see the DSLAM's.
-
My home line had G.inp removed at 11:32 with interleaving applied again :( on a better note my US increased slightly.
-
If they can see what's connected, how come the G.INP implementation was such an ordeal?
-
You'd need to ask Openreach.
Just because you have access to information doesn't mean you're using it or know all the results of it. The Huawei SNAFU was down to how the DSLAMs reacted hitting something not compatible with G.inp.
-
What about the ECI SNAFU?
-
They have seen the problem and are now using said information to backtrack the affected modems until a fix is in place.
-
So their testing failed to show any issues?
-
Wouldn't be the first time.
-
And it wasn't. It happened on the Huawei G.INP implementation and again on the ECI G.INP implementation. It's unbelievable that they can tell what modems are connected.
-
I still have g.inp but also have a severely banded line. Should I be expecting the worse?
Sent from my SM-T810 using Tapatalk
-
well yeah, when your testing involves not telling the customers they been tested and no way for them to report "directly" to the technical test team then yeah you wont have reported issues :D
Instead when they ring the isp they will be told by the rep who also doesnt know they on a trial to clear the cache etc. :)
-
More removals today.
It does indeed look like they are now removing across all lines. It all seems a bit messy and I'm seeing some lines which didn't have Interleaving & FEC prior to g.inp now ending up being interleaved and reduced line rate.
Im trying to get more info to find out whats going on, but Ive nothing to tell as yet.
Just happened to mine this morning.
I wasn't even aware I had been put on G.INP but today I noticed my latency had shot up and wondered what was going on. So looked back at my logs and noticed I had been on G.INP since 22nd March (resynced between 4-5am) and it was switched back off this morning, with my line now interleaved for the first time ever since getting VDSL with Zen.
I have never once had any stability issues (DLM has never even kicked in once until G.INP, I was starting to think Zen didn't even use DLM) and used to get 100Mbit on Digital Region with no interleaving before having to reduce to 80Mbit when moving over to BT, when they closed down.
I'm still synced at full speed with 9.8dB SNR down, 15.4dB SNR up, so pretty peed to have interleaving applied suddenly.
Max: Upstream rate = 31250 Kbps, Downstream rate = 97840 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79994 Kbps
I haven't noticed any performance problems during the time G.INP was enabled, if anything my speed seems to have been a bit more stable the last week or so.
-
so much mis information in this thread. bt says it will be rolled out for everyone else next week, bt says this, bt says that.
G.INP rollout on ECI cabinets has been cancelled again. since at least 19th April. not looking like ECI DSLAMs will ever get G.INP
http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html
-
Another 3 lines disabled overnight by the looks of it.
-
so much mis information in this thread. bt says it will be rolled out for everyone else next week, bt says this, bt says that.
G.INP rollout on ECI cabinets has been cancelled again. since at least 19th April. not looking like ECI DSLAMs will ever get G.INP
http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html
noone has said everyone will get it next week.
There is 2 sets of users.
1 - some who never got it at all (my line is in this group). My info was for this set of users
2 - some who got g.inp but have now been disabled. which is the group the ispreview article refers to.
However any decisions openreach make are subject to change so the information that was gained say 3-4 weeks ago may no longer be valid.
-
There was an Openreach briefing "NGA014/16 Performance of Retransmission on the ECI platform" dated 26 April 2016.
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga01416.do
No details available to ordinary end users like me.
-
No wouldn't we just like to get hold of that NGA01416.pdf file
-
Please don't let facts get in the way of a good troll attempt. ;)
so much mis information in this thread.
This thread is mostly end users reporting application of G.INP on their line and reporting stats so the results could be put into a spreadsheet to show losses and gains. A separate announcement about this was made here on the 18th of March (http://forum.kitz.co.uk/index.php/topic,17286.0.html)
bt says it will be rolled out for everyone else next week, bt says this, bt says that.
There's only been a total of 2 "BT says"
1) April 19th (http://forum.kitz.co.uk/index.php/topic,17447.0.html) When I notified suspension of G.INP roll out and the removal of G.INP from lines which may be affected. This information came from a very reputable source.
2) April 28th (http://forum.kitz.co.uk/index.php/topic,17195.msg321812.html#msg321812) when Chrys said the non activated group should get G.INP in a few weeks. He identified the info to me and it seems genuine.
G.INP rollout on ECI cabinets has been cancelled again. since at least 19th April. not looking like ECI DSLAMs will ever get G.INP
Please keep up! Practically everything said in that report originated from this site.
It would have been nice if where Mark said "was followed this month by rumours that Openreach had now partly suspended the G.INP ECI roll-out to problematic lines and removed the upgrade from those lines identified as likely to suffer from problems" was actually acknowledged as relating to information on this site dated 9th April from a reputable source.
Basically all that Mark had done was get it confirmed from his own source, the info he got is practically the same, just worded slightly differently and 10 days later.
Its only within the past few days that they have started a second and much larger batch of removals.
-
@ejs - me neither.
-
Another "BT says". ::)
http://forum.kitz.co.uk/index.php/topic,17682.0.html
-
I'm assuming the fact that openworld's boost engineers failing to obtain sync at the CPE with their own test equipment, if the line is on an ECI cabinet with G.INP enabled, also contributed to this G.INP removal decision.
My engineer had no idea why he could not obtain sync, I suggested it was because of the ECI G.INP issue, he had no idea, but was confused when my HG612 could sync up with no problems quickly.
I'm currently away from home, but hope to god that my line keeps G.INP, it's a fantastic addition to my line, enabling a few Mbit higher sync and the complete elimination of ES's on the downstream.
-
My engineer had no idea why he could not obtain sync,
Dont know to be honest, it could be the PPP issue as the reason why they are rolling back, but I wouldnt have thought they needed PPP.
The original reason why there was the delay rolling out to the ECI cabs from last year is that supposedly the problem was with the engineer equipment.
hope to god that my line keeps G.INP
From the info received today, its unlikely unless you have multicast services.
-
I wonder if j0hn (http://forum.kitz.co.uk/index.php?action=profile;u=7552) would care to introduce her/himself to us and if an employee (in any shape or form) of a BT Group plc company, quote her/his EIN? :-\
-
G.INP was removed from my ECI line just after 12pm.
That's despite having BT IPTV, I thought these lines were being spared the cull.
Stats recorded 30 Apr 2016 18:27:44
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6F039o1.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 6 hours 16 min 11 sec
Resyncs: 5 (since 27 Apr 2016 16:17:40)
Downstream Upstream
Line attenuation (dB): 31.2 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 21538 1578
SNR margin (dB): 6.0 6.1
Power (dBm): 11.9 6.9
Interleave depth: 913 1
INP: 8.00 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0461 0.0050
RSUnCorr/RS (%): 0.0003 0.0000
ES/hour: 1.08 0.65
:( :(
-
G.INP was removed from my ECI line just after 12pm.
That's despite having BT IPTV, I thought these lines were being spared the cull.
Clearly the policy has been changed as a result of further observations. It is beginning to appear that a total roll-back is in operation . . . which may not be a bad thing in the long term, for it will give a completely "level service" (for ECI equipped circuits) upon which the adjusted G.Inp implementation can then be built.
[Edited to change "log" to "long".]
-
Looking at it logical the adjustment is going to be made on the DLM side as G.INP seems to work fine, it's just a niggle but it must be the way the DLM assigns G.INP for each users line some are ok with it and others are not.
And it's good to see after the removal of ECI G.INP they don't go straight onto fastpath as this would make things worse interleaving is definitely the best way to start from.
-
Mine went from g.inp (8th april) to default for 2 days then went to fastpath and has been since 10th april approx.
Cheers
-
The way I see it the DLM was assigning G.INP to all lines even if the end-users modem did not support it the DLM should have had an contingency plans to disable G.INP and move them onto either Interleaving or Fastpath that is why I think the ECI DLM needs more configuration parameters added.
-
It may be a case of 3rd world coder syndrome
-
I wonder if they are just doing a blanket removal from all lines regardless then with a bit of luck roll out mk2 at some point soon...fingers crossed. I had a better sync on g.inp and less errors so hope to see it again at some point.
Have found since swapping to the zyxel the ds sync has been faster than the 8800nl plus less errors since g.inp was disabled so my line/cab seems to prefer the zyxel. Used both in bridge mode only.
-
But all VDSL2 modems are required to support downstream retransmission (G.INP) to comply with the mandatory requirements specified in BT SIN 498. And it's only downstream retransmission that was being enabled. There shouldn't be any devices which don't support downstream retransmission, so arguably they shouldn't have to support non-compliant devices.
Upstream retransmission is optional in SIN 498, which is why it is necessary for the DLM to be provided with data on if upstream retransmission is supported, and then only enable it if it is supported.
-
Upstream retransmission is optional in SIN 498, which is why it is necessary for the DLM to be provided with data on if upstream retransmission is supported, and then only enable it if it is supported.
It was incompatible modems that caused all the fuss last year on huawie cabinet upstream & downstream so why would the eci be any different
-
Mine went from g.inp (8th april) to default for 2 days then went to fastpath and has been since 10th april approx.
Cheers
That's good to hear, hopefully the same will happen to the rest of us.
-
G.INP was removed from my ECI line just after 12pm.
That's despite having BT IPTV, I thought these lines were being spared the cull.
Information is 'may not be rolled back' as these they feel are the lines which would benefit most from g.inp rather than interleaving.
That was based on a decision made last Tues and before they started phase 2 roll-back. Perhaps now that phase 2 is under way they have changed their minds and too many lines still affected. :shrug2:
Because it is obviously an earlier decision, I may remove it from the main article, but it is something to bear in mind if someone still has it applied.
-
I wonder if j0hn (http://forum.kitz.co.uk/index.php?action=profile;u=7552) would care to introduce her/himself to us and if an employee (in any shape or form) of a BT Group plc company, quote her/his EIN? :-\
Naw they're not anything BT. Just someone making a first post troll.
-
Naw they're not anything BT. Just someone making a first post troll.
Please feel free to kick that post into the far corner of my litter tray . . . ;)
-
It was incompatible modems that caused all the fuss last year on huawie cabinet upstream & downstream so why would the eci be any different
ejs is correct. Both the ECI modem and HH5A can support downstream g.inp only. There is only one possible HH5A that Ive seen that may not be compatible and that is Dray's because it still has old f/w on. Even then its not conclusive - without stats we are guessing.
The ECI cabs are only doing downstream ReTX.
2015 Mk2 g.inp removed upstream g.inp by default from the DLM during the Huawei cabs specifically to be compatible with the lantiq chip based modems.
-
I wonder if they are just doing a blanket removal from all lines regardless then with a bit of luck roll out mk2 at some point soon...fingers crossed. I had a better sync on g.inp and less errors so hope to see it again at some point.
The info is they are 'working hard with their vendor' (ECI) to find a permanent solution to re-enable retransmission.
That to me sounds like firmware. No idea if its for the cabs or modems though.
-
I bow down on my knees and plead forgiveness to the god ejs for my SIN 498 for i am not worthy to receive your blessings ;D
-
Naw... no need to get down on your knees.
If you're anything like me, since my accident last Nov and still healing.. then it would take too long to get back up again. :D
-
2015 Mk2 g.inp removed upstream g.inp by default from the DLM during the Huawei cabs specifically to be compatible with the lantiq chip based modems.
And seems that even if you have a compatible modem your line has to be absolutely abysmal to get it back.
-
Hi Guys
My G.inp (ECI Cab) was removed this morning. I have tried to fathom the thread, but not 100%. Do I gather its been rolled back. I have not gone back to Fastpath, but that also seems to be the case. My MDSLWS show how stable the line was with g.inp and a 10% increase in sync
Tony
-
Yes its being removed from some lines. Who knows when it might be back.
Some on default but mine went default to fastpath with a loss in ds sync
-
Thanks, reading further I suspect it wont be back >:(
-
I hope it will be back or something other than the present state as my line has gone from g.inp to higher interleaving with more es than it ever been
-
Well my G.INP went off yesterday morning so I've lost 5k on the down, interleaving (1047) is back on and pings to DNS have gone from 10 to 20. Not happy.
-
I wasn't interleaved when it went on. Not sure why I am now
Tony
-
G.Inp removed this morning.
Lost 2mb download and latency up by about 5ms.
-
Just an observation.
G.INP is not being rolled back in the same order that it was applied. In fact I cant see any pattern to it. There are some that were g.inp enabled before me and some after me, who have had the rollback and it seems rather random.
The only similarity is that both shadow4dog and jamesmayl got g.inp the same day, and both got removed the same day.
Yet that cant be relied on either: jeffers was g.inp'd the same day as me, yet his line was rolled back a few days ago.
-
I was first so I get to keep it forever :D
-
Some how that would be wishful thinking. That said it must be a total automated process. I doubt any BT Techs are working at 0830 bank holiday Sunday
-
Just had interleaving removed from my line, had two resync's within five minutes of each over though ???
This is from my resync log:
01/04/2016 18:04 - RESYNC detected (DS 51476 Kbps, US 7005 Kbps), AS = 20, Retrain Reason: 0, G.INP applied
03/04/2016 10:23 - RESYNC detected (DS 51272 Kbps, US 6888 Kbps), AS = 43, Retrain Reason: 0, turned off for over 30 minutes - update PN profile
10/04/2016 10:21 - RESYNC detected (DS 51857 Kbps, US 6732 Kbps), AS = 46, Retrain Reason: 0, Upgraded router to V14 firmware from Dutch site
23/04/2016 21:24 - RESYNC detected (DS 51506 Kbps, US 6414 Kbps), AS = 23, Retrain Reason: 0
29/04/2016 11:33 - RESYNC detected (DS 47077 Kbps, US 6888 Kbps), AS = 29, Retrain Reason: 0, G.INP removed :-(
01/05/2016 11:08 - RESYNC detected (DS 46922 Kbps, US 6785 Kbps), AS = 76, Retrain Reason: 0, Upgraded to official V14 firmware
01/05/2016 15:25 - RESYNC detected (DS 46741 Kbps, US 6601 Kbps), AS = 2, Retrain Reason: 0, accidently pulled the power plug out too much!
01/05/2016 16:03 - RESYNC detected (DS 49517 Kbps, US 6643 Kbps), AS = 54, Retrain Reason: 0
01/05/2016 16:08 - RESYNC detected (DS 49326 Kbps, US 6732 Kbps), AS = 5, Retrain Reason: 0
-
Historical data that the DLM might have perhaps ?
-
Retrain Reason: 0, Upgraded to official V14 firmware
Is this for the modem?
-
@forceware, it's a Zyxel VMG8324-B10A modem/router
-
Interesting Ronski that you have had G.INP removed but I still have it enabled on my line, coincidence or is it with TT customers they dont know if you have TV or not?
Stuart
-
Stuart, I still have G.INP at work in Sandwich, for now anyway.
-
No doubt others are monitoring disconnections but from just a couple of users a few days ago were up to 16 lines disabled now.
The thing I couldnt understand is why my disable was so early being the 8th april..
-
DLM has put me back on FASTPATH again this morning.
So I can confirm the previous reports that after having G.INP removed you get a couple of days of interleaving then restored back to normal.
-
Just had G.INP removed from my line and replaced with interleaving :(
-
You should have had the technician do a DLM reset which would have removed G.INP
-
Given Clayy's experience one could speculate that G.INP appears to be causing disconnections in certain situations - possible high error levels.
If this is correct, and speculating even further, if it turns out to be a fundamental Lantiq issue then it could perhaps be the end of G.INP on ECI.
-
I'd be inclined to try another modem
-
Well I have been on interleaved for 4 days now still not on fast path. G.inp was removed after a pair swap two weeks ago and DLM reset.
-
i'm sitting here hoping for G.INP to be removed as there's been issues since it was enabled (173 disconnections in the month its been turned on for)
thanks for this info, it gives insight into the nature of the faults.
-
G.INP has been removed from my line at 11:00 today. Don't have stats but my latency has increased by 8ms. Downstream sync only dropped from 60000 to 59993 as my line was already banded.
-
Wish they would take G.INP off my line, it's ruined my connection. Errors go through the roof periodically on the DS and I lose connection yet they stick Interleaving on the US that wasn't showing errors.
-
G.INP has now been removed on our work's line, but at least we didn't take too much of a hit a sync speed being on a 40Mbps package, but are once again interleaved, which we was prior to G.INP.
24/12/2015 09:08 - RESYNC detected (DS 39993 Kbps, US 6048 Kbps), AS = 42, Retrain Reason: 0, Unplugged UPS to change batteries
29/03/2016 09:31 - RESYNC detected (DS 40000 Kbps, US 6055 Kbps), AS = 41, Retrain Reason: 1, G.INP applied
03/05/2016 12:03 - RESYNC detected (DS 38623 Kbps, US 6105 Kbps), AS = 50, Retrain Reason: 1, G.INP removed
-
It seems I either had G.INP either enabled or disabled I can't tell due to the fact I use the BT Home Hub 5 Type A.
Here is my stats:
4. Board version: BT Hub 5A
5. DSL uptime: 0 days, 02:17:59
6. Data rate: 20000 / 80000
7. Maximum data rate: 33116 / 103325
8. Noise margin: 14.6 / 7.9
9. Line attenuation: 7.3 / 10.4
10. Signal attenuation: 7.2 / 10.4
At around 2-ish I had a resync occur. From the looks of it since I've got the full 80 download now and my latency is as low 5ms I can all but assume it's been enabled.
I'm probably wrong since I'm basing it off speculation.
My BRAS profile is now back at 77.44 Mbps instead of the 77.35 Mbps I was at for some time.
From the resync before the one today my download reported from the HH5 Type A was 799906 and before that it was always at 79995 until April.
So something has indeed happened to me but what exactly I'm not sure whatsoever. And a lot of the technical talk all goes over my head still but its sure satisfying learning all the ins and outs on the site. ::)
Mark.
-
Up to 20 lines now on mydslstats that have been disabled. Not many left to go..
-
Just been clobbered by G.INP removal. From 70122 sync to 57395 sync interleaved. >:(
-
Seems not every line goes back to Fastpath. I was on fastpath before g.inp applied now interleaved for 3 days since removal. Others seem to get back to fastpsth after 2 days.
-
I lost G.INP as well about 8 hours ago :no: Insert favourite curse here ____ >:(
Stats before (with G.INP):
System
Hostname OpenWrt
Model BT OpenReach VDSL ECI/r Modem
Firmware Version OpenWrt Chaos Calmer r46559 / LuCI Master (git-15.216.69575-bb7ea3e)
Kernel Version 3.18.19
Local Time Mon May 2 19:50:04 2016
Uptime 17d 16h 34m 7s
Load Average 0.13, 0.05, 0.05
xDSL Status
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 14d 15h 48m 30s — Resyncs: 2
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 68.662 Mb/s — 20.555 Mb/s
Actual Line Speed: 70.998 Mb/s — 18.999 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: OFF
G.INP: D: Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 32 — 255
Interleave Delay: 0.20 ms — 0.0 ms
INP: 43.0 — 0.0
NFEC: 32 — 255
RFEC: 16 — 16
LSYMB: 16 — 5134
LPATH: 0 — 0
Line Attenuation: 16.5 dB / 17.2 dB
Noise Margin/SNR: 5.5 dB / 6.0 dB
Transmit Power: 12.6 dBm / 6.0 dBm
Errors Since Line Up
FECS: 0 — 40315740
ES: 1420 — 69939
SES: 21 — 279
LOSS: 0 — 403
UAS: 77 — 77
HEC: 0 — 0
CRC_P: 344 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 0 — 0
FECS: 0 — 0
Errors in 1 Day
Code Violations: 141 — 110
FECS: 0 — 1708
Stats after (after G.INP got disabled):
Line Mode: G.993.2 (VDSL2) — Annex B — Profile 17a
Status & Uptime: UP — 8h 45m 34s — Resyncs: 3
Line State: showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream — Upstream
Attainable Line Speed: 67.702 Mb/s — 21.121 Mb/s
Actual Line Speed: 67.684 Mb/s — 18.999 Mb/s
Trellis: D: ON — U: ON
Bitswap: D: ON — U: ON
G.INP: D: Not Enabled — U: Not Enabled
Virtual Noise Support: D: Not Supported — U: Not Supported
Interleave Depth: 1 — 1
Interleave Block: 255 — 255
Interleave Delay: 0.0 ms — 0.0 ms
INP: 0.0 — 0.0
NFEC: 255 — 255
RFEC: 16 — 16
LSYMB: 18136 — 5134
LPATH: 0 — 0
Line Attenuation: 16.5 dB / 17.2 dB
Noise Margin/SNR: 6.0 dB / 6.6 dB
Transmit Power: 12.6 dBm / 6.3 dBm
Errors Since Line Up
FECS: 6901 — 419
ES: 1728 — 70060
SES: 23 — 279
LOSS: 3 — 403
UAS: 117 — 117
HEC: 0 — 0
CRC_P: 482 — 0
CRCP_P: 0 — 0
Errors in 15 Minutes
Code Violations: 3 — 0
FECS: 111 — 0
Errors in 1 Day
Code Violations: 530 — 123
FECS: 6901 — 1048
Good news is that I'm on fastpath by the looks of it and the drop is 'only' 70.998 Mb/s --> 67.684 Mb/s (so far).
Bad news is that the downstream FECS which have always been 0 with G.INP are now in the high thousands ... I hope that won't trigger interleaving and an even lower speed.
Story so far in case people might be interested:
- DSLAM/MSAN type: IFTN:0xb204 / v0xb204
- Before G.INP I used to have speeds in the region of 61.300 - 62.500 Mb/s for downstream, with downstream interleaving in the region of 700-1000 (for ECI/r modem). With an unlocked HG612, interleaving was previously in the region of 1200-1900 and speeds were similar.
- After G.INP was enabled I've been on 72.371 Mb/s with G.INP for about 14 days, on an OpenWRT ECI/r modem.
- I then did a resync to see what speed I'm getting with my unlocked HG612 and the result was highly disappointing, it synced at only just 66413 Mb/s with G.INP enabled.
- I went back to the ECI/r modem immediately and I have been on 70.998 Mb/s with G.INP ever since, for another 14 days that is...
- 8 hours ago G.INP was removed from my line and currently I'm on fastpath by the looks of it with a current speed of 67.684 Mb/s
DOH! >:(
It was good while it lasted ... I hope BT get things sorted out soon and we don't have to wait months and years to get G.INP re-enabled on ECI cabs again ...
-
Perhaps we should rename this thread
"I have G.INP no longer!!" :lol:
-
My line is still blessed with G.INP for now at least - hoping they forget about my cabinet!
-
Wishfull thinking :D your time will come
-
Perhaps we should rename this thread
"I have G.INP no longer!!" :lol:
The Lord Giveth and The Lord Taketh Away.
-
cathome, seems a new hybrid fast path mode where FEC is enabled without interleaving (same as upstream).
-
Perhaps we should rename this thread
"I have G.INP no longer!!" :lol:
I still do :P
For how long though :'(
-
Still active here as well.
-
Back to FastPath ;D
-
I eventually got back to Fastpath but now slower sync than it was before G.INP started.
Before G.INP I was syncing at about 68Mb with an ip profile of about 65Mb ish and now syncing at 66Mb with an IP profile of 60Mb. Plusnet tell me I'll be able to leave the contract if it goes below 58Mb! My download is at about 56Mb over a wired connection. I think probably if I disconnected the line for 35 minutes I'd get the correct profile but I think I should let my ISP sort this out for me. The faults only been open for 6 days.
Tim
-
I lost G.INP 18 hours ago. Stuck on a higher ping now thanks to interleaved on the downstream :(. I wonder if ECI will ever get G.INP, as it was working fine on my line.
-
I saw a drop in ds sync after g.inp was removed. I have tied various re-syncs just to see if the ds sync would go back up but it does not. The best I had on g.inp was 68mb for my line. Now sits on 62 with fast path.
-
I lost G.INP 18 hours ago. Stuck on a higher ping now thanks to interleaved on the downstream :(. I wonder if ECI will ever get G.INP, as it was working fine on my line.
Yes - I am in much the same boat.
TBH it makes little difference to me as we use the line for general web browsing and film streaming.
But it would be nice to have it back.
-
Any insider info as to when G.INP may me enabled on ECI lines?
I do miss this feature especially with VOIP calls.
-
Agreed it did nothing but good for my online gaming.
-
Meh - bye bye G.INP :(
Lost 4mbps downstream, my ping has almost doubled and by tomorrow I'll probably be banded once the DS CRC's start rolling in when it gets dark. My stats before and after are on MDWS for anyone interested.
Presumably BT will simply leave the hundreds of ECI cabinets as they are now - it obviously costs them too much money in manhours to rollout new technologies to sub standard cabinets.
-
I too had no issues with G.INP on my line, though it wasn't too bad before I had G.INP applied, just a little noisy.
Just had my resync that stuck me back on fastpath so I'm guessing my graphs will be plastered with downstream errors again :(
-
Well just over 3 days since G.INP was removed and Interleaving applied I'm back on FastPath as of 4pm today. Strange time I thought?
Still from my G.INP days I'm down 5k on max and about 3k on actual and ping seems to be around 12ms instead of 10 but it is teatime I suppose.
-
Maybe ECI will do a swap for some V41s :-\
Should be fixable though its not like everyone has had problems.
-
Having spent an entire career applying logical thought in a problem solving role, trying to understand what is going on here has me beaten.
Before G.INP I had almost 4 years of fastpath connection with 70 to 80 error seconds per day. The broadcom based HG612 gave a consistently higher sync than anything Lantiq based, by about 3 Mb or so.
G.INP is rolled out and the HG612 takes a 3Mb hit, whilst Lantiq based kit does the opposite. Still on fastpath, but now zero error seconds. So I switch from having the HG612 in front of the Draytek to using the VDSL connection on the Draytek itself. Net result is more or less same speed but lose the 70 to 80 error secs - so really no difference either way.
Now I see all these reports of people with high error rates losing G.INP that has greatly improved their connection, whilst G.INP remains steadfastly active on my line when really it isn't doing much at all.
Go figure!
-
My type B HH5 just rebooted today and it looks like DLM has capped my speed to 65Mbs but my maximum download speed has gone from 71Mbs to 78Mbs and my lines has never been that high with a broadcom chipset :o
-
Having spent an entire career applying logical thought in a problem solving role, trying to understand what is going on here has me beaten.
Before G.INP I had almost 4 years of fastpath connection with 70 to 80 error seconds per day. The broadcom based HG612 gave a consistently higher sync than anything Lantiq based, by about 3 Mb or so.
G.INP is rolled out and the HG612 takes a 3Mb hit, whilst Lantiq based kit does the opposite. Still on fastpath, but now zero error seconds. So I switch from having the HG612 in front of the Draytek to using the VDSL connection on the Draytek itself. Net result is more or less same speed but lose the 70 to 80 error secs - so really no difference either way.
Now I see all these reports of people with high error rates losing G.INP that has greatly improved their connection, whilst G.INP remains steadfastly active on my line when really it isn't doing much at all.
Go figure!
I presume your on a Huawei cabinet, or you'd have lost G.INP too recently. This thread is related to the ECI cabinet G.INP rollout - which has been troublesome to say the least. The Huawei rollout is complete and there are no problems with it, hence your line gets to keep it.
-
Nope - if you check back you will see I am very much on an ECI cab!!
-
DLM took action and lowered my INP so it still seems functional for me.
When I got the e-mail I was expecting it to have gone.
-
Just warming you up for the main event to come! :P
-
Having spent an entire career applying logical thought in a problem solving role, trying to understand what is going on here has me beaten.
Before G.INP I had almost 4 years of fastpath connection with 70 to 80 error seconds per day. The broadcom based HG612 gave a consistently higher sync than anything Lantiq based, by about 3 Mb or so.
G.INP is rolled out and the HG612 takes a 3Mb hit, whilst Lantiq based kit does the opposite. Still on fastpath, but now zero error seconds. So I switch from having the HG612 in front of the Draytek to using the VDSL connection on the Draytek itself. Net result is more or less same speed but lose the 70 to 80 error secs - so really no difference either way.
Now I see all these reports of people with high error rates losing G.INP that has greatly improved their connection, whilst G.INP remains steadfastly active on my line when really it isn't doing much at all.
Go figure!
Well, talk about tempting fate! Just had resync and G.INP gone. Left me with interleaving; Attainable 52700; Actual 46353.
So a loss of 6Mb compared to pre G.INP. Words fail me!
-
Lol... that's class - sorry to hear of your loss ;)
-
Well, talk about tempting fate! Just had resync and G.INP gone. Left me with interleaving; Attainable 52700; Actual 46353.
So a loss of 6Mb compared to pre G.INP. Words fail me!
We shoud start a support group thread, for those left with significantly worse connections after the G.INP removal :lol:
-
;) Never doubted for one minute it would get implemented.
Indeed. Apart from the above post back in early March I notice B.S. has been unusually quiet lately!
-
seems to look like me never been activated is a blessing in disguise.
-
Chrysalis I think your line would have enjoyed it without any issues at all, going to call the next ECI G.INP rollout MK4 as MK1/2 was on huawie's MK3 was the first rollout of G.INP to ECI cabinets so G.INP MK4 sounds right :)
-
Chrysalis I think your line would have enjoyed it without any issues at all, going to call the next ECI G.INP rollout MK4 as MK1/2 was on huawie's MK3 was the first rollout of G.INP to ECI cabinets so G.INP MK4 sounds right :)
I think it's far more likely BT will abandon G.INP on ECI cabinets- it's obviously more hassle for them than it's worth. It can't be cheap trying to diagnose these lingering issues with the vendor, having hundreds of support calls and having to commit the manhours to rollout then remove G.INP.
-
Having spent an entire career applying logical thought in a problem solving role, trying to understand what is going on here has me beaten.
Before G.INP I had almost 4 years of fastpath connection with 70 to 80 error seconds per day. The broadcom based HG612 gave a consistently higher sync than anything Lantiq based, by about 3 Mb or so.
G.INP is rolled out and the HG612 takes a 3Mb hit, whilst Lantiq based kit does the opposite. Still on fastpath, but now zero error seconds. So I switch from having the HG612 in front of the Draytek to using the VDSL connection on the Draytek itself. Net result is more or less same speed but lose the 70 to 80 error secs - so really no difference either way.
Now I see all these reports of people with high error rates losing G.INP that has greatly improved their connection, whilst G.INP remains steadfastly active on my line when really it isn't doing much at all.
Go figure!
Indeed go figure. Given the problems with the roll out last year I fondly thought OR would do better with this. Oh well see what they come up with next.
-
Just been reading this thread with interest. I'm on an ECI cabinet with 206 firmware and using an HG612 - still have G.INP (for the moment).
I'm not particularly looking forward to losing it - it's been very effective on my line. No resyncs since it was applied on the 18th March, increased DS sync, 9ms to my ISP and hardly any ES.
-
I think it's far more likely BT will abandon G.INP on ECI cabinets- it's obviously more hassle for them than it's worth.
If they have invested time and money into getting G.INP to work on ECI cabinets they won't just pull the plug on this, It looks like a cabinet firmware upgrade is needed across the whole ECI network (DLM) again there must be like hundreds of thousand of VDSL2 modems out there that can't even handle G.INP on the downstream correctly.
So if a VDSL2 modem cannot work with G.INP on the downstream then it needs a fallback scenario be it interleaving and then onto fastpath while compatible modems will get G.INP.
This is just my own theoretically input into whats going own ;)
-
Lets hope they fix eci cabinets!! ::) ::)
http://www.telegraph.co.uk/business/2016/05/05/bt-to-plug-6bn-in-superfast-broadband-and-mobile-as-it-unveils-p/
-
It is all very disappointing and I feel for any who may be left with interleaving after things has settled down. I was interleaved for 5-6 days after interleaving was removed. Now back to fastpath after a resync at about 3pm yesterday. :fingers: It may be a coincidence put there were two engineers around the CAB at roughly that time. After 3 days with interleaving the line had a never seen before event with 10 secs of LOM and many SES, this looked more than enough to fix interleaving in place but I am glad to say that it seems to have not have had that effect.
The loss of speed is not an issue for me, I don't like interleaving but I can't tell the difference between say 40 and 70 Mb/s except via speed test. I guess that if I had a sync less than 30 I might not be so insensitive to speed.
-
Quick favour as I have to go out. This is so that someone else can perhaps pick up the info.
IF you previously had G.INP on an ECI cab then it was removed AND you are still what appears to be on open profile, but your line needs Interleaving can you put your stats below.
I know there was a couple of you early on in the thread which had this problem, but not sure if DLM has now sorted it for you.
Also is there anyone still stuck with Interleaving... who wasn't interleaved before G.INP and whose line doesn't need it.
-
I'd say both my lines are back to normal, works line was always interleaved, home often used to be interleaved for long periods then fast path for periods.
-
I thought I read in one of these G.INP/ECI threads that the roll-back should be completed by the 4th May. However my line still has G.INP active, been up now 37 days straight, still with high upstream FECs though all day. Probably now I've said that it will be removed today >:(
Stuart
-
Quick favour as I have to go out. This is so that someone else can perhaps pick up the info.
IF you previously had G.INP on an ECI cab then it was removed AND you are still what appears to be on open profile, but your line needs Interleaving can you put your stats below.
I know there was a couple of you early on in the thread which had this problem, but not sure if DLM has now sorted it for you.
Also is there anyone still stuck with Interleaving... who wasn't interleaved before G.INP and whose line doesn't need it.
I have a HG612 and an ECI Cabinet, G.INP was removed a couple of days ago. Interleaving now applied on my line and don't need it. Think only ever been interleaved about 18 months ago before as had some power issues in the area.
-
G.INP removed yesterday, interleaving applied for the first time ever.
Attainable 52464 Actual 46353. Loss of over 6Mb compared to pre-G.INP
-
last week g.inp was turned off, went from 73999 back down to 69540, no errors at all and it was rapid :(
-
No problems whatsoever with G.INP on my ECI cabinet and Fritz!Box 7490. Rolled back late yesterday evening with the loss of Fast Path and with 8ms downstream latency. Re-sync at 79995/20000 (pre G.INP settings) at 8.03 am this morning. Fast path etc restored. I lost about 5 Mbps on my max attainable rate following yesterday's rollback.
-
@kitz I see they got round to your connection. Welcome to to the disappointment!!
-
Poor Kitz! I don't think I have ever seen a line that syncs at 75979 with interleaving applied ::)
-
Seems still a few last men standing on MDSLWS on ECI
My line is back to pre g.inp in terms of sync/es .
I did note when I did have g.inp, a increase in US ES, not much but enough to notice
Tony
-
If they take mine I'm going to the exchange ;D
-
pfttttt.. Just got in. In over 13yrs of adsl Ive only been interleaved once, and that was because of a line fault.
PFTTTTT.. I have some sort of weird capping going on too. Just tried a resync to see if I could pick up some more speed, but its not going for a straight 6dB target SNRm.
-
It looks normal for interleaving but I would not worry for while yet. Most lines seem to got back to fastpath after anything from 1-6 days. I would not start to worry till next Friday.
-
I did note when I did have g.inp, a increase in US ES, not much but enough to notice
Yes, same here - it was rare to have more than 1 or 2 a day pre-G.INP but now I have 2 or 3 an hour.
-
@les-70.
Yep just sitting on it for a few days, nothing I can do. It's following the normal path of DLM reset for g.inp lines.
Seems a bit odd that even a resync doesnt go for a straight target SNRm of 6dB though.
-
for what its worth I never get 6.0db on a resync, its always around 6.3-6.5. Your snrm is within that range.
-
I'm still stuck with g.inp, but with the default snr of 6dB I can no longer hold a stable connection for more than several hours. Only by setting my router to use 8dB snr on the DS can I get any stability.
You would have thought with the lessons learned last year we wouldn't see a repeat 'screw up' by BT, but once again they make themselves look completely inept.
-
Simon I think you have some sort of line fault going on rather than G.INP being the culprit once G.INP is removed and you still have issues call your ISP asap
-
An engineer is already booked for Wed next week, if g.inp drops off in between I'll soon know. My line problem started around the time g.inp was enabled, bit of a coincidence.
-
It is a bit of coincidence you should have posted on the Kitz forum with your issues when G.INP was applied to your line
-
nasty FEC spike today for kitz, lets hope FEC has no bearing on if DLM decides to move to fast path.
-
The SES burst on kitz's line may be more relevant to the DLM, but I had such a burst a day or two after loosing G.INP and although I expected a DLM response the response was to fastpath a few days later. Seems odd to get SES with not a single ES but I had had much the same before and have learnt to check SES.
-
earlier I had a 1 CRC on my US with 0 ES O_o
-
Only by setting my router to use 8dB snr on the DS can I get any stability.
Hmmm... why is that ringing some bells with me. Someone else had to artificially cap their line but I cant recall when & where. :hmm:
Capping line to get a lower sync speed is similar to increasing the SNRm. Different methods but same end result.
-
nasty FEC spike today for kitz, lets hope FEC has no bearing on if DLM decides to move to fast path.
No idea what that was about, not been in most of the day so not noticed it. Although saying that it was bang on 8am, so I was still in then.. but not using anything.
The SES burst on kitz's line may be more relevant to the DLM, but I had such a burst a day or two after loosing G.INP and although I expected a DLM response the response was to fastpath a few days later. Seems odd to get SES with not a single ES but I had had much the same before and have learnt to check SES.
Just checked my stats and I dont have any SES recorded.
Then I checked the time of those SES from yesterday and it was about the time that DLM removed g.inp from my line.
-
An engineer is already booked for Wed next week, if g.inp drops off in between I'll soon know. My line problem started around the time g.inp was enabled, bit of a coincidence.
Simon what modem are you using?
-
@kitz Your correct of course re the SES, either incompetence or your extra resync made me think it was during the interleaving period.
-
nasty FEC spike today for kitz, lets hope FEC has no bearing on if DLM decides to move to fast path.
No idea what that was about, not been in most of the day so not noticed it. Although saying that it was bang on 8am, so I was still in then.. but not using anything.
Same huge ~25k spike this morning too. ???
-
Seen as I'm the outrider and not updated the firmware to be G.INP enabled yet. I too noticed quite a few SES's today (11). Which is unusual as I never normally get them, whether on fastpath or interleaving.
-
G.INP got taken off my line this morning and the sync rate has gone from 78 to 67 :( It was up for 31 days with zero issues so unsure why it was removed.
-
It's being removed from all ECI cabinets
-
Awesome they giveth and they taketh away!
Sent from my iPhone using Tapatalk
-
It's being removed from all ECI cabinets
Source and when will it be enabled again? I miss it dearly. :lol:
-
Just to say that a few minutes ago I also had G.INP removed. Like others, I'm now interleaved with associated decrease in DS sync and 8ms increased latency.
It remains to be seen whether DLM will move me to fastpath. It should, as I was moving between green and amber on the MDWS traffic lights on fastpath prior to G.INP.
-
Source and when will it be enabled again? I miss it dearly. :lol:
Source http://forum.kitz.co.uk/index.php/topic,17682.0.html
Who said it will be re-enabled?
-
Saw a post somewhere on this forum, I think it was one of Kitz' insider sources.
Admin - Removed nesting.
-
Was that Chrys's post here (http://forum.kitz.co.uk/index.php/topic,17195.msg321648.html#msg321648)?
Info from my source(s).
~ Apr 9th - Suspension for some cabs (http://forum.kitz.co.uk/index.php/topic,17447.0.html)
~ Apr 30th - Roll back for all cabs (http://forum.kitz.co.uk/index.php/topic,17682.0.html).
~ May 6th - Mini update re error spikes & PPP issues (http://forum.kitz.co.uk/index.php/topic,17682.msg322775.html#msg322775).
Nothing Ive been given indicates total abandonment, nor a date when it will go back on.
They say they are 'working with their vendors' to find a permanent fix and an update expected later this month.
-
my line got chaotic today, even with my long spell on fast path, it shows how vulnerable everyone is without g.inp.
-
my line got chaotic today, even with my long spell on fast path, it shows how vulnerable everyone is without g.inp.
I suspect this was down to thunderstorms was tracking 3 cells moving north, even with G.INP these still get through with mad CRCS
-
Was that Chrys's post here (http://forum.kitz.co.uk/index.php/topic,17195.msg321648.html#msg321648)?
Info from my source(s).
~ Apr 9th - Suspension for some cabs (http://forum.kitz.co.uk/index.php/topic,17447.0.html)
~ Apr 30th - Roll back for all cabs (http://forum.kitz.co.uk/index.php/topic,17682.0.html).
~ May 6th - Mini update re error spikes & PPP issues (http://forum.kitz.co.uk/index.php/topic,17682.msg322775.html#msg322775).
Nothing Ive been given indicates total abandonment, nor a date when it will go back on.
They say they are 'working with their vendors' to find a permanent fix and an update expected later this month.
Yes that was it. Cheers darling. :lol:
-
at the time I got that information the rollback wasn't on every cabinet for every user. Clearly the situation has now changed.
-
Only 3 users left now with g.inp on mydslwebstats. S.step still hanging in there by a thread ;)
-
They will never take my precious :D
-
:lol:
-
Yup, add me to the list of people who have had it removed :-(
Sent with Tapatalk (the crap Windows Phone Version!)
-
Only 3 users left now with g.inp on mydslwebstats. S.step still hanging in there by a thread ;)
Well I must be one of those 3 as mine is still enabled as of this morning.....
Stuart
-
You are. I was trying to figure out how your ds snrm is only 3.5 yet you have a sync of 70mb...
-
It has been like that for ages. Initially the snrm was higher but has dropped over time but the line has been up 39 days now with no drop out or re-sync.
Stuart
-
We are obviously the chosen ones Broadstairs :cool:
I hate getting e-mails now I always expect it to be a g.inp was disabled one :'(
-
But what's odd is your two lines come from the same cabinet, yet one of them has G.INP
-
One was turned off by a DLM reset rather than the removal of G.INP
-
How much can I pay to have G.INP re-enabled?
-
How much would it cost to move to a house served by a Huawei cabinet?
-
Do any of you still with G.INP have TV services. As of Friday, Openreach appeared to think that multicast lines wouldn't have retransmission disabled yet. Yet Im sure someone last week with BT TV said they'd had it removed.
-
@S.Stephenson. I cant recall, but which of your lines got g.inp first, and which of them still has it.
iirc, your line got G.INP before the date Openreach state as the main roll out. :hmm:
-
Only one ever had g.inp. 2nd line was enabled on the 19th March.
The line with G.INP has BT TV, at this point I'm thinking G.INP was rolled out early for people with BT TV and they don't plan on turning it off at the moment.
Note that my 2nd line is Plusnet and wasn't activated until G.INP was halted, hence it never had G.INP.
So unfortunately we can't be certain that it's because of TV services unless someone without TV services has had G.INP disabled on Cabinet 19 Hemsworth.
-
So you can add BT TV for £49
https://www.productsandservices.bt.com/products/add-tv
-
Do any of you still with G.INP have TV services. As of Friday, Openreach appeared to think that multicast lines wouldn't have retransmission disabled yet. Yet Im sure someone last week with BT TV said they'd had it removed.
Yes I have BT TV and g.inp was removed from my ECI line on 30th April.
While I had g.inp it was excellent, lost around 3 Mbps with it's removal.
Broadcom router VMG8924-B10A
-
How much would it cost to move to a house served by a Huawei cabinet?
How much do I have to pay to take part in the G.fast trial? :fingers: :lol:
-
Do any of you still with G.INP have TV services. As of Friday, Openreach appeared to think that multicast lines wouldn't have retransmission disabled yet. Yet Im sure someone last week with BT TV said they'd had it removed.
Yes I have BT TV and g.inp was removed from my ECI line on 30th April.
While I had g.inp it was excellent, lost around 3 Mbps with it's removal.
Broadcom router VMG8924-B10A
Are you on mydslwebstats?
-
@S.Stephenson - thanks for that info, I couldn't recall without looking back through the thread.
Your line is behaving as expected, from what Im hearing Openreach is supposed to be doing re IPTV.. yet its odd that npr's isnt.
I removed the info about multicast from the news statement because I knew someone had said they'd had it removed.. yet just 2 days ago they were still saying they hadn't yet made the decision to remove it from multicast lines.
atm Im taking it with a pinch of salt.. but they were expecting to have finished removal from all lines bar multicast by this weekend.
---
ETA
... and there goes Broadstairs g.inp.
-
2 to go... will s.step be the last one I wonder... :D
-
mine was removed today. Maximum Data Rate went from 82Mbs to 72Mbs and interleaving was taken off
-
So if my G.INP survives today do I get to keep it forever?
-
Yes you win, unless you get rid of BT TV of course.
-
Someone has lost G.INP who had TV though?
-
2 of you still in the running at the moment ;D
-
I'm the Leicester City of G.INP.
Hopefully though BT is that peed off at ECI that they make them make it work on the upstream too.
-
Mine was removed yesterday, and replaced with interleaving :(
I've reset my 8dB snr to default 6dB and it's holding steady, whereas before it was dropping connection every few hours.
-
Mine went 5 hours ago lost 10000kbps in speed after 40 days of running with no problems (apart from crazy upstream FECs) at least none which caused any issues. I've also been interleaved which I dont think was necessary. Not a happy bunny.... I know it wont do any good but I have reported this to TT as an unacceptable speed drop and enforced interleaving with no obvious cause for this to happen on my line. (Just made me feel better having a rant over there!)
Stuart
-
nasty FEC spike today for kitz, lets hope FEC has no bearing on if DLM decides to move to fast path.
Despite getting the high FEC spikes every morning (~25K), the DLM wasn't concerned by them and has put me back on to Interleaving off.
As expected it takes 2-3 days for DLM to catch up. Would rather it was set back to open profile.. but we have known for nearly a year that Openreach said Interleaving ON is the new default for g.inped lines :/
-
How can lines be interleaved but without increased latency? I can see some poeple on mydslwebstats who have Interleaving depth of 16 and 0ms of delay. G.INP enabled of course.
-
With my thread on the TT forum about my G.INP loss I had a reply from one of their 'volunteers' on the TT forum trying to excuse TT from any responsibility for this. Now I know the situation in all this, however I have asked for this to be escalated to their CEOs office and asked what TT are going to be doing about this situation and to provide a timescale for rectification. Now I also know the likelihood of seeing answers to this are in the realm of finding rocking horse droppings but I do like to wind up people some times ;) ::)
Stuart
-
So you want TT to give Openreach a good talking to?
-
I know one ISP that will be doing ;)
-
So you want TT to give Openreach a good talking to?
You could say that ;) ;) however I know I am p***ing in the wind here - I just like to wind them up as much as possible :cool:
Stuart
-
@kitz Your correct of course re the SES, either incompetence or your extra resync made me think it was during the interleaving period.
@les.
FYI I again had a small burst of SES just before DLM removed interleaving, so your theory of "The SES burst on kitz's line may be more relevant to the DLM," is probably correct for both occasions.
-
Slightly off topic as it's not G.INP related, but interleaving has finally been removed on my line, and looks like Kitz has too, my SNR has shot up to 7.8 also, so either openreach have fixed my line as a fault was logged, or they doing work on the ECI cabs? No idea as I've not been updated on any fix my end as of yet.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29183 Kbps, Downstream rate = 85452 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 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): 7.8 12.3
Attn(dB): 13.5 0.0
Pwr(dBm): 13.8 2.5
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0955 0.3771
L: 20104 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 52970349 607497
OHFErr: 182 0
RS: 0 1534513
RSCorr: 0 28
RSUnCorr: 0 0
Bearer 0
HEC: 584 0
OCD: 12 0
LCD: 12 0
Total Cells: 584655984 0
Data Cells: 220864058 0
Drop Cells: 0
Bit Errors: 0 0
ES: 194 26
SES: 32 0
UAS: 146 114
AS: 87608
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 6.15
OR: 116.09 202.87
AgR: 80103.09 20203.27
Bitswap: 21929/21929 22/22
Total time = 1 days 23 hours 32 min 13 sec
FEC: 0 28
CRC: 182 0
ES: 194 26
SES: 32 0
UAS: 146 114
LOS: 3 0
LOF: 26 0
LOM: 0 0
Latest 15 minutes time = 2 min 13 sec
FEC: 0 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: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 32 min 13 sec
FEC: 0 28
CRC: 171 0
ES: 135 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 11 0
ES: 19 2
SES: 10 0
UAS: 37 27
LOS: 1 0
LOF: 9 0
LOM: 0 0
Since Link time = 1 days 20 min 7 sec
FEC: 0 28
CRC: 182 0
ES: 144 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Getting a few ES but hopefully it won't effect anything
-
or they doing work on the ECI cabs?
G.INP rollback on ECI cabs was estimated to be complete by the weekend just gone. It leaves lines with Interleave for a couple of days then if the line is ok, removes it.
-
For the love of god Openreach just leave it off on ECI cabs, its been more trouble than its worth.
-
Please OR, we need G.fast! :fingers:
-
Unless your less than 400m from the cabinet I wouldn't expect G.Fast till after 2020.
-
Unless your less than 400m from the cabinet I wouldn't expect G.Fast till after 2020.
Aren't OR deploying G.fast from the distribution point?
-
How can lines be interleaved but without increased latency? I can see some poeple on mydslwebstats who have Interleaving depth of 16 and 0ms of delay. G.INP enabled of course.
Because interleaving can be configured with many different settings. The softest ones tend to be put in place in parallel with retransmission being activated - where you see depths of 4, 8 or 16. The harshest ones have depths of over 1000.
The delay associated with interleaving comes from it working on a 2-dimensional array of data (with both a width and a depth), so the delay amount is in proporotion to (depth x width) [or (depth x blocksize)] ... the softest settings have a delay of around 0.2ms, while the harshest ones tend to be 8 or 16ms.
-
Unless your less than 400m from the cabinet I wouldn't expect G.Fast till after 2020.
Aren't OR deploying G.fast from the distribution point?
Your guess is as good as anyone's.
Research into G.Fast started life with the expectation it would only be viable at the DP, and has been designed and standardised with that in mind. However, it turns out that the copper has worked better than expected, and longer distances can be used while still allowing for a decent speed upgrade. BT have been asking for improvements to the standards and the chipsets to allow for deployment further away from homes than "just" the DPU; my current belief/expectation/guess is that distances up to approx 300-350m will be the maximum.
That has given OR some relief (they can deploy fewer G.fast nodes, so it will be cheaper), but a conundrum too - where do they choose to put the node now?
So one of the aims of the current G.Fast trials is to find out what speeds happen in reality, and what distances. That will let Openreach plan a deployment.
Until they figure the answers out, we won't know a blessed thing. Once they figure it out, we still won't know - we'll have to guess from watching where they activate nodes.
But...
While they are figuring that answer out, we can speculate a little.
It will almost always be true that they'll have to locate one G.Fast node where the PCP/FTTC node is - to support the premises close to that cabinet. There is already fibre, already power, and already a set of premises. A no-brainer.
Extending that thought process though, we can see that if BT put a G.Fast node at every PCP/FTTC site, and aimed at 300m reach, then they would likely be able to offer service to about 30% of lines in the country - by this: http://postimg.org/image/bp372fcnn/
By coincidence, 30% of lines in the country is BT's target for G.Fast by 2020. Edit: But the coincidence might just be that - and they're planning a different 30% entirely, targetting specific areas.
If they did that, and only that, then they'd only end up offering the 300Mbps service to people who could already get 80Mbps - politically, lots of people would be up in arms at this choice. And it might not get the best takeup.
It's all speculation, until we see what Openreach end up doing.
-
I would probably go further than WWWombat in speculating that by 2020 you will see g.fast in the local loop (not just cabinet locations) for areas that are considered economically viable and/or have cable - with little to no g.fast in BDUK areas.
-
I think its logical they will take the low hanging fruit first, so just deployed at cabinets or next to cabinets. I have speculated this for months, although I kept been shot down as the trials are not working this way.
I think the people in the worst position is where they over 300m but they only a few per cabinet over 300m, I am by coincidence in this category, my engineer told me only 48 lines out of about 600 are over 300m from the cabinet and i am one of them. Is it worth BT deploying a node for less than 50 people?
On the plus side crosstalk will ease off on g.fast rollout as people move over and I am happy with vdsl2 speeds. So its not a major issue for me at this time.
This will also be a factor on any business decision on vectoring for vdsl, because as people move from vdsl2 to g.fast then crosstalk on vdsl2 naturally will go down, there wont be crosstalk from g.fast users with the power cut back.
-
At this rate I reckon we'll see 100% FTTP coverage by 2030. :lol: :fingers:
-
Just a quick update on my thread with TT. One of their OCEs ran a line test and said its fine BTOR will not accept this as a fault so basically they are doing nothing. I have pushed for escalation to the CEOs office but I dont really expect to win that one but my thread is getting quite a few views so at least it is causing some interest.
I have only found one other recent thread on the TT community about loss of G.INP but they just commented and no one seemed to follow up on it.
Stuart
-
On g.fast I am sure I heard BT announce they had chosen their initial chipset vendor (but did not say who) the other day.
If it's Broadcom based, their newer chipsets support both VDSL and g.fast
-
Openreach have also said they will be adding about 2800 extra cabinets (network re-arrangements), to improve speeds and coverage, started in February 2016, to finish in 2020/21. Presumably some people will be furious that all they got was a closer FTTC cabinet, while others were getting G.fast.
-
I have speculated this for months, although I kept been shot down as the trials are not working this way.
I tend to agree the trial isn't a good indicator yet - Openreach need to use the trial to figure out answers to lots of questions, which needs a variety of deployments that won't always be optimal. The shape of the pilot might tell us more.
I think the people in the worst position is where they over 300m but they only a few per cabinet over 300m, I am by coincidence in this category, my engineer told me only 48 lines out of about 600 are over 300m from the cabinet and i am one of them. Is it worth BT deploying a node for less than 50 people?
It might be, if they're all the same direction away from the cabinet - which does happen for some of the cabs here in my town.
In circumstances like yours, a single node might not have the capacity for demand from 550 lines ... so splitting at 200m might make sense. In fact, I could see an argument for choosing the range by dividing the total by 2 or 3, rather than rigidly setting range to 300m.
On the plus side crosstalk will ease off on g.fast rollout as people move over and I am happy with vdsl2 speeds. So its not a major issue for me at this time.
This will also be a factor on any business decision on vectoring for vdsl, because as people move from vdsl2 to g.fast then crosstalk on vdsl2 naturally will go down, there wont be crosstalk from g.fast users with the power cut back.
I do wonder what the demand will be like for Openreach ultrafast products.
That 2014 Ofcom graph told us that about 10% of VM's customers chose the top-tier (120-150Mbps at the time), and another 27% chose the middle tier (100Mbps, or being increased to that level). The 2015 results for VM tell us that 40% were taking the middle or top tiers (100Mbps and 200Mbps, by that time).
If BT find there is only demand from 10% of properties for their ultrafast offering, I don't think we'll see much decrease in crosstalk.
-
yeah all 48 are bunched together, the coverage from the cabinet is like a U shape rather than O. I am right at the edge of the U, next to the next cabinet.
g.fast will likely be dominated by warez downloaders and people who want to brag I expect. vdsl2 is fast enough for mainstream.
But then again who knows what marketing can pull off, people can get brainwashed to think they need 100mbps+.
-
Please OR, we need G.fast! :fingers:
Do you really think they can pull it off after all the problems with g.inp?
Wishful thinking!
-
yeah all 48 are bunched together, the coverage from the cabinet is like a U shape rather than O. I am right at the edge of the U, next to the next cabinet.
g.fast will likely be dominated by warez downloaders and people who want to brag I expect. vdsl2 is fast enough for mainstream.
But then again who knows what marketing can pull off, people can get brainwashed to think they need 100mbps+.
You can have a gigabit service but if the source of your download is capped for QOS its pointless.
-
Just to say that a few minutes ago I also had G.INP removed. Like others, I'm now interleaved with associated decrease in DS sync and 8ms increased latency.
It remains to be seen whether DLM will move me to fastpath. It should, as I was moving between green and amber on the MDWS traffic lights on fastpath prior to G.INP.
Also like others, just had another resync and now I'm back on fastpath.
-
yeah all 48 are bunched together, the coverage from the cabinet is like a U shape rather than O. I am right at the edge of the U, next to the next cabinet.
g.fast will likely be dominated by warez downloaders and people who want to brag I expect. vdsl2 is fast enough for mainstream.
But then again who knows what marketing can pull off, people can get brainwashed to think they need 100mbps+.
You can have a gigabit service but if the source of your download is capped for QOS its pointless.
Pretty sure people were saying similar things 10 years ago "what's the point in 10Mbit when you can't download from one source at that speed" - I'd encourage you to look outside the box, there is great demand for reliable high bandwidth services in this day and age. Each year only increases the digital divide.
-
No different to the chap I had on 2 occaisions. He knew nothing of g.inp the 1st and said on the 2nd still knew nothing more about it bar it had been rolled out but as an engineer fixing fibre he had not been given any advice or technical info about g.inp..
-
If it was cross-talk then the DLM reset wouldn't have cured it and given your speed back.
-
User wj66 has appeared on mydslstats with g.inp enabled. Looks like it was already enabled as the uploads are only on 26%
-
But he's also only got an uptime of 7 hours and 9 minutes, so the big question is did they have g.inp prior to the resync?
-
He has got some older data but its too old, shame we cant mail him and ask ;D
-
He has got some older data but its too old, shame we cant mail him and ask ;D
Hi skyeci and Ronski
Just comparing the HG612 modem against my Vigor 130 that had g.inp enabled on the 23 March, Vigor sync speed was 51 down and 17 up both the up and down on fast path. will leave HG612 connected for a few days to see how it goes. The Vigor has better sync speed possibly down to the type of chip but unable to download to MyDslWebstats.
Wj66 John
-
Ah ok. Thanks for taking the time to post. I hope you dont lose it as 3 of you remain enabled...
-
For the love of god Openreach just leave it off on ECI cabs, its been more trouble than its worth.
I don't think the people who gained 10Mbit from G.INP will agree with you there.
-
So anyone hazard a guess why even though the rollback was supposed to be completed by the end of last weekend we still have 3 enabled users-seems a bit odd ?
Thanks
-
Shush now - don't tempt fate as mine is still hanging in there (ayeaye on MDWS)!
Although, I didn't see any speed increase that others have done so I wouldn't be too bothered if it was removed and then fastpath came back after a couple of days of interleaving.
-
Those remaining may have multi-cast (IPTV) services from their ISP.
-
Those remaining may have multi-cast (IPTV) services from their ISP.
Yeah I've got BT TV - but I thought that people who had IPTV had seen G.INP removed as well so possibly no consistency there?
-
Thats what I thought too..
-
Those remaining may have multi-cast (IPTV) services from their ISP.
Yes I also have BT TV
-
If I signed up to BT TV would I get G.INP?
-
If I signed up to BT TV would I get G.INP?
Who know's try it?
-
Yeah, well volunteered mate ;)
-
If you go for the starter package its a 12 month contract, and the only cost is a £10 activation fee, then £4 after the 12 months. Not sure if this is just for new customers though.
https://www.productsandservices.bt.com/products/tv-packages
-
If I signed up to BT TV would I get G.INP?
Who know's try it?
I have BT TV am on an ECI cabinet and lost G.IMP about 2 weeks ago.
It was active on my line for 2 weeks and caused no end of problems.
My line was stable beforehand at approx. 46mb down / 5mb up on low level interleaving and would stay connected for months at a time.
G.INP brought it down to 32mb down / 3mb up with high level interleaving when G.INP was removed from the line.
Whether it was the BT rollback that removed it or DLM that would be anyone's guess.
After 10 days of the line being in sync and DLM making no attempt to recover the line to its previous speed I logged a fault with BT.
After the UK support team ran their tests they informed me it reported a "DSL and BRAS profile mismatch"
An Openreach engineer was booked for a couple of days later who did some line tests and performed a DLM reset.
Line been up now 7 days on Fastpath (Hooray) although I dont expect it to last as it connected too fast IMO at the moment.
ATU-R Information
Type: VDSL2
Hardware: Annex A
Firmware: 05-07-06-0D-01-07
Power Mngt Mode: DSL_G997_PMS_L0
Line State: SHOWTIME
Running Mode: 17A
Vendor ID: b5004946 544e0000
ATU-C Information
Vendor ID: b5004946 544eb204 [IFTN]
Line Statistics
Downstream Upstream
Actual Rate 50103 Kbps 4638 Kbps
Attainable Rate 49435 Kbps 4783 Kbps
Path Mode Fast Fast
Interleave Depth 1 1
Actual PSD 0. 2 dB 12. 3 dB
Near End Far End
Trellis ON ON
Bitswap ON ON
ReTx 0 0
SNR Margin 5 dB 6 dB
Attenuation 22 dB 30 dB
Cheers.
-
I have a short quiet line and a DSL-AC68U. Synced 80/20 fastpath/fastpath I had DSL up times counted in months and daily CRC errors counted in tens.
About 22nd March something happened (almost certainly the ECI cabinet G.INP update) and I had a 64/20 interleave/interleave sync. About 10 days later it resynced at 78/20 interleave/fastpath (and tweaking stability (SNR margin) on the router I could make that 80/20 interleave/fastpath).
I still have an interleaved downstream. Apparently the ECI G.INP implementation doesn't work with the DSL-AC68U and the cabinet decides it should be punished with a permanent +1 level of DLM regardless of the line being almost perfect. I also have a TP-Link TD-W9980 which will sync 80/20 fastpath/fastpath.
This garbage G.INP implementation should have been rolled back by now? If it has it seems to have been rolled back to something different. Is there some way of telling if G.INP is active on a TD-W9980?
-
This garbage G.INP implementation should have been rolled back by now?
It's hardly garbage, it worked wonders on my two and many others compatible routers!
-
I lost G.Inp about a week ago - was on interleaving DS but just been set to no interleaving.
Still not so good as G.Inp though.
-
You don't get to call it garbage if you use incompatible hardware that's 100% your fault.
Update the firmware or get the right hardware would be my advice.
-
You don't get to call it garbage if you use incompatible hardware that's 100% your fault.
Update the firmware or get the right hardware would be my advice.
I have not seen any complaint about G.INP and the DSL-AC68U on huawei cabinets so the hardware at which end is incompatible? If it wasn't a garbage implementation on ECI cabinets they wouldn't be pulling it would they and it isn't being pulled just for Asus modems.
I don't need or care about G.INP there is no excuse for making my connection worse with or without it. I want the connection I had on the 20th March back.
-
Well in regards to G.INP being active on your line i'd imagine its disabled atm unless you have IPTV.
-
Well in regards to G.INP being active on your line i'd imagine its disabled atm unless you have IPTV.
I don't have IPTV so I would expect G.INP to be disabled or rolled back or whatever by now yet the cabinet is still forcing downstream interleave on the DSL-AC68U. I haven't tried the TP-Link modem recently.
-
When G.INP was knocked off some people got interleaving it should probably go away on its own withing a week.
-
Well in regards to G.INP being active on your line i'd imagine its disabled atm unless you have IPTV.
IPTV (BT TV) & ECI Cabinet = G.INP Disabled on my line ???
-
Just a bit concerned that all lines will see a stable fasthpath once G.INP is removed some lines may have to many errored seconds to remain on fastpath and the DLM will send them back to interleaving.
Once G.INP is removed it goes into interleaving then to fastpath if the errored seconds counts have gone above 2880 Speed and 1440 Standard profile the DLM may introduce interleaving
That was always the case even before G.INP
-
My works line stayed interleaved (it always has been generally), my home line did go on to fast path but is back interleaved, which it often used to be.
-
Once G.INP is removed it goes into interleaving then to fastpath if the errored seconds counts have gone above 2880 Speed and 1440 Standard profile the DLM may introduce interleaving
Hey there,
Are those the errored seconds values per 24hr DLM period?
Where did you get those values from?
Cheers
-
I get 400-600 ds es per 24 hour.still on fast path
-
I currently have 2 US and 2 DS CRC errors in 65 hours of up time. The session before had 1 US CRC error in 101 hours which is why I am not impressed with this ECI G.INP fiasco forcing at least downstream interleave on my connection for 8 weeks and counting.
-
DLM uses MTBE (http://www.kitz.co.uk/adsl/DLM.htm#DLM_categorising_the_line) to calculate acceptable errors.
So if you are on speed profile and have a full days uptime
MTBE red = 86400/30 = 2880
MTBE green = 86400/300 = 288
Anything in between is amber and considered OK.
-
DLM uses MTBE (http://www.kitz.co.uk/adsl/DLM.htm#DLM_categorising_the_line) to calculate acceptable errors.
So if you are on speed profile and have a full days uptime
MTBE red = 86400/30 = 2880
MTBE green = 86400/300 = 288
Anything in between is amber and considered OK.
Do we know for sure that DLM uses a 24 hour period and doesn't look at the number of ES/SES over smaller intervals, too? I had a big spike this morning (268 ES between 9 and 10am) and one SES. No resync, though. My MTBE is 106s over 24 hours.
-
I think its 24 hours, last week when I had that very nasty 2-3 hour spell, I was way over the MTBE threshold during that short period but over 24 hours I was ok.
-
I think its 24 hours, last week when I had that very nasty 2-3 hour spell, I was way over the MTBE threshold during that short period but over 24 hours I was ok.
Thanks - I guess I'll find out soon enough :)
-
It's a bit frustrating they decided to remove it from *ALL* ECI lines, at my parents' they gained about 6meg with it on, and now it's been removed they've lost about 8meg from it (I suspect extra noise since it last resynced)
-
Well thats not strictly correct as 3 users on mydslstats still have g.inp on eci lines. The reason why it remains on these lines does not appear to be totally clear.
Fingers crossed they may sort it, hopefully not abandon it..
-
Openreach are under the impression that the only lines with g.inp remaining are those with multicast.
That was just last last week and supposedly they still havent made a final decision for removal from multicast lines.
The multicast info was originally included in the original statement made 30th April (http://forum.kitz.co.uk/index.php/topic,17682.0.html). However I removed the IPTV info as npr had said despite him having BT-TV, g.inp had been rolled back for him and therefore assumed that had made a decision.
If your line has been reset indications are that it wont come back on... and therefore I doubt purchasing BT-TV would now cause it to kick back in again.
-
btw. Has anyone else notice that since they've rolled back it takes ages to get re-connected and get a new PPP session.
I was fine before.. this has only started tonight... but then again tonight is the first time Ive had to resync since g.inp was rolled back plus I cant recall having to do a manual resync since g.inp was enabled.
-
The BT Wholesale ISP Forum document (from 12th May) has a little to say about the subject of Retransmission on ECI:
- Openreach were removing retransmission on ECI
- The decision affects 260k lines
- Does not include multicast; decision due on those lines on 13th May
- The reason given: "we are experiencing a much higher than average fault rate for these lines"
- "Openreach working with its supplier"
- If I read it correctly, one item that BTW fed back to BTOR was: "ECI retransmission - why wasn’t it trialled more thoroughly?"
260,000 lines doesn't seem like a lot. Either there are a lot using multicast, or the rollout hadn't gone very far.
To check, I looked back at the cabinet composition data we got in Autumn 2014, as part of the application for unmetered power supplies. That data provided a snapshot for 34,000 cabinets (out of perhaps 55,000 that were installed at the time), of which 15,000 cabinets were ECI ones. The breakdown of ports in use suggested there were perhaps 750k lines on those 15,000 ECI cabinets at the time.
I would guess there has to be over a million lines in use now - even if most of the rollout since then has been Huawei.
-
@wombat
That info sounds like it may be old - its basically what I reported on the 30th of April (http://forum.kitz.co.uk/index.php/topic,17682.0.html) and before they made the decision to roll back on all lines except multicast.
The reason I removed the multi-cast info on May 1st (http://forum.kitz.co.uk/index.php/topic,17682.msg322392.html#msg322392) was that npr who had BT-TV said that he had been rolled back, so I assumed that Openreach had already made the decision (which from the info I got ) was due by mid-May. However it does appear that those few remaining MDWS lines still on ECI G.INP do have IPTV services.
-
any idea why ECI multicast CP are exempt from the removal of G.INP
-
the reason given was something along the lines of multicast lines benefit most from retransmission rather than traditional methods of error protection such as interleaving.
-
The reason I removed the multi-cast info on May 1st (http://forum.kitz.co.uk/index.php/topic,17682.msg322392.html#msg322392) was that npr who had BT-TV said that he had been rolled back,
WildBill also reported G.INP being disabled while having BT TV.
http://forum.kitz.co.uk/index.php/topic,17195.msg323406.html#msg323406
Anyone fancy my chances of getting it reinstated?
Or even BT support knowing what G.INP is. ???
-
Sky fibre pro certainly do not.....having spoken to them for some time over the last month (lost g.inp on the 8th april) they appear to be no wiser to what it even is..
-
Looks like WildBills was removed due to the engineer resetting DLM. In the case of resets it doesn't look like it will be re-applied, which is why I said the other day, that I dont think ordering of BT-TV will get it re-instated.
I had a thought about yours, but atm I have very limited internet access and cant google anything (plus I expect to be kicked off soon), but I was wondering about their stress of multicast rather than TV services. From memory there is something about minimum speeds for multicast services and which products you can get on it. Do you have any of the umm extra services or HD etc. Also from memory your sync speed is lower than average.. just throwing ideas around re multicast/unicast until this connection fails.
-
just throwing ideas around re multicast/unicast until this connection fails.
Your connection has gone skew whiff that needs a serious looking into we complain about losing 5 -10 Mbps but at least we can connect to the Internet.
-
Aye, I'm prepared to believe the BTW information was somewhat out of date, especially with regard to multicast TV. However, it does help confirm that this status was true at some recent point.
I hadn't seen information on scale before.
-
Hi Kitz,
No I don't have any extra services, just basic BT sports TV at SD.
Sync speeds are not great due to aluminium in the line, after g.inp has been removed I'm getting around 21Mbps down and 1.7 Mbps up which should be fine for SD multicast tv.
-
Hi guys im new here and have become interested in G.inp and have noticed its not enabled on my line. I am connected to an ECI cab and was wondering if there is any chance of it being enabled.
-
Hi
Probably not at the moment it would seem due to it mainly being removed/disabled over the last month apart from some of those who have bt tv services and still have it.
What modem/router are you using etc?
-
Hi
Probably not at the moment it would seem due to it mainly being removed/disabled over the last month apart from some of those who have bt tv services and still have it.
What modem/router are you using etc?
Thanx for the speedy reply :), I have a Huawei 612 running HW cfw B030SP08, also connected to that a Asus RT-AC66U with Merlin Firmware, my ISP is Sky Fibre 40/10. Below are some stats:
Stats recorded 19 May 2016 20:18:51
DSLAM/MSAN type: IFTN:0xb206 / v0xb206
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 8 min 45 sec
Resyncs: 0 (since 19 May 2016 19:34:48)
Downstream Upstream
Line attenuation (dB): 23.0 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 30000 9995
SNR margin (dB): 6.3 6.3
Power (dBm): 6.4 6.3
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0001 0.0008
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 7.59 0
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 10534 Kbps, Downstream rate = 30348 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 30000 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.2 6.3
Attn(dB): 23.0 0.0
Pwr(dBm): 6.4 6.3
VDSL2 framing
Bearer 0
MSGc: 26 219
B: 247 235
M: 1 1
T: 60 7
R: 6 16
S: 0.2629 0.7508
L: 7728 2717
D: 1 1
I: 254 255
N: 254 255
Counters
Bearer 0
OHF: 1011742 338733
OHFErr: 8 0
RS: 60689387 4156150
RSCorr: 35 4
RSUnCorr: 20 0
Bearer 0
HEC: 21 0
OCD: 1 0
LCD: 1 0
Total Cells: 231020587 0
Data Cells: 156178 0
Drop Cells: 0
Bit Errors: 0 0
ES: 8 0
SES: 0 0
UAS: 25 25
AS: 4007
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.95 11.87
OR: 64.65 151.62
AgR: 30064.35 10146.45
Bitswap: 2952/2952 8/8
Total time = 1 hours 7 min 12 sec
FEC: 35 4
CRC: 8 0
ES: 8 0
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 7 min 12 sec
FEC: 6 0
CRC: 3 0
ES: 3 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: 7 4
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 7 min 12 sec
FEC: 35 4
CRC: 8 0
ES: 8 0
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 hours 6 min 45 sec
FEC: 35 4
CRC: 8 0
ES: 8 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Like you being on sky I have tried to get information from them but they know nothing about g.inp.
Its unclear at the moment wether we will get it back and even if it does get sorted we dont know how long this will take..
Are you uploading to mydslstats?
Cheers
-
Like you being on sky I have tried to get information from them but they know nothing about g.inp.
Its unclear at the moment wether we will get it back and even if it does get sorted we dont know how long this will take..
Are you uploading to mydslstats?
Cheers
No, how do i do that.
-
From the discussions I have had with TalkTalk it seems unlikely that any ISP was informed about G.INP by BTOR, and I believe they only found out when end users who are knowledgeable about it have complained. BTOR are a law unto themselves in my view as they own the connection from the end users house to the exchange and dont see why they should tell ISPs about any changes they make even if said ISPs end up fielding complaints. I dont believe BTOR will make any information available to ISPs about any past or future changes to what they own, be it Vectoring or G.FAST, we will all be left in the dark as will ISPs until such time as BTOR deem fit to tell anyone anything.
In my view another reason why something needs to be done about BTOR, there is not enough control or accountability while they are part of BT, I believe they need to be accountable to all ISPs not just the BT group. As it stands ISPs have no influence over BTOR.
Stuart
-
They wouldn't if they split. Same result, but with no investment ............ we've been here many times before.
-
No, how do i do that.
If you have a pc or pi you can run hg612 stats or dsl stats and upload real time to mydslstats.co.uk
Plenty of info in the monitoring section on
Kitz. Unlocked 612 will work from port2
http://www.kitz.co.uk/routers/hg612stats.htm
http://www.kitz.co.uk/routers/hg612stats_setup.htm
https://www.mydslwebstats.co.uk/
-
@broadstairs
There were briefings about the problem:
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga01416.do
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga01616.do
And these things from the ISP forum event: http://forum.kitz.co.uk/index.php/topic,17806.0.html
For things like G.INP and Vectoring, Openreach shouldn't really need to tell anyone that they are going to enable it, because the modems are already required to support downstream retransmission, and vectoring, and are supposed to have passed the testing which includes testing those features. I doubt that they'd be many people praising Openreach if switching on retransmission had gone smoothly, but it didn't, so everyone's complaining.
-
The thing that doesnt make sense is "or" say they are communicating with their customers about the network changes but when I ask their customer about it they havent got a clue. Why is the information not filtering down to the engineers on support etc.. have spoken with sky pro fibre team many times but they really dont know what g.inp is...perhaps sky for example is not passing down the info internally properly...
-
isp's are either using plausible deniability (instructing reps to pretend there is no knowledge of said bodged rollout). Or simply only higher level technical staff were ever made aware, so anyone on tech support hasnt a clue.
I did ask revk whether he told his customer's if they were on a OR trial, and he said yes. So at least AAISP do things right.
-
Does the fact that you guys who have 'Jail-breaked' or by-passed this security mean that you would otherwise be in the dark as to the various trials OR are conducting with regard to Vect and INP, had you left the software as is ??
If the answer is 'Yes' ....... then as far as I'm concerned you have no rights at all to demand answers of OR.
There are plenty of modems available which give stats without being "jail-breaked"
-
Yeap. Zyxel, billion to name a couple
-
There are plenty of modems available which give stats without being "jail-breaked"
Thank you Dray, that's what I was querying.
-
No I don't have any extra services, just basic BT sports TV at SD.
Sync speeds are not great due to aluminium in the line, after g.inp has been removed I'm getting around 21Mbps down and 1.7 Mbps up which should be fine for SD multicast tv.
Thanks. I do seem to remember reading something a while back about multicast and HD and other services (btw I didnt mean pr0n) - I just couldn't remember the term that they used for the additional channel package. For some reason a figure of something like 28-30Mbps was stuck in my head about provision of service and I cant recall what it was. The connection I was trying to make is I wondered if because your service was <30Mbps and because you dont have one of the premium HD packages, I was wondering about 'multicast'. Openreach said multicast not IPTV. Anyway it was just a niggling doubt about why yours could have been removed.
-
Gosh there seems to have been quite a bit going on the past 3 days whilst I didn't have a connection.
---
I can confirm that the ISPs definitely were advised by BT. The information given to me was practically the same info that was given out to the ISPs. I'm seeing quite a bit of it these days where certain ISPs are denying knowledge of certain information when the truth is that its not being filtered down to those at the ISP who interface with the EU's.
Didn't I also see a moan from a certain 'LLU ISP' fairly recently moaning about BTretail using the 55Mbps product and implying that it was BT favouritism?
We are being misled by certain sectors, because we damn well know that BT very openly made info available from last year that a new 55/10 product was being made available. I can guarantee you that those same ISPs will have had the same info I had and probably even a bit more.
It is the ISP's who are not filtering this info on to the EU's and this is something that I had a fairly long convo with Ian Lawrence about last year and possible ways it could be filtered out to the EU by other means. I said last year that the G.INP info filtered via this forum was being monitored by BT for reactions, but all that happened was a pile of negative comments about BT and the thread was filled with one line comments about how crap BT were. If you look there is a post by me made several months ago saying that they were monitoring how info passed to '3rd parties' was received. To be quite frank if all it does is generate moans, then can you blame them if they shut the stable door. I know for a fact there are/were 3 sites they were considering sharing more info with. However, that opportunity has now passed and the person involved has moved on.
---
As regards to the ECI issues, I can see both sides of this. Openreach have and always will use at least 2 different suppliers for hardware. Its only these days because we can physically see the cabs that we are perhaps more aware of it. But situations like this have happened many times in the past. Right back to pre Openreach.. I can recall Cisco kit in exchanges having a problems way back in 2003 when the Junipers where fine. Theres the Marconi MSANs that had problems with the increased upstream for maxdsl and lots more no doubt that I cant think of right now.
I can understand the customer frustrations and I do believe that g.inp wasn't tested as well as it should have been. I myself have offered services of forum members last year for testing purposes. The problem Openreach have with that is that we are not their customers - its the SPs. For example the 3dB trial, that was down to the ISPs who trialled it. Think again we have proof that Openreach have tried in the past to directly communicate with the EU's, but it was certain 'LLU ISPs' who put the block on that.
---
Re 'hacked' routers.
Nothing to do with it.. there are plenty of MCT and Openreach approved modems that do give info. I myself use an Openreach MCT modem router and would have become aware of what was going on with G.INP etc on my line. Once upon a time all modem/routers provided this sort of info.
One of the first ISPs to start the lock-downs was Sky, soon after followed by BTr with the HH. I know for a fact BT didnt like certain modems because some users were tweaking SNR without really understanding what they were doing and putting their line into a worse state. Even today on these forums I see people panic because their SNRm moves by 'x' amount or become fixated on attenuation.
Line stats are a fantastic diagnostic and with line stats monitoring many times in the past we've been able to point people with genuine line faults in the right direction.
What happens though is some people get hold of info and demand something fixed which is within normal range.. I'm not talking about Openreach here, I'm talking about DSL is genuinely expected to perform within standards across the board and that certain variations are to be expected. Years ago, fluctuations of up to 6dB was considered as not unusual. ADSL was designed to cope with these sorts of fluctuations and its why such things as Interleaving, FEC and G.INP were invented. Myself I would be a bit concerned about 6dB.. but 3dB is considered within the realms of normal... but you have to look at the bigger picture - not all lines behave the same... and longer lines are always going to be more susceptible.
So line stats are good, as long as used sensibly.
-
I've split the off-topic comments concerning BT and Openreach in general into a separate discussion. http://forum.kitz.co.uk/index.php/topic,17822.0.html
-
thanks eric for saying, I wondered where my post went :)
-
Today I was recabling my network kit and as part of this I reinstated my HG612 modem. Immediately after resuming my uploads to MDWS I received an email:
"Just to let you know that G.INP is now disabled for your line."
I'm on a Huawei cabinet so am puzzled as to how/why I have lost G.INP?
-
Ignore the above, my stupidity!! :-[ :blush:
Had a new line installed yeswsterday and despite my meticulous labelling still managed to code the wrong modem address in DSLStasts.
Sorry.
-
It's now more than 10 days since I lost G.INP and DLM has not yet removed interleaving from my line despite my stats being pretty goos. Is there anything I can get TT to do to make it happen?
It does seem unreasonable for it not to have happened by now.
Stuart
-
I can only think of one at that is to find away to get the DLM reset into an open profile,you have less than 5 ES per day on the downstream with interleaving so with fastpath you may see no more than 200 per day
And having seen how long it takes your line to go from interleaving to fastpath you need some form of DLM intervention to take place.
-
It's now more than 10 days since I lost G.INP and DLM has not yet removed interleaving from my line despite my stats being pretty goos. Is there anything I can get TT to do to make it happen?
It does seem unreasonable for it not to have happened by now.
Stuart
After G.INP was removed from my line (BT TV & ECI Cabinet) either by DLM or OR roll back my profile become stuck at a lower speed and a high level of interleaving.
After 10 days or so and DLM making no attempt to speed things back up to pre G.INP state I logged a fault with BT.
I managed to speak to the UK BT Digital Care team (who were excellent) and after they ran some tests they reported a BRAS / DSL profile mismatch.
An engineer visit was booked and the OR engineer performed a DLM reset after doing some line tests.
Since the engineer left my connection been up for 15 days now on fastpath (other than 1 x DLM change in the early hours to speed things up slightly).
During the 2 week period I had G.INP enabled on my line it would re-sync several times per day and not hold a stable connection.
Since the DLM reset my line been very stable and on fastpath which is unusual (Always had low level interleaving) in the past.
Just chase your ISP for an engineer IMO.. GL :)
-
Unfortunately we just has about 200+ ES in the past 2 hours due to some thunderstorms nearby which I'm hoping will get ignored. I'll leave it another couple of days and then see if TT will do anything. G.INP was great for me 40+ days with 71000kbps sync and no drop outs or significant errors.
Stuart
-
It go's to show how good G.INP is we also had 6 cells of T/Storms today from 2pm to 6pm a dozen of those was a cloud to ground strike 3 miles from me, the max errored second count reached 27 if I was interleaved it would have reached 870 and on fastpath I would looking at 4000+ errored seconds
-
so g.inp does work against lightning then :)
-
Apparently Openreach have issued a third briefing to CPs about ECI's retransmission:
NGA017/16 Update on Performance of Retransmission on the ECI platform (https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga01716.do)
-
If only we knew it says..anyone have access?
-
If only we knew it says..anyone have access?
Hopefully someone will have access and can summarise whether it is good or bad news. Kitz or BlackSheep may be able to help let's cross fingers and hope there is some news soon.
-
I'm afraid that all I know is that there was an update due last week about g.inp and multicast on the ECI platform and whether they were going to leave it on or take it off multi-cast lines.
The people who have access to that page are ISPs... ie the likes of Sky and TT who say they dont get info about whats going on with G.INP ::)
There was a meeting last week at BT towers for the SP reps where they could discuss such things but the info that came out of that (see wombats post) didn't really provide anything that we didnt already know... and it was still at the 'we are working with ECI to find a fix'.
I don't like harassing my contacts too often.. and I think (hope) one of them would give me a nod if there was anything new of great importance such as them having them found a permanent fix.
--
ETA
Im guessing that it may just be an update to say all lines bar multicast have now been rolled back and whether they have decided to leave it on or not for those lines.
-
Just for info regarding the HH 5A G.INP support debate, I have just completed a migration from Plusnet to BT. Although I have no intention of using the supplied HH5 I have just had a look at it out of curiosity and I am a little surprised that it is a brand new HH 5A with firmware 4.7.5.1.83.8.204 (Type A).
It would appear that this firmware rolled out in Dec 2014, thus pre-dating last years G.INP roll out and the ensuing Lantiq based issues. Could it be therefore that BT are actually supplying HH5's without G.INP support even now?
-
I believe 4.7.5.1.83.8.204 supported g.inp but it had other issues (to do with WiFi I think) so was replaced with 4.7.5.1.83.8.204.1.11 over a year ago (and BT are rolling out a further update now).
I know you don't plan to use the HH5A but you might want to leave it connected long enough to get the .1.11 version if nothing else.
-
As gt94sss2 says 4.7.5.1.83.8.204 supports g.inp in downstream direction only.
The actual g.inp updates were likely rolled out mid 2014, but as mentioned there was instability with something unrelated to g.inp which was what the Dec 2014 f/w release was about. I explained in another post last year that I was told 'the latest versions support retransmission' and since the version no at the time was the above one I had the no of, its why I quoted that. But I also mentioned that it in another other post that it was likely that the prior version to it which actually contained any g.inp update.
-
So, since the test modem swap mentioned in the split off thread DSL has been up for 8 days and as usual racked up 2 downstream and 2 upstream CRC errors and the downstream remains interleaved.
Despite my assertion in the other thread that it would be a waste of time I did indeed waste some more time trying and failing to convince my ISP that the downstream should not be interleaved like it wasn't ever in the 4 years before openreach perpetrated this ECI/G.INP farce.
-
I have just had BT TV with Ultra HD installed at home. Like almost everyone else G.INP had been removed about a month ago from my line (ECI cab). However I am reasonably certain I have just had G.INP enabled again.
I am using the BT supplied ECI modem so no proper stats per se. However my throughput with online speedtests is back to indicating a line sync of about 67-69Mbps. I was down to 56 mbps when G.INP was removed and I immediately had interleaving applied. Also my pings (to bbc.co.uk) have gone from 18ms to now 10ms (the same as when I initially had G.INP MK1).
As a side note my TP-Link VR200 modem/router 'hung' whenever I watched the BT Ultra HD channel (434) and needed to be rebooted, so I suspect it is not completely compatible with BT TV.
-
(the same as when I initially had G.INP MK1).
Do you mean ECI G.INP Mk1 or Huawei G.INP Mk1 :-\
-
ECI G.INP Mk1 (2016)
I ordered BT TV they gave me back G.INP ;D
-
Interesting gamble for someone to try. What's the minimum payment and contract term for BT TV?
-
ECI G.INP Mk1 (2016)
I ordered BT TV they gave me back G.INP ;D
Have you got an unlocked modem to be 100% sure?
-
ECI G.INP Mk1 (2016)
I ordered BT TV they gave me back G.INP ;D
Are you sure that DLM hasn't just put you back on fastpath?
-
My line was never stable on fastpath, I was always interleaved. If I get chance I will put the TP-Link back on and telnet in.
-
I see the basic package is free. Did you get that one or the HD one? If you get g.inp for the free package I'll definitely sign up.
-
I ordered BT TV they gave me back G.INP ;D
I'd love to see confirmation of that, but I would be very surprised. I'm subscribed to a multicast service with talktalk and my g.inp was removed on my line alongside most others. I'd guess adding BTTV has come with a DLM reset and your just on fastpath . would love to be proved wrong though.
-
Hi, I forgot that my TP-Link does show some stats via telnet but not detailed G.INP info. So I had to borrow a Billion 8800NL, luckily I used to have one and I still had a backupsettings.conf settings backup file, so it was easy to connect up quickly & easily.
Yes my line now has G.INP :P
I ordered the BT TV UHD package - £16 per month.
-
Bit if G.INP is broken, why would they even enable it on your line just because you ordered BT TV?
Maybe they've fixed the problem and are rolling it back out and you were just one of the first to get it?
-
Who knows. No changes on the users already uploading to mydslstats at the mo.
-
I think the way openreach have made this decision is that IPTV services gain the most from reduced error count, so they are left as g.inp capable, but everyone else with the higher overall faults been reported have had it disabled.
-
I don't understand how streaming video benefits from G.INP more than say, time critical applications such as gaming. Just what exactly does streaming video gain from G.INP? You don't get a huge increase in download speed but your latency gets cut into three.
As a customer, I want G.INP back on. I'll be phoning them tomorrow and kicking up a stink since G.INP obviously CAN be enabled on a per line basis, and my line was brilliant with it on.
-
On IPTV errors = video artefacts etc. as the transmission is live.
Correct me if I'm wrong.
-
I've never had an IPTV service so I'm not up to scratch, but I assumed it would just buffer for a second if the download wasn't capable.
Either way, it's still not time critical information.
I wonder if I order BTTV if i'll get put on G.INP.
-
IPTV, whether live or streamed, is not carried by a protected protocol (such as TCP) where dropped packets would be re-transmitted by the far end. If a packet containing IPTV gets dropped - for whatever reason; bit-errors, congestion etc - it causes a glitch in the video/audio.
It doesn't matter what amount of buffering occurs - that glitch can never be recovered.
G.INP activates limited retransmission across the weakest part of the whole end-to-end segment (whether multicast or unicast): your copper connection. It isn't quite a guarantee that the packet gets through (which TCP would do), but it improves the odds no end.
-
Bit if G.INP is broken, why would they even enable it on your line just because you ordered BT TV?
It looks like it was fundamentally broken on a few lines, but the more common issue makes it look like it had a negative impact on either statistics or on the sync speed. However, it looks like, with the more common issues, it kept to its job of getting packets through less broken.
The balance that Openreach had to strike was that, while things looked bad in some senses, they still improved in the important aspects.
Having a TV package was perhaps enough to swing the balance. Quality of service becomes viewed slightly differently.
-
As a customer, I want G.INP back on. I'll be phoning them tomorrow and kicking up a stink since G.INP obviously CAN be enabled on a per line basis, and my line was brilliant with it on.
Good luck with that - lol. You need to remember you are dealing with a monopoly who don't give a crap other than a little bit about competing with Virgin media and about trying to sell you more stuff like IPTV. Your ISP doesn't give a crap because none of their competitors will please you either.
Did anyone else here have a problem with G.INP? Yeah Yeah it is all the fault of my Asus modem blah blah blah.
First I knew was my line which had been synced 80/20 fastpath for 3.5 years was interleaved up and down and banded to 64/20. The modem has a sort of built in DLM and was flashing telling me it had taken steps to stabilise the connection (didn't even know that was enabled). It seems like there must have been a crap load of errors and or resyncs.
Annoyingly my downstream remains interleaved 11 weeks later something which my ISP and BTOR are not going to fix because neither give a crap.
One thing I noticed looking back at modem screenshots I took at the time is the crc error rate on the 64M interleaved downstream was about 10 times higher (6 or 7 per day) than it currently is interleaved at 80M - strange.
-
I think I know what you see here, Ktor.
-
I don't understand how streaming video benefits from G.INP more than say, time critical applications such as gaming. Just what exactly does streaming video gain from G.INP? You don't get a huge increase in download speed but your latency gets cut into three.
As a customer, I want G.INP back on. I'll be phoning them tomorrow and kicking up a stink since G.INP obviously CAN be enabled on a per line basis, and my line was brilliant with it on.
Indeed, this has proven they are capable of overiding behaviour for individual lines, but simply have not offered it as an option other than the DLM profiles. We now seem to also have sub profiles which dictate whether g.inp is enabled or not.
-
I think I know what you see here, Ktor.
People who have not created an account and logged in don't see anything. A forum policy which makes many posts and their authors look stupid.
-
So long as the intended member can see it. :P
I'm just trying to lighten your mood slightly, constantly slagging OR (My employer) with not an ounce of an idea of how they truly operate is always going to draw my attention.
They do "Give a cr5p" ......... I know cos I'm on the receiving end of umpteen team meetings, e-mails, SMS, 1-1's, breakfast huddles, conference calls ..... about how we are performing and what the expectations are.
As in ANY business, they will get it wrong sometimes .... especially a mammoth business like mine. But to say the don't give a cr5p is simply juvenile.
-
I'm just trying to lighten your mood slightly, constantly slagging OR (My employer) with not an ounce of an idea of how they truly operate is always going to draw my attention.
And you really don't have an ounce of an idea of how pi**ed off some of you indirect customers are because you have deliberate policies to make sure you can't hear them. You notice 'slagging' here because you don't listen anywhere else.
You think anyone in OR is going to hear anything about Ornum's angry telephone call?
-
The fact of the matter is that our contracts are with our ISP's not OR.
I am sure BT Group would love not to have OR/Wholesale/Retail but OFCOM have decided differently.
I can sympathise with folk who have had disruption due to G.Inp (I gained a little and I am now back to square one; others are square one minus). But as long as the service being provided is within contractual limits ISP's have little contractual motivation to do anything.
Competition in the market it seems to me is about low introductory prices not quality of service.
-
Now can we get back to the subject of this thread please? Thank you.
-
Well said, Eric.
-
Whilst I cant provide any evidence to back this up I was told today that the document issued on the 21st by or basically mentioned that they were still monitoring and gathering data on lines that had been g.inp enabled on eci cabs and needed more data . It also mentioned that a further update was originally due on the 5th june but as far as he could tell this had not been issued and after making some further enquiries within "or" he could not get any new info and he couldnt see any further statements at this time. Supposedly he did gather that lines/cabs were still being monitored...could not find out about time scales either..
Read in to it what you will..just passing on what I was told....was amazed to get anything to be fair...
Perhaps another update might surface at some point considering the one on the 5th doesnt seem to be out ??
-
Now can we get back to the subject of this thread please? Thank you.
Please I would love to hear how Ornum got on with his "I'll be phoning them tomorrow and kicking up a stink" call. My guess is if he gets past his ISP's first line customer services it will only be because they don't understand what he is talking about.
-
I haven't got round to it yet as I've been a bit busy, but I will be phoning them soon. The first thing I plan to ask is, do you know what G.INP is? When they say no I will demand to be escalated to someone who does. Whether or not it will work I don't know, but I will be making it clear that I'm not phoning for customer support, I'm phoning to make a complaint. People usually listen when a. You're paying a bill, b. Looking to buy or c. Making a complaint. Actually if you ever need any kind of support, screw tech support and phone the sales and payments number and act as if you think you phoned tech support. You would be surprised how often this works and gets you put through to someone in Britian who actually knows what they're doing. The other trick is to call as a potential customer with you pre-purchase tech questions (even if you're already a customer).
-
You might be wise to ask if the call-centre advisor knows what re-transmission is, as well as G.INP. Depends who you talk to as to how they refer to it ?.
-
The two people I spoke to at BT support didn't understand G.INP or re-transmission. ???
When I said I would like G.INP re-enabling on my line cos I have BT TV and it's believed to be BT's policy not to disable it on such lines. The operator grasped that and quickly said "so it's a TV fault I'll transfer you to TV support".
My shouts of NO were not heard --- I now have a unspecified open fault on my TV service. :no:
-
Without actually trying to upset any more people:
I received another call from BT (Caller ID: 0800 3289393), the lady offered me a better deal on my BT broadband. Either £17 a month with a 1 year contract, or £14 a month with 2 year contract - both for BT Infinity 2, unlimited. Line rental is not included.
I signed up to the £14 a month deal. This makes the cost of BT TV with UHD almost negligible.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FUrzlzv4.png&hash=87fb847464e31c7baabf71ccfef21f559a42cd78)
-
I got Infinity 1 for £10 per month.
Also got a £100 reward card + £199 cash back. ;D
There's a different deal each week. ;)
-
I wonder who my next ISP will be with have tried BT then freeserve then Wanadoo then talktalk then BT and now EE must try Plusnet this time :-\
Not much ISP providers to choose from here they all come in as Market 1 BT price band BTw Pricing Band Band E no LLU here the difference from any ISP will be a few £ apart from Talktalk as they just ran away into LLU land and stuck two fingers up to IPstreamers disgusting :(
-
There was another update from Openreach yesterday:
NGA020/16 Update on Performance of Retransmission on the ECI platform (https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga02016.do)
No, I don't know what it says, it might say nothing more than that they're still working on it and the next update will be whenever.
-
So I am told it says the issue is still be investigated and another update of the issue is due on the 15th June (as in another statement..)
-
This ECI malarky is going to run & run,no closer to solving the problem.
Shame there isn't a simple fix like replacing the ECI cabs with Huawei cabs, but that is unlikely to happen.
Someone drop a clanger choosing ECI cabs.
-
Yesterday my ISP actually did something for the first time in the nearly 3 months I have been complaining. They requested a profile change which should reset DLM and it did cause a resync this morning and it still synced interleaved.
Today my ISP tells me my downstream is permanently interleaved due to the firmware update in the cabinet which BTOR is still in the process of recalling with no stated time scale.
Who thinks I should believe that? Who thinks I should just accept it if it is true?
-
They requested a profile change which should reset DLM and it did cause a resync this morning and it still synced interleaved.
That's a good start - that a resync was triggered.
Remember that @kitz's analysis was showing two separate DLM reset procedures. Some of them reset back to an old-style FEC+interleaved profile, while some of them reset back to an open profile with no FEC, no interleaving, and no retransmission. We don't know why there are two methods, and haven't come up with a plausible way to identify why one has happened vs the other.
So bear in mind that you might have had a DLM reset, but it is taking the former pathway. If so, then the next change would be expected after 48 hours. Perhaps to an open profile, and perhaps to a retransmission profile directly.
Today my ISP tells me my downstream is permanently interleaved due to the firmware update in the cabinet which BTOR is still in the process of recalling with no stated time scale.
Not so good. I'm not sure I would believe that, but ... given what I mentioned before ... you are probably best waiting 2 or 3 days anyway.
-
you are probably best waiting 2 or 3 days anyway.
Left it 3 1/2 days no resync and 11 CRC errors due to a lot of thunderstorms.
Plugged in a TP-Link modem then back to the Asus - both had downstream interleave.
Faulty cabinet firmware and/or faulty DLM who knows. I still have had pointless and undesired interleaving for 3 months and counting.
After the profile change resync the modem has started reporting downstream power as 0.1dbm, obviously wrong, it used to be 12.7dbm. Nothing changed my end looks like more ECI cabinet bugginess.
-
I think profiles are kind of stuck atm as I've had interleaving on my upstream on my ECI G.INP line and it has had 0ES a day since like late March.
-
So is G.inp dead now for ECI cabs, or is there a long term plan in place?
-
Just to note that I was stuck on interleaving until 9 days ago an OR guy did a full reset on my line as I was having problems. So far I've not had DLM intervene and I've been on fast path for these 9 days.
My only comment would be that according to this OR guy they are finding some issues with lines on ECI cabs which they believe are related to the removal of G.INP and he said he personally had seen some lines which after a complete reset had their issues go away. Now this is anecdotal I know but its strange that my line was fixed by one OR guy as it was raised as phone fault which did indeed exist but my broadband problems continued and the second OR guy responding to a broadband fault could find no problems with the line itself but now after the reset it has behaved very well on fast path, and all he did was this reset, he changed nothing at my end and did not disappear elsewhere to do anything. Go figure!
Stuart
-
Stuart. You line looks like how mine did until dlm changed it yesterday. My sync was higher than my attainable. Dlm dropped 4mb off the ds on the resync but the line still retains fastpath. Took about a week for dlm to sync it down with sync higher than the attainable..
-
Well since I was told wait 10 days after reset I guess I've got another 24 hours to go before DLM may or may not do anything.
Stuart
-
Broadstairs were you manually capping the modem ? the engineer found no fault on your line and yet a DLM reset which you wanted seemed to fix your line issue ???
-
hello guys, my 1st post :)
so i have a problem.i see you complaining about G.inp not working on your line,but here i have the opposite problem.
I have G.inp and i hate it,because it adds latency,with g.inp i have interleaving depth of 8 up/down cuz i have the inp 61 up/down delay 0, and it's bad at playing online games,30% of my hits wont register.so from my modem i can disable G.inp, but the interleaving depth will go to 837 down and 285 up cuz inp will go to 2 down/up and the delay will go 8 down 3 up,so it's worse, my ping will go +5/7 in speedtest and will not talk bout gaming.
no joke :D
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FkhV3nPu.png&hash=fad2bfadfe7f9e2e7fd00861d8e6d13514eef1f1)
The problem is that the isp here in italy,don't have fast vdsl profiles,the only profiles are G.inp on/off,which i can do by myself using telnet on my modem,and they wont do a fast profile,cuz that's the standard,they use interleaving to reach contract speed,so people will not complain.
So my problem is to get rid of G.inp and set my line in fast using a modem that can do this kind of tweaks.Since i can do some tweaks from my modem means that the dslam accepts the tweaks, i can change the data rate,lowering it,snr will increase and the interleaving too,sra,trellis etc etc.
I cant find a modem with this kind of tweaks, like delay/inp,i found some that can do CO/CPE, but the tweaks can work only in CO,simply cuz u create a vdsl line and u can choose whatever u want.
I found this modem Kasda KW52283,and looking at the manual there is a setting that u can choose,PTM configuration Path0(fast) Path1 (interleaved) look in the manual page 18.
manual here (https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj-qbCP6OvNAhVGNxQKHQtTBWEQFggcMAA&url=http%3A%2F%2Fwww.kasdanet.com%2FENHCSZ%2Fpro_down-67.html&usg=AFQjCNGv_gJjfpwexoSE-2a8hbTkrNFDHw&bvm=bv.126130881,d.d24)
what do you think guys?is it possible to do it?maybe you know a different modem that have CO settings in a CPE modem.i looked at some cisco 880va,but it looks complicated to configure.
thanks.
-
Faulty cabinet firmware and/or faulty DLM who knows. I still have had pointless and undesired interleaving for 3 months and counting.
So I asked the ISP for a deadlock statement so I could take the problem to arbitration. They offered to register a complaint with BT Openreach which I accepted and as usual they do nothing for a week then contact me to ask if I really wanted a complaint lodged with openreach, which, of course I did.
Lucky me instead of the ISP ignoring me I get to be ignored by BT Openreach for two weeks before they also tell me to p1ss off. Apparently some operations manager doesn't know anything about cabinet firmware and some 'coach' says nothing could be done without reporting a fault and is isn't a fault so you can't report it.
Just as I have said all along "We don't give a crap, take what we give you and like it".
Back in march when I was told an overnight 20% drop in downstream speed and 25ms more latency from bi-directional interleave wasn't a fault and to p1ss off I started maintaining the attached modem stat (Unlike copper and cabinets BT/ISP don't have a monopoly on being aholes). I didn't imagine I would still be maintaining it 3 and a half months later - looks like I will be for at least another 6 months of pre-paid line rental before I probably switch to Virgin. The idea of buying anything from BT has become abhorrent, I already ceased a second land line for that reason.
I mentioned the stat to the ISP guy today, he told me the package was unlimited and bandwidth doesn't cost them anything - so that's all-right then - lol.
-
I have G.inp and i hate it,because it adds latency,with g.inp i have interleaving depth of 8 up/down cuz i have the inp 61 up/down delay 0,
I think you are getting slightly confused.
INP generally stands for "impulse noise protection", and VDSL2 uses values for INP to offer protection against noise. However, "G.INP" isn't the same as "INP". It is a different means to protect against noise by using "retransmission".
When looking at line statistics, you can usually tell that G.INP (retransmission) is in use when the "INP" value is set to something much higher: above 30 is common in the UK and in Ireland. Alongside this, the "delay" value would be set to 0 (zero, so there is little additional latency), and interleaving depths will be 0, 4, 8 or 16.
In your case, "INP" is set to 2 (up and down), and "delay" is set to 8ms down and 3ms up. Those values suggest that G.INP (retransmission) is not in use. Instead, your modem is using old-style INP settings that turn on FEC and interleaving, and allow for 11ms of additional latency.
Beyond that, I don't know of tweaks that you can use - others may be able to guide you better. However, in the UK, our telco has locked down the DSLAM so that it ignores almost all the tweaks you could set. I believe you can deliberately set a lower speed, in the hope that this reduces error rates, which in turn persuades the system to put you back on fastpath.
-
that's the issue.the inp.i have like 40k forward errors corrected a day (specially when gaming,i get even more),and the correction adds latency,on bf4 30% of my hits don't register(not bf4 hitreg problem,got fixed).only way from what i saw on uk forums,to have the line in fast is (to disable g.inp in my case) then inp 0 and delay 0,that way forward errors will not be corrected.i didn't see people with g.inp enabled and inp 0 delay 0 or some kind of fast lane with g.inp.
so that's why i'm asking if somebody knows a modem with CO settings usable on CPE,since my dslam accepts modifications from the modem.the dslam is a Selta SAMBHA 200.
-
I recommend you to have G.INP enabled rather than any alternative.
-
well in this situation yes,cuz without is worse.but still, the correction its simply a disaster.before with adsl2+ fastpath had a ping of 10 on a server test,now its 19/20/21,and its not a cable problem or something like that,cuz the technician did some tests on the line with a tester and it's ok.
somehow if i set a data rate of 100 down and 1 up, the interleaving depth in upload changes to 2 from 8, with the same inp of 61 but snr goes to 32db from 11db.
-
Cannot advise you really as you in italy and no idea what their policies are but on a technical level.
fast path = minimal added latency, however errors may cause packet loss. Which would be hits not registering in games if the packet loss is bad enough.
interleaving with no g.inp = permanent increased latency, base latency is higher but jitter remains same as fast path. Much less likely to get packet loss than fast path.
interleaving via g.inp = variable latency, when errors need correcting latency for the affected packets will increase, so you have comparable base latency to fast path but jitter is introduced. This is typically the most desirable configuration, as jitter is better than packet loss.
The only 2 modems I can think off that might give you the ability to overide the dslam in this case is either the asus devices or possibly the fritzbox devices. Its not something that I have ever seen as a publicised ability and I have never heard of anyone in the world been able to overide the isp's interleaving configuration in this way.
-
only way from what i saw on uk forums,to have the line in fast is (to disable g.inp in my case) then inp 0 and delay 0,that way forward
errors will not be corrected.i didn't see people with g.inp enabled and inp 0 delay 0 or some kind of fast lane with g.inp.
I'll repeat: "INP" is not the same as "G.INP".
In the UK, we have 3 basic modes of operation:
1) Fastpath
INP=0, delay=0.
Most susceptible to errors
In mode (1), G.INP is not active.
2) Interleaving and FEC
INP=3 or 4, delay=8ms, 12ms or 16ms
With these settings, interleaving depth is around 1,000 and latency increases by between 8ms and perhaps 20ms.
In mode (2), G.INP is not active.
3) Retransmission - aka G.INP
INP=40-50, delay=0.
With these settings, retransmission is the main protection method, but small amounts of interleaving exist. The interleaving depth is less than 100, and the latency doesn't increase in any appreciable manner.
In mode (3), G.INP is active. Retransmission is used when errors occur.
In the UK, mode (3) - with G.INP enabled - is generally thought to be the best mode to use - it gives the lowest error count, with the lowest impact to latency for gamers.
It looks like your line is currently in mode (2), or the Italian equivalent. You do not need to try to disable "G.INP" because it is not turned on for your line.
-
.the dslam is a Selta SAMBHA 200.
looks like a nice piece of kit
http://www.selta.com/ProductDetail?id=01t20000004m10XAAQ
look into the Asus DSL-AC68U, absolutely useless in the UK. might be better on an unlocked dslam.
-
the asus has same configs like mine.what i need it's something like this:manual (http://datainterfaces.com/usermanual/vdtu2-r140-manual.pdf) page 17,look at the image.those settings work if u choose the CO mode aka mini dslam,u create a vdsl line to transmit,and you choose the parameters.i need those settings in CPE mode,to modify the line i receive.i looked at some modems,and all of them work the same,CO u have parameters,CPE no parameters.
@WWWombat
i'm in mode 3,but i can get in mode 2 using telnet commands on my modem "xdslctl configure --Ginp 0x0",but i can't get in mode 1 cuz my modem doesn't have inp and delay commands, and my isp have only 2 profiles, mode 3 and 2,doesn't have mode 1, and don't want to do it,and that's what i'm trying to do,but i need a modem with those settings.
-
@willc
I don't think you are in mode 3. The screenshot show INP values of 2 and "delay" values that are non-zero: both are clear indications that you are in mode 2.
If you used to be in mode 3, and have put yourself into mode 2, then undo everything - you made things worse. If you want better latency for your gaming, mode 3 is better.
Also note that, in general, the telco companies do not want you to be able to tweak your settings, or to adjust your line profile. Even when you make a change at your side, there is no guarantee that the DSLAM will stick to your setting ... and, as you have discovered, some settings are only possible on the DSLAM side anyway.
There are modems that will let you (try to) tweak your target noise margin. However, in this country, the VDSL2 DSLAMs will ignore that, and use a target of 6dB anyway. Here, there are almost no tweaks that work - and I haven't heard of a single person who has managed to tweak INP and delay settings to result in fastpath. Not one, in 6 years.
-
@WWWombat
you didn't read my post (http://forum.kitz.co.uk/index.php/topic,17195.msg327451.html#msg327451) well :
I have G.inp and i hate it,because it adds latency,with g.inp i have interleaving depth of 8 up/down cuz i have the inp 61 up/down delay 0, and it's bad at playing online games,30% of my hits wont register.so from my modem i can disable G.inp, but the interleaving depth will go to 837 down and 285 up cuz inp will go to 2 down/up and the delay will go 8 down 3 up,so it's worse, my ping will go +5/7 in speedtest and will not talk bout gaming.
so ye, i'm in mode 3 cuz 2 is worse,and can't find nothing that has some inp and delay tweaking :(
-
Yes @willc, I did read your post. I was mislead by your screenshot which seemed to contradict what you wrote in the text.
In the same quoted text, I'll highlight the bit that we should pay attention to now:
I have G.inp and i hate it,because it adds latency,with g.inp i have interleaving depth of 8 up/down cuz i have the inp 61 up/down delay 0, and it's bad at playing online games,30% of my hits wont register.so from my modem i can disable G.inp, but the interleaving depth will go to 837 down and 285 up cuz inp will go to 2 down/up and the delay will go 8 down 3 up,so it's worse, my ping will go +5/7 in speedtest and will not talk bout gaming.
G.INP/retransmission adds virtually no latency, compared to the old-style FEC+Interleaving settings (in the UK: INP=3, delay=8ms).
My calculations are that, when retransmission is activated in the UK (with INP settings higher than 30, and delay=0), the small amount of "interleaving depth" (and "interleaving block size" )amounts to around 0.2ms of latency, compared to the 8-16ms of latency that BT used to allow.
I can't calculate the equivalent figure for you, as you haven't given us the same data for running with G.INP. Without G.INP (with INP=2), your line has added latency of 11ms.
Here in the UK, the 0.2ms seems to be pretty much invisible.
If your gaming is suffering, I suspect there may be other more significant causes than the 0.2ms that comes from G.INP activation.
Do you have access to something that monitors your ping times 24 hours a day? To see how consistent your ping times are?
I have one of these running from somewhere in London, pinging my router once a second, and producing graphs like this:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F39df7f4b07b0bad3a622344dc973e989-12-07-2016.png&hash=2534344ba661465ce4feb6538f9e6e3f9315ec30)
can't find nothing that has some inp and delay tweaking :(
I don't think you ever will.
-
My line is used mostly for gaming, I can say for my line g.inp mode was the best experience for me. Fast path was in second place followed way behind by interleaving and fec which I'm currently on. Desperately waiting for a eci g.inp fix.
-
My line is used mostly for gaming, I can say for my line g.inp mode was the best experience for me. Fast path was in second place followed way behind by interleaving and fec which I'm currently on. Desperately waiting for a eci g.inp fix.
it depends,every case is different.in my case i have a lot of FEC 80k a day when gaming,normally 40k,means that errors get corrected,that's what increase latency,and the inp@61 up/down does it.looking at a table here (http://www.kitz.co.uk/adsl/interleaving.htm) Burst Protection adds huge latency.
-
The highest number I see on that table is 4ms which isnt a great deal to be honest
-
it depends,every case is different.in my case i have a lot of FEC 80k a day when gaming,normally 40k,means that errors get corrected,that's what increase latency,
No - FECs are errors that never happened, and take no time whatsoever to fix. If you get zero, or 5 million, you will see no change in latency.
Interleaving is what adds latency - and that happens from the moment the line profile is set that way. Once the line is configured with interleaving, then even with zero FECs, you will have encountered the impact on latency.
looking at a table here (http://www.kitz.co.uk/adsl/interleaving.htm) Burst Protection adds huge latency.
The important point, however, is that the mere existence of "interleaving" does not imply there is extra "huge latency".
The table you quoted applies to ADSL, and the relationship between "latency" and "interleave depth" really depends on the total speed.
In VDSL2, the important parameter is the "delay" parameter that you highlighted in your first screenshot. There, your line was allowing 8ms of extra latency downstream and 3ms of extra latency upstream: a total of 11ms extra latency.
To achieve this, the modems agreed an interleaving depth of 837 downstream (and an interleaved block size of 128; this is an important number too), and an interleaving depth of 285 upstream (and an interleaved block size of 44).
However, go back and look at the same delay value when G.INP is running: a "delay" of 0. Zero.
Here, I have G.INP running, with INP=48, delay=0, interleaving depth=16, and interleaving block size=139. Your downstream settings (when in mode 2) allow for 8ms of latency, mine (in mode 3) allows for 0.16ms.
As you saw from the graph yesterday, my round-trip ping times (home - London) are currently around 13ms; the extra latency from G.INP is approximately 1% of that round trip time. I wouldn't classify that as "huge latency".
If you post the same screenshot of your line profile with G.INP running, I can calculate yours too.
-
i'm telling you,in bf4 when i shoot,20/30% of my shots don't register,and when people shoot me, i get the shots like a magnet,i get all the shots in one bang,and when i die my body jumps to who shot me,like fishing :D
here just restarted:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 32028 Kbps, Downstream rate = 101992 Kbps
Bearer: INTR, Upstream rate = 21600 Kbps, Downstream rate = 101028 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Line Encoding: DMT
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Cell Delin: 0
Down Up
SNR (dB): 6.7 10.8
Attn(dB): 0.0 0.0
Pwr(dBm): 13.7 -13.6
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 243 73
M: 1 1
T: 0 0
R: 10 8
S: 0.0769 0.1079
L: 26422 6079
D: 8 8
I: 254 82
N: 254 82
Q: 8 8
V: 0 5
RxQueue: 100 70
TxQueue: 20 14
G.INP Framing: 18 18
G.INP lookback: 20 14
RRC bits: 24 24
Bearer 1
MSGc: 234 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 4.5714 16.0000
L: 56 16
D: 3 1
I: 32 32
N: 32 32
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 0
OHFErr: 0 0
RS: 14143976 1532877
RSCorr: 73 8
RSUnCorr: 0 0
Bearer 1
OHF: 15920 17068
OHFErr: 0 0
RS: 237946 68273
RSCorr: 0 1
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 2306 2
rtx_c: 20 321
rtx_uc: 0 21530
G.INP Counters
LEFTRS: 0 5
minEFTR: 101033 21591
errFreeBits: 422231 9604269
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 53232957 0
Data Cells: 19875 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: 0 0
SES: 0 0
UAS: 30 30
AS: 274
Bearer 0
INP: 60.00 59.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 101132.00 21858.32
Bearer 1
INP: 3.00 4.00
INPRein: 3.00 4.00
delay: 2 0
PER: 17.20 16.06
OR: 111.56 31.87
AgR: 111.56 31.87
Bitswap: 137/137 0/0
Total time = 5 min 4 sec
FEC: 73 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 5 min 4 sec
FEC: 73 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 min 4 sec
FEC: 73 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 min 33 sec
FEC: 73 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
TotalRetrains: 0
ShowtimeRetrains: 0
#
-
i'm telling you,in bf4 when i shoot,20/30% of my shots don't register,and when people shoot me, i get the shots like a magnet,i get all the shots in one bang,and when i die my body jumps to who shot me,like fishing :D
I can't doubt what you say at all. I can only say that it is hard to put the blame on the extra latency from G.INP. I'll go check through the stats in a minute...
What have you got to compare it to? What is the *best* behaviour, when this doesn't happen?
-
I can't doubt what you say at all. I can only say that it is hard to put the blame on the extra latency from G.INP. I'll go check through the stats in a minute...
What have you got to compare it to? What is the *best* behaviour, when this doesn't happen?
things get a bit better when i change these things:
trellis off i24k off CoMinMgn off sra off and connection noretrain does a big difference.with this tweaks ping lowers about 4/5 ms.
anyway i give up with the isp and all this stuff,i will move out.don't loose time anymore.
thanks for the replies
-
Most of those tweaks are probably not applicable to VDSL2.
Trellis coding - mandatory to be supported for VDSL2 (and ADSL2, ADSL2+, but optional for ADSL1).
i24k - 24k bytes of interleaving memory - that's an ADSL2+ thing, where equipment either had 16k or 24k memory for interleaving. Not applicable to VDSL2 which needs more memory for interleaving than that anyway.
Min margin - that controls whether your modem will retrain when the SNRM drops below a certain value set by the DSLAM, shouldn't really affect anything else.
SRA - seamless rate adaptation - might affect things if SRA actually happens if you don't disable it.
-
How can one have a Bearer of 101028 Kbps on the UK FTTC 80/20 service :-\
Max: Upstream rate = 32028 Kbps, Downstream rate = 101992 Kbps
Bearer: INTR, Upstream rate = 21600 Kbps, Downstream rate = 101028 Kbps
Bearer 0
INP: 60.00 59.00
seems odd unless they are outside the UK
-
How can one have a Bearer of 101028 Kbps on the UK FTTC 80/20 service :-\
Max: Upstream rate = 32028 Kbps, Downstream rate = 101992 Kbps
Bearer: INTR, Upstream rate = 21600 Kbps, Downstream rate = 101028 Kbps
seems odd unless they are outside the UK
it's italian garbage
@ejs yes i know,but turning off stuff apparently works.
-
it's italian garbage
Not from what I can see ;)
-
Not from what I can see ;)
if performs worse than a dsl in terms of latency and makes online gameplay like a dsl with 7 mb down and 0.256 up 2006 times then yes.
only thing this is useful is to download stuff (piracy)
when i saw fiber availability i was :dance: then did the first game on bf4 and i was :'(
-
I would imagine then before you were helped out a lot by the lag compensation of the game. Have you done any tracert tests to discover what ping you have to various locations?
-
Being an X online gamer I did fine with 45-60ms with interleaving you can't just blame G.INP as the issue here I do blame some game servers for the lag you experience.
-
I would imagine then before you were helped out a lot by the lag compensation of the game. Have you done any tracert tests to discover what ping you have to various locations?
it changes always when rebooting modem.after several reboots i can get good ping around 35 on uk servers,but usually 40/45/50.
it's not the ping it's interleaving the problem.i see australians with 90 of ping,turks with 60/80 they all kick my butt :mad:
Being an X online gamer I did fine with 45-60ms with interleaving you can't just blame G.INP as the issue here I do blame some game servers for the lag you experience.
it's the interleaving man,u are close to the servers uk/germany.on bf4 ping is not so important,like i said turks aus russians they kick me butt
-
Hi
I have mentioned in other post over gaming.
There are well known or not so well known network exploits to gain an advantage over other players, but if caught, usually lead to a permanent ban of the game.
I have seen this, and usually just move to another lobby
Many thanks
John
-
Hi
I have mentioned in other post over gaming.
There are well known or not so well known network exploits to gain an advantage over other players, but if caught, usually lead to a permanent ban of the game.
I have seen this, and usually just move to another lobby
Many thanks
John
you mean that they are cheating,using hax ?
-
Hi
I would never go that far as to state that, especially as I do not play bf4
I have seen it on Xbox and ps, and know they were not in the position where screen showed
Just look up lightswitch, which can manipulate network, easy to build and use
If it was true latency or interleave, when it caught up given what you said, you would be dead instantly, not in the process of been killed, just as when I played shift, leading the race, suddenly another player may jump straight into first place, even though they were behind me, but when I say first place, they were very far infront
This is how you tell if using network manipulation and works be fooling the game servers into a poor connection when Infact they have an excellent connection
Where this happens, I just change lobbies
Many thanks
John
-
(Whoops --- I wrote this yesterday, and obviously forgot to post it)
I'll go check through the stats in a minute...
The portion of latency added by interleaving, when G.INP is activated, probably accounts for 0.15ms downstream plus 0.17ms upstream, making a total of 0.32ms. Detailed calculations below.
That is approximately 3% of the extra latency of your mode 2 (interleaving when G.INP is disabled), when INP=2 and delay=8ms (down) and 3ms up.
Here are my calculations:
1. Downstream Mode 2
In mode 2, your modem would have to fill a block of data sized 837*128, total 107kbytes, before transmitting. The DSLAM would have to receive the whole block before de-interleaving. Processing that 107kbytes is what gives 8ms of latency.
2. Downstream Mode 3
In mode 3, the block is sized 8*254, total 2kbytes. If it takes 8ms to interleave/de-interleave 107k, then it takes 1/53th of the time to interleave/de-interleave just 2k ... 1/53 of 8ms is 0.15ms
3. Upstream Mode 2
In mode 2, the DSLAM has to fill a block of data sized 285*44, total 12kbytes, before transmitting. Your modem has to receive the whole block before de-interleaving. Processing that 12kbytes is what gives 3ms of latency.
4. Upstream Mode 3
In mode 3, the block is sized 8*82, total 0.7kbytes. If it takes 3ms to interleave/de-interleave 12k, then it takes 1/17th of the time to interleave/de-interleave just 0.7k ... 1/17 of 3ms is 0.17ms
NB: The calculation will be slightly wrong on the downstream side, because you likely synchronised at a higher speed in mode 3 (I estimate 101Mbps instead of 92Mbps), because the G.INP configuration also uses less overhead for FEC.
With the higher sync speeds, bits are travelling about 10% faster, so the block travels 10% quicker, and the latency is likely to be reduced about 10% - down to about 0.135ms
-
it's not the ping it's interleaving the problem.
Interleaving only has two effects:
a) To alter the bit error distribution, to allow FEC to correct more errors
b) To alter the ping time, aka latency.
If it isn't the ping time, the latency, then the only other part that interleaving can affect is the error rate. But your line doesn't look to suffer many errors.
BUT...
G.INP has an extra impact on latency, that isn't caused by interleacing. If the retransmission mechanism is used after some packets are corrupted (and cannot be fixed by FEC), then there will be some extra latency for those packets only. That appears as jitter, where the latency varies a lot.
Again, your line doesn't seem to suffer from errors (FECs aren't important here), so I doubt this is the problem.
If you want me to confirm this, you'll need to provide two sets of statistics like last time, but separated over 24 hours.
things get a bit better when i change these things:
What I really meant was: How do you know that your problem is with G.INP if the only change you can make to get rid of G.INP makes things worse? How can you tell that fastpath is certain to be an improvement?
if performs worse than adsl in terms of latency and makes online gameplay like adsl with 7 mb down and 0.256 up 2006 times
When you moved to a "fiber" service, your backhaul probably changed too ... your gaming problems might be being caused there (for example, by sharing a congested link), and the latency of your G.INP access connection plays only a small part.
Did you move ISP when changing to fibre? Do you have any measured "ping" times from the command-line, rather than from within games?
For example, my round-trip ping time can be seen in "ping" commands to the BBC:
C:\>ping www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.246.95] with 32 bytes of data:
Reply from 212.58.246.95: bytes=32 time=12ms TTL=55
Reply from 212.58.246.95: bytes=32 time=13ms TTL=55
Reply from 212.58.246.95: bytes=32 time=13ms TTL=55
Reply from 212.58.246.95: bytes=32 time=13ms TTL=55
Ping statistics for 212.58.246.95:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms
When my line was fastpath, I'd get times of around 12-13ms. When my line was faulty, and I was given interleaving settings (INP=3, delay=8ms on downstream only), those 13ms times increased to 21ms. Now I'm on G.INP, and my ping times stayed the same: 12-13ms.
In fact, I have some good images to show those last numbers. Let me go and get them off a different computer...
-
Finally, I have a couple of graphs to show you that give you an idea of what happens to latency:
a) When the line changes from "fastpath" (with a lot of errors) to "FEC + Interleaving" with INP=3, delay=8ms (with few errors)
This was my very first FTTC line in 2011, and the graph shows the ping round-trip latency.
I think you can readily see the impact of the 8ms extra latency. It is *very* obvious.
b) When the line changes from "fastpath" (with very few errors) to "G.INP" (with no errors).
I am part of the UK national "Ofcom" broadband monitoring test group, and my line has a test box permanently connected, running tests.
I have attached a graph that covers results for "UDP latency" (ie equivalent to ping round-trip time, but using UDP) from February 2015 through to July 2016.
At the start (February 2015), my line was "fastpath", and encountered very few errors.
On 27th March 2015, BT changed my line to G.INP for both upstream and downstream, as part of their rollout of G.INP nationwide.
On 26th June 2015, BT changed the line to put upstream back to fastpath, again as part of a nationwide rollout (too many modems failed with G.INP upstream).
The worst thing you can say is that the the line went slightly more unstable in the first month of deployment (I didn't notice any difference though).
But the latency times became indistinguishable from fastpath, and stayed that way.
-
thanks for the answers.
so i'm waiting for the package xxxx,i'll do some tests and report (if everything goes by the plan)
today played on a german server with 24 of ping, and me butt got hurt,simply my bullets don't work,specially when somebody shoots at me.
by the way this is mine,will use for comparison:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F2u5MMGh.png&hash=b0e65b71542dcb3ce920dfee35f01caa47daa244)
-
Hi
Wwwombat, do you mean your a Sam knows tester or if not, I would be interested to become ofcom tester as well
Willc, your pings are high to bbc, what does pathping result show - open command box, pathping bbc.co.uk
Just thinking this may give a better clue and who is your ISP
Many thanks
John
-
@d2d4j
Note that @willc is in Italy, so is likely to have long pings to the BBC servers in the UK. 40ms isn't that bad...
If I do the opposite, and try to ping "www.rai.it", I unfortunately reach some Akamai server located in the UK, so get a bogus reading.
If I try to "traceroute" to (for example), the Telecom Italia website, I find it takes me 12ms to get to London, 38ms to get to the Milan gateway on Seabone, and 47-50ms to get through to TIM's own network. Judging from the Seabone map (http://peering.seabone.net/map.html), that extra 12ms is consistent with a hop from Milan to Rome.
Tracing route to tim.it [156.54.69.9]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms 192.168.0.1
2 11 ms 11 ms 11 ms lo0.16.Central16.pcl-bng01.plus.net [195.166.130.210]
3 17 ms 11 ms 11 ms irb.15.pcl-cr01.plus.net [84.93.249.161]
4 12 ms 12 ms 12 ms 195.99.126.96
5 13 ms 12 ms 12 ms core3-te0-10-0-19.faraday.ukcore.bt.net [109.159.249.23]
6 13 ms 13 ms 13 ms peer5-BE5.telehouse.ukcore.bt.net [213.121.193.171]
7 14 ms 12 ms 13 ms t2c4-et-8-1-0-0.uk-lon1.eu.bt.net [166.49.211.248]
8 13 ms 12 ms 13 ms ae14.londra32.lon.seabone.net [89.221.43.172]
9 37 ms 37 ms 37 ms ge6-1-8.milano1.mil.seabone.net [195.22.208.36]
10 38 ms 38 ms 38 ms ibs-resid.milano1.mil.seabone.net [93.186.128.210]
11 * * * Request timed out.
12 * * * Request timed out.
13 50 ms 50 ms 50 ms crs-mi003-vl4.opb.interbusiness.it [151.99.75.244]
14 * * * Request timed out.
15 * * * Request timed out.
16 47 ms 47 ms 47 ms 80.21.4.83
17 47 ms 47 ms 47 ms host46-83-static.86-94-b.business.telecomitalia.it [94.86.83.46]
18 * * * Request timed out.
19 49 ms 48 ms 49 ms host117-38-static.77-62-b.business.telecomitalia.it [62.77.38.117]
20 50 ms 48 ms 48 ms host118-38-static.77-62-b.business.telecomitalia.it [62.77.38.118]
21 * * * Request timed out.
22 * * * Request timed out.
23 49 ms 49 ms 50 ms 156.54.69.9
and, just to show that "ping" is consistent with "traceroute":
>ping www.tim.it
Pinging tim.it [156.54.69.9] with 32 bytes of data:
Reply from 156.54.69.9: bytes=32 time=49ms TTL=236
Reply from 156.54.69.9: bytes=32 time=49ms TTL=236
Reply from 156.54.69.9: bytes=32 time=49ms TTL=236
Reply from 156.54.69.9: bytes=32 time=49ms TTL=236
Ping statistics for 156.54.69.9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 49ms, Maximum = 49ms, Average = 49ms
-
Wwwombat, do you mean your a Sam knows tester or if not, I would be interested to become ofcom tester as well
Yes - that graph is the output from the tests run by my SamKnows whitebox for the Ofcom testing.
I've been running those since 2011, but they sent me a new box in February last year and I lost all my previous results.
-
Hi wwwombat
Ah sorry, I did not realise or missed willc in Italy sorry.
Your correct that would explain the higher pings to bbc
Please ignore pathping as it would not help sorry
Many thanks
John
-
Hi wwwombat
Many thanks, good to meet another Sam knows tester and mine has not been replaced since 2011 I think
Many thanks
John
-
looks like a nice piece of kit
http://www.selta.com/ProductDetail?id=01t20000004m10XAAQ
look into the Asus DSL-AC68U, absolutely useless in the UK. might be better on an unlocked dslam.
i sent u some pm
-
nothing unexpected there. I don't think the "g.inp profile" was ever able to be selected by an ISP, it's all handled automatically by dlm.
sounds from that though that OpenReach are no longer "individually re-profiling" lines, at least fir sky, as some ISP's allow you to switch from standard to speed profile.
-
Is G.inp dead then? Or still planned...?
-
On MyDslWebStats there is a user still showing G.INP on ECI
-
Is G.inp dead then? Or still planned...?
OR indicated a fix is being worked on but IF it returns,it wont be till next year..
-
On MyDslWebStats there is a user still showing G.INP on ECI
I am one of the chosen few :D
I have a feeling it's due to UHD BT TV as I took a TV package on my plusnet line to see what would happen.
-
we wondered who were the mystery people who had ppp connectivity issues on g.inp eci right?
well this is a sky customer, so dhcp not ppp, but g.inp broke dhcp, guess what modem he was using?
The asus dsl-ac68
I knew that device would be trouble.
http://www.skyuser.co.uk/forum/sky-broadband-fibre-help/60543-asus-dsl-ac68u-wan-connection-isps-dhcp-did-not-function-correctly.html
-
Draytek 2850 was another one with the PPP issues In fact there were iirc 2 draytek models which had problems but cant remember the other one off the top of my head now. Draytek admitted defeat on them and instead they will offer £100 off a more updated model. The 2850 was one of the first VDSL2 modems available in 2012.
-
I still can't believe Openreach would disable G.INP on all ECI cabinets due to what must be a tiny number of Asus VDSL2 models and the Draytek ones (2850 and 2750 (http://www.draytek.co.uk/information/our-technology/bt-sin-498)).
I'm not even sure they said it was "PPP issues" this time (which always sounded more like general data transfer difficulties, as in the modem says it's connected but it's not really working), they just said there was an increase in the rate of fault reports.
-
Another OR update on ECI transmission posted 30/8/16
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga02316.do
-
Another OR update on ECI transmission posted 30/8/16
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga02316.do
So what's the summary?
-
don't know as I don't have access - just posting it to let others know they have obviously said something... only CP's have access to it.
-
Well they did disable upstream G.INP for all as standard on huawie cabinets because some modems had problems with G.INP on the upstream.
This ECI G.INP issue is on the downstream which is not an easy fix as it was on G.INP MK1 to MK2 turn off G.INP on the upstream
-
And the daft thing about that was upstream G.INP for Lantiq modems seemed to only need a firmware update.
-
It's amazing how a minority of users can influence openreach with calls to there ISP and all they needed was a compatible VDSL modem rather than OR to take this drastic step and remove G.INP for all though some members were steadfast and unwilling to give G.INP a go they wanted to stay on fastpath !
-
As I said earlier, I find that difficult to believe, not helped by the absence of any detailed information on what the actual problem is. "PPP issues" is about as detailed as "the Internet is not working".
-
All they needed to do was enforce their own guidelines i.e. ban incompatible devices. But they took the path of least resistance instead.
-
Should block incompatible devices and then charge then if an engineer gets called out due to it.
Can they not detect incompatible devices and notify the ISPs?
-
yes enable g.inp then ban every device that misbehaves :)
-
All they needed to do was enforce their own guidelines i.e. ban incompatible devices. But they took the path of least resistance instead.
Sure your one of those users that wanted to stay on fastpath and didn't want anything to do with G.INP if memory serves me right and the 8800NL is a none MCT compatible device in oprenreach's eyes ;)
-
I hate interleaving but not g.inp :)
if the 8800nl got banned then so be it I would just plug the hg612 back in
-
Another OR update on ECI transmission posted 30/8/16
Uno (xilo) has posted an update on TBB....http://forums.thinkbroadband.com/otherisp/t/4500729-re-uno-self-install-fibre.html (http://forums.thinkbroadband.com/otherisp/t/4500729-re-uno-self-install-fibre.html)...well into 2017.
Ian
-
Uno appears to be commenting on whether or not BTOR's official modem update system will remain in effect, not on the schedule for G.inp. Although the fact that it is remaining online suggests they are working with Lantiq and ECI to fix it.
-
Woops...read more carefully....craws back under stone ... :-[
-
27 weeks of complaining, argument, going through ADR then more argument to finally get someone from openreach to tap a few keys on a touchscreen and give me back this
Pinging www.bbc.co.uk [212.58.244.67]....
99 packets received/99 transmitted : 0% PACKET LOSS
Round Trip Time (in milliseconds) Max/Min/Av: 7/6/6
-
So, how do we find out if it has been applied to my connection?
-
You need a modem that will give you the stats. If you are on ECI CAB you won't have it as it was removed whilst hopefully we might see it return in April 2017 if the tests went well...
What's your modem or modem/router model etc
There is plenty of info on this site of how to obtain your stats. It just depends on what you are using.
-
My line has had G.inp enabled on the downside from March 2016, I am on a ECI Cabinet using a Vigor 130 modem, this is probably due to having BT Youview box.
John
-
Yes - I think you might be the only one now.. didn't step lose his as well in the end?
-
Will be putting the HG612 back on line in the new year as the stats from the Vigor 130 are very limited. I know I will lose some download speed but will leave it on for a couple of weeks.
John
-
You need a modem that will give you the stats. If you are on ECI CAB you won't have it as it was removed whilst hopefully we might see it return in April 2017 if the tests went well...
What's your modem or modem/router model etc
There is plenty of info on this site of how to obtain your stats. It just depends on what you are using.
Ah ok, thanks.
Yes, im on ECI with the standard BTOR modem.
I did purchase the Dratek 130, but i was having issues with pages struggling to load, almost as if the internet was too quick for it.
In fact, from memory, it even crashed on some normal websites.
I might try it again in the new year as i have seen that there have been some updates to the firmware since i used it.
If i put it back in service, is there a particular page on the modem UI that i can find it?
Thanks
:)
-
The latest Vigor 130 firmware is 3.7.9.3BT released 3rd November 2016, Link to download page for UK: https://www.draytek.co.uk/support/downloads
I have the Asus router setup so I can access the stats from 192.168.2.1
John
-
Ah ok, thanks.
Yes, im on ECI with the standard BTOR modem.
I did purchase the Dratek 130, but i was having issues with pages struggling to load, almost as if the internet was too quick for it.
In fact, from memory, it even crashed on some normal websites.
I might try it again in the new year as i have seen that there have been some updates to the firmware since i used it.
If i put it back in service, is there a particular page on the modem UI that i can find it?
Thanks
:)
What model is your bt modem? - if it's a HG model you can unlock it easily.
-
Yes - I think you might be the only one now.. didn't step lose his as well in the end?
Mine still has it (ayeaye on MDWS) with the HG612.
Was offline for a while in reporting stats as the box I was using needed rebuilding and I forgot all about stats.
-
ah yes so you do, silly me - missed it on the list. Fingers crossed we all see it again next year :fingers:
-
What model is your bt modem? - if it's a HG model you can unlock it easily.
Unfortunately its an ECI
-
If you fancy a challenge you can unlock it with the help of this thread. I did a couple of my own and it's not too bad once you have the board talking to your pc/laptop etc
http://forum.kitz.co.uk/index.php/topic,15918.0.html
-
If you fancy a challenge you can unlock it with the help of this thread. I did a couple of my own and it's not too bad once you have the board talking to your pc/laptop etc
http://forum.kitz.co.uk/index.php/topic,15918.0.html
Thanks for the tip, however, that is way out of my comfort zone!
;D
-
Happy to help if you want to sort it :)
-
Mine still has it (ayeaye on MDWS) with the HG612.
Was offline for a while in reporting stats as the box I was using needed rebuilding and I forgot all about stats.
Hi Esb
As you have retained your eci g.inp ever since it was introduced back in 2016 what firmware version is your cab on please?
Wondered if you might see a change on the firmware version as you have a working version of g.inp currently..
Thanks
-
Hi Esb
As you have retained your eci g.inp ever since it was introduced back in 2016 what firmware version is your cab on please?
Wondered if you might see a change on the firmware version as you have a working version of g.inp currently..
Thanks
206 I believe. Has been constantly enabled even when swapping modems around and still have BT TV even though never use it - like having G.INP and until its confirmed working for all I'm leaving things alone!
-
Just to bump this thread :)
Migrated from BT to Sky Fibre this week and finally lost G.INP (connected to ECI cabinet). Line started as interleaved when migrated on Monday, was removed early hours Wednesday morning.
A good run on G.INP/ECI, no doubt will be back to fastpath / interleaved / fastpath swings as used to see.
Still, this could just be temporary as City Fibre is allegedly coming to our area so 1Gbps full fibre is tempting (even if it is with Vodafone).