|
|
I was wondering if anyone is privy to the development of this issue?
Last I heard, BT said that ECI haven't released a new firmware for ECI cabinets to support G.INP yet.
|
|
|
Yes, they haven't and I don't think they will.
BT Openreach have helpfully turned off G.INP on the upstream for everyone to mask their buddies, BT Consumer, problems with the HH5A's.
Update
Wednesday 10:36:31 Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
Edited by deleted (Fri 05-Jun-15 17:12:52)
|
|
|
Yes, they haven't and I don't think they will.
BT Openreach have helpfully turned off G.INP on the upstream for everyone to mask their buddies, BT Consumer, problems with the HH5A's.
Update
Wednesday 10:36:31 Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
Disappointing
I wonder what genius at BT decided to buy thousands of cabinets that don't support G.INP.....
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
I wonder what genius at BT decided to buy thousands of cabinets that don't support G.INP..... It hadn't occurred to them that it would ever be useful. That's assuming they'd even heard of it.
|
|
|
I wonder what genius at BT decided to buy thousands of cabinets that don't support G.INP.....
Probably the same one that that made sure they didn't support vectoring either. 
|
|
|
|
I think the issue is that the current firmware levels for ECI, in both DSLAMs and modems, only supports G.INP downstream. However, lines on ECI cabinets have not, as yet, been allowed to change to G.INP-friendly profiles. Deliberately.
It looks like someone (probably a lot of someones) at BT miscalculated the impact of ECI modems on Huawei cabinets -perhaps believing the ECI modems only existed on ECI cabinets. Result: carnage.
This miscalculation was discovered at the end of the Huawei cabinet rollout, but before the ECI cabinet rollout. Unsurprisingly, the ECI cabinet rollout got stopped (paused, at minimum), until the situation could be dealt with.
Now they've rolled out a workable fix for those users affected by the Huawei rollout, they're probably in a position to understand whether further changes are needed prior to an ECI rollout.
|
|
|
I wonder what genius at BT decided to buy thousands of cabinets that don't support G.INP.....
Probably the same one that that made sure they didn't support vectoring either.
Probably doesn't matter now, as G.fast looks to be preferred.
|
|
|
It looks like someone (probably a lot of someones) at BT miscalculated the impact of ECI modems on Huawei cabinets -perhaps believing the ECI modems only existed on ECI cabinets. Result: carnage.
I think BTO must also have a large job lot of ECI modems, everyone around here who has had FTTC enabled has been given the ECI modem. And we are all on Huawei cabinets.
PlusNet BBYW1
|
|
|
|
The installers were giving out ECI modems and selling the Huawei modems on Ebay.
|
|
|
I think the issue is that the current firmware levels for ECI, in both DSLAMs and modems, only supports G.INP downstream. However, lines on ECI cabinets have not, as yet, been allowed to change to G.INP-friendly profiles. Deliberately.
It looks like someone (probably a lot of someones) at BT miscalculated the impact of ECI modems on Huawei cabinets -perhaps believing the ECI modems only existed on ECI cabinets. Result: carnage.
This miscalculation was discovered at the end of the Huawei cabinet rollout, but before the ECI cabinet rollout. Unsurprisingly, the ECI cabinet rollout got stopped (paused, at minimum), until the situation could be dealt with.
Now they've rolled out a workable fix for those users affected by the Huawei rollout, they're probably in a position to understand whether further changes are needed prior to an ECI rollout.
This sounds encouraging, though as the weeks/months go by without any updates, it looks like the ECI cabinets will never be updated to support G.INP.
Perhaps the ECI DSLAMS cannot support G.INP properly due to a hardware limitation? Surely BT would have requested a software update from them by now etc.
|
|
|
This sounds encouraging, though as the weeks/months go by without any updates, it looks like the ECI cabinets will never be updated to support G.INP.
Perhaps the ECI DSLAMS cannot support G.INP properly due to a hardware limitation? Surely BT would have requested a software update from them by now etc.
BT Wholesale provided ISPs with an update at the end of last month.
According to ISP Review they said:
FTTC/VDSL Vectoring
BT indicates that we might see a wider deployment of VDSL (FTTC) Vectoring technology, which is designed to improve broadband performance by combating cross-talk interference on copper lines. So far VDSL Vectoring has only been deployed in a very limited and selective way (here), although the latest update states that Openreach are now expecting a second DSLAM vendor enablement to happen �soon�, although BTWholesale is still awaiting a �deployment plan�.
which has been taken by some to refer to G.INP as well (the second DSLAM vendor = ECI) - though I think the real focus in future will be on G.Fast..
|
|
|
This sounds encouraging, though as the weeks/months go by without any updates, it looks like the ECI cabinets will never be updated to support G.INP.
Perhaps the ECI DSLAMS cannot support G.INP properly due to a hardware limitation? Surely BT would have requested a software update from them by now etc.
BT Wholesale provided ISPs with an update at the end of last month.
According to ISP Review they said:
FTTC/VDSL Vectoring
BT indicates that we might see a wider deployment of VDSL (FTTC) Vectoring technology, which is designed to improve broadband performance by combating cross-talk interference on copper lines. So far VDSL Vectoring has only been deployed in a very limited and selective way (here), although the latest update states that Openreach are now expecting a second DSLAM vendor enablement to happen �soon�, although BTWholesale is still awaiting a �deployment plan�.
which has been taken by some to refer to G.INP as well (the second DSLAM vendor = ECI) - though I think the real focus in future will be on G.Fast..
Thanks for the update.
I wasn't aware vectoring was enabled on Huawei cabinets - is this really the case?
|
|
|
my ECI cabinet got upgraded this morning from 204 to 206 chipset version.
So looks like they rolling something out now.
No sign of g.inp or vectoring tho, just the chipset change.
|
|
|
I wasn't aware vectoring was enabled on Huawei cabinets - is this really the case?
As ISP Review puts it 'in a very limited and selective way' - as in they its in at least 100 cabinets but thats a very small %
ECI equipment - well the chipsets which are made by lanqiq(owned by Intel - support G.INP but BT had previously said they weren't happy enough with the quality of the firmware available to roll it out.
New versions will take a (long) while to approve and deploy by BT but it sounds as if progress is being made.
|
|
|
my ECI cabinet got upgraded this morning from 204 to 206 chipset version.
So looks like they rolling something out now.
No sign of g.inp or vectoring tho, just the chipset change.
Thanks for the reply.
Is this where I view the cabinet chipset version in the line stats? Here's mine:
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
So looks like my cabinet is on v204 - hopefully mine will get the update too in the coming weeks
|
|
|
I wasn't aware vectoring was enabled on Huawei cabinets - is this really the case?
As ISP Review puts it 'in a very limited and selective way' - as in they its in at least 100 cabinets but thats a very small %
ECI equipment - well the chipsets which are made by lanqiq(owned by Intel - support G.INP but BT had previously said they weren't happy enough with the quality of the firmware available to roll it out.
New versions will take a (long) while to approve and deploy by BT but it sounds as if progress is being made.
Ah great, thanks again for the information
|
|
|
I wasn't aware vectoring was enabled on Huawei cabinets - is this really the case?
As ISP Review puts it 'in a very limited and selective way' - as in they its in at least 100 cabinets but thats a very small %
ECI equipment - well the chipsets which are made by lanqiq(owned by Intel - support G.INP
Do you have any evidence that lanqiq(owned by Intel - support G.INP ?
|
|
|
Back in January last year, Huawei anounced 'SuperVectoring' trial using 35Mhz instead of the usual 17Mhz frequency band.
Can't find the article, but they were getting something around 100Mb well past 800 metres distance.
Prehaps it's this which is about to make an apperance.
Edited by Nightglow (Fri 05-Feb-16 00:39:31)
|
|
|
35MHz or 30MHz? VDSL2 stops at 30.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
Do you have any evidence that lantiq(owned by Intel) - support G.INP ?
Both the HH5A and T-Link TD-W990 use the same Lantiq VRX-268 modem chipset.
TP-Link issued new firmware in May 15 enabling the TD-W990 to work properly on G.INP lines . From their firmware notes:
Fixed the bug that the speed dropped on the BT line of UK when G.INP was enabled.
Edited by gt94sss2 (Fri 05-Feb-16 02:43:50)
|
|
|
35MHz or 30MHz? VDSL2 stops at 30.
There is a 35b profile - sometimes called Vplus or VDSL+. Its basically a supercharged 30a vectored line.
It has some advantages for telco's but at shorter distances, G.Fast outperforms it (and from memory - I don't think the two play well together)
I don't think OR could roll it out even if they wanted to atm - due to the frequency plan - but they prefer G.Fast anyway.
|
|
|
Do you have any evidence that lantiq(owned by Intel) - support G.INP ?
Both the HH5A and T-Link TD-W990 use the same Lantiq VRX-268 modem chipset.
TP-Link issued new firmware in May 15 enabling the TD-W990 to work properly on G.INP lines . From their firmware notes:
Fixed the bug that the speed dropped on the BT line of UK when G.INP was enabled.
The problem is we are talking about cabinets not modems 
|
|
|
35MHz or 30MHz? VDSL2 stops at 30.
There is a 35b profile - sometimes called Vplus or VDSL+. Its basically a supercharged 30a vectored line.
It has some advantages for telco's but at shorter distances, G.Fast outperforms it (and from memory - I don't think the two play well together)
I don't think OR could roll it out even if they wanted to atm - due to the frequency plan - but they prefer G.Fast anyway.
Can't find orginal article, but I did find this.
http://gfastnews.com/
http://gfastnews.com/index.php/90-r/139-supervector-...
|
|
|
That's good, thanks.
BT must know about that, I wonder if they have ruled it out for now. Has anyone heard of any Openreach trials, as G.FAST seems to be favourite at the moment and if I read the first article correctly this replaces that?
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
Edited by RobertoS (Fri 05-Feb-16 09:46:55)
|
|
|
G.Fast might just be a red herring, & BT have been beavering away on SuperVector technology, a 100 Mbit/s within 800 m (2624') just short of half a mile, without requiring network restructuring must be tempting.
Edited by Nightglow (Fri 05-Feb-16 10:26:08)
|
|
|
BT have been beavering away I assume you are joking.
|
|
|
G.Fast might just be a red herring, & BT have been beavering away on SuperVector technology, Link please? a 100 Mbit/s within 800 m (2624') just short of half a mile, without requiring network restructuring must be tempting. Which was behind what I posted. If your post is just conjecture with no source, rather than the "fact" you present, G.FAST is looking like the way they are going. Instead of (for the moment) any form of vectoring. Though the last time I looked they were saying modems must be vectoring-capable.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
G.Fast might just be a red herring, & BT have been beavering away on SuperVector technology, Link please?a 100 Mbit/s within 800 m (2624') just short of half a mile, without requiring network restructuring must be tempting. Which was behind what I posted. If your post is just conjecture with no source, rather than the "fact" you present, G.FAST is looking like the way they are going. Instead of (for the moment) any form of vectoring. Though the last time I looked they were saying modems must be vectoring-capable.
Sadly, it's just conjecture, but there a old saying, there is no smoke without fire...
Vectoring would achieve a lot more, but we will just have to wait & see what happens in the coming months...
|
|
|
|
There's still the issue of ECI DSLAMs not supporting vectoring unless there are any V41's out there.
|
|
|
|
Well I can tell you what hey are saying internally matches what the statements externally say. It IS all about G.Fast now. Trials are ongoing and are going well and more people are being added to the trials
|
|
|
Looks like ECI G.INP is being rolled out! (On the downstream):
User on kitz reporting his ECI powered FTTC connection resynced to apply G.INP:
http://forum.kitz.co.uk/index.php?topic=17195.0
Hopefully the rollout won't take too long, can't wait to see what it does to my line 
|
|
|
Yes, they haven't and I don't think they will.
BT Openreach have helpfully turned off G.INP on the upstream for everyone to mask their buddies, BT Consumer, problems with the HH5A's.
Update
Wednesday 10:36:31 Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
Disappointing
I wonder what genius at BT decided to buy thousands of cabinets that don't support G.INP.....
maybe that one genius with the gob, Neil mcrae according to google .He is Managing Director and Chief Architect., was he the one that thought packet loss was normal/acceptable?
Edited by tommy45 (Sun 06-Mar-16 21:00:36)
|
|
|
Do you have any evidence that lantiq(owned by Intel) - support G.INP ?
Both the HH5A and T-Link TD-W990 use the same Lantiq VRX-268 modem chipset.
TP-Link issued new firmware in May 15 enabling the TD-W990 to work properly on G.INP lines . From their firmware notes:
Fixed the bug that the speed dropped on the BT line of UK when G.INP was enabled.
lets not forget that other BTOR supplied POS that isnt G.inp compatible the ECI modem that was supplied /installed by OR on many Huawei FTTC cabs, and then you have BT publish even more BS in their SIN documents about testing/ approving modem devices when they have supplied thousands of un tested in compatible devices themselves, it's like the blind leading the blind in BT
ECI cabs will never see G.inp (US+DS) and i doubt that BT will ever roll-out vectoring on a national scale, G.fast maybe, maybe not as again they would have to supply modems capable of g.fast speeds, and knowing BT they would get that wrong also
Edited by tommy45 (Sun 06-Mar-16 20:58:14)
|
|
|
Looks like ECI G.INP is being rolled out! (On the downstream):
User on kitz reporting his ECI powered FTTC connection resynced to apply G.INP:
http://forum.kitz.co.uk/index.php?topic=17195.0
Hopefully the rollout won't take too long, can't wait to see what it does to my line they where able to do this early last year or year before that (ECI modems. although was questionable) , but they cannot enable it on the upstream on the ECI modems or cabs without a hardware upgrade at cab level, and a firmware update of the eci modems, as it stands it's borked in some way or other for most of us
Edited by tommy45 (Sun 06-Mar-16 20:57:16)
|
|
|
Looks like ECI G.INP is being rolled out! (On the downstream):
User on kitz reporting his ECI powered FTTC connection resynced to apply G.INP:
http://forum.kitz.co.uk/index.php?topic=17195.0
Hopefully the rollout won't take too long, can't wait to see what it does to my line they where able to do this early last year or year before that (ECI modems. although was questionable) , but they cannot enable it on the upstream on the ECI modems or cabs without a hardware upgrade at cab level, and a firmware update of the eci modems, as it stands it's borked in some way or other for most of us
G.INP has been disabled on ECI cabinets for a very long time.
I'm aware this is only for downstream, thats why I mentioned it in my post.
It's stil very good news that BT are finally rolling out downstream G.INP for those on ECI cabinets.
|
|
|
It's stil very good news that BT are finally rolling out downstream G.INP for those on ECI cabinets. Allegedly
|
|
|
It's stil very good news that BT are finally rolling out downstream G.INP for those on ECI cabinets. Allegedly
Nope, confirmed. He has uploaded his line stats.
https://www.mydslwebstats.co.uk/
|
|
|
|
Line stats can be faked
|
|
|
Line stats can be faked
Prepare to be proved wrong...
|
|
|
|
So, you can prove line stats can't be faked? Anyway one swallow doesn't make a summer.
|
|
|
Keep on digging mate.
http://forum.kitz.co.uk/index.php/topic,15921.msg315...
Edited by deleted (Sun 06-Mar-16 21:36:12)
|
|
|
|
Start your proof anytime....
|
|
|
Line stats can be faked
Prepare to be proved wrong...
Glad there's someone else with a brain here, who can see his stats uploaded to www.mydslwebstats.co.uk
|
|
|
|
You only have to fake them in DSLStats which will then upload them to MDWS.
|
|
|
Looks like ECI G.INP is being rolled out! (On the downstream):
User on kitz reporting his ECI powered FTTC connection resynced to apply G.INP:
http://forum.kitz.co.uk/index.php?topic=17195.0
Hopefully the rollout won't take too long, can't wait to see what it does to my line they where able to do this early last year or year before that (ECI modems. although was questionable) , but they cannot enable it on the upstream on the ECI modems or cabs without a hardware upgrade at cab level, and a firmware update of the eci modems, as it stands it's borked in some way or other for most of us
G.INP has been disabled on ECI cabinets for a very long time.
I'm aware this is only for downstream, thats why I mentioned it in my post.
It's stil very good news that BT are finally rolling out downstream G.INP for those on ECI cabinets.
I think the word disabled isn't the right term here, as ECI cabs were not G.inp compatible or still aren't, one reported case isn't really conclusive of any changes being made, if however other EU's that are connected to ECI cabs start to show G.inp active, then that would change things perhaps, but it was because of BT's ineptness that many on huawei cabs have lost out due to G.inp being disabled by default , because of the ECI blunder, so if they have finally got g.inp on eci cabs, when do the rest get g.inp enabled on the upstream again?
Edited by tommy45 (Sun 06-Mar-16 22:08:47)
|
|
|
I'd rather people not accuse me of lying/forgery just because their anti BT bias.
All I know is that Webstats says G.INP is active and that my actual sync increased by 3mbit.
Whatever you want from DSL Stats just ask for and I will provide.
Here's some Telnet stuff
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19237 Kbps, Downstream rate = 65888 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 62696 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.3
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: 16397 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 281477
OHFErr: 0 2
RS: 63275072 549198
RSCorr: 4 21
RSUnCorr: 0 0
Bearer 1
OHF: 122583 0
OHFErr: 0 0
RS: 1225214 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 9 0
rtx_c: 1 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 62660 0
errFreeBits: 1882405 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 237363544 0
Data Cells: 10274204 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 2
SES: 0 0
UAS: 30 30
AS: 1970
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19243 Kbps, Downstream rate = 65888 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 62696 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: 19243 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.1 N/A N/A 9.0 20.4 32.4
Signal Attenuation(dB): 0.1 14.7 23.1 N/A N/A 10.4 20.2 32.4
SNR Margin(dB): 8.0 6.6 6.2 N/A N/A 6.2 6.2 6.2
TX Power(dBm): -5.3 -40.8 3.1 N/A N/A 11.3 7.3 7.4
#
Edited by deleted (Mon 07-Mar-16 00:32:17)
|
|
|
|
|
|
|
IMG
That
Have reset once so
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19291 Kbps, Downstream rate = 65592 Kbps
Bearer: 0, Upstream rate = 16995 Kbps, Downstream rate = 62635 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.1 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.1240 0.4443
L: 16381 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 1973935
OHFErr: 0 20
RS: 982408304 497349
RSCorr: 58 196
RSUnCorr: 0 0
Bearer 1
OHF: 1904186 0
OHFErr: 0 0
RS: 19041245 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 52 0
rtx_c: 44 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 62629 0
errFreeBits: 29210473 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3684114170 0
Data Cells: 9808597 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 19
SES: 0 0
UAS: 34 34
AS: 30588
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: 62699.39 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: 7138/7251 0/0
Total time = 8 hours 30 min 22 sec
FEC: 58 196
CRC: 0 20
ES: 0 19
SES: 0 0
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 22 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 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 = 8 hours 30 min 22 sec
FEC: 58 196
CRC: 0 20
ES: 0 19
SES: 0 0
UAS: 34 34
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 = 8 hours 29 min 47 sec
FEC: 58 196
CRC: 0 20
ES: 0 19
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
|
|
|
Woohoo! Ratio is 0.9669 (with)
|
|
|
|
G.INP is ready to launch on ECI cabs in the next couple of months.
|
|
|
|
Lol. You're kidding, right?
|
|
|
Nope, deadly serious. Why? Haven't read the full thread so maybe I've missed something?
All I know is it will soon be deployed on all ECI cabinets.
Edited by deleted (Mon 07-Mar-16 13:13:29)
|
|
|
|
How do you know?
|
|
|
Nope, deadly serious. Why? Haven't read the full thread so maybe I've missed something? The last few posts have been about a user who has just had G.INP enabled on their ECI cabinet
|
|
|
Nope, deadly serious. Why? Haven't read the full thread so maybe I've missed something? The last few posts have been about a user who has just had G.INP enabled on their ECI cabinet
Ah, makes sense!
How do you know?
I just do. You'll have to trust me
|
|
|
If only you'd posted this on Friday... G.INP is ready to launch on ECI cabs in the next couple of months.
|
|
|
I just do. You'll have to trust me And it has already been rolled out to some is the bit you seem to be missing . We have seen a few now.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
|
I'm not missing anything! I'm just letting you know what I've been told. That's great that it's been rolled out to a few already but apparently it'll be rolled out to every single ECI cabinet soon.
|
|
|
|
In other news, the Tories will win the 2015 election.
|
|
|
|
|
|
|
In other news, the Tories will win the 2015 election.
Whatever....
I won't bother next time
|
|
|
|
Oh come on, I was joking - trust me.
|
|
|
Oh come on, I was joking - trust me.
You just don't know when to stop do you?
|
|
|
thanks for the info, I suspected it was coming as the ECI dslams are getting a new firmware (or card swap) rolled out.
Looks like the ECI configuration is different to hauwei in how its implemented.
|
|
|
|
Given you complained about losing a couple of hundred kilobits a second of downstream to the G.inp retransmit bearer perhaps better they keep it off.
BT aren't deploying vectoring on a national scale and have never suggested they would.
People are more likely to get FTTP or G.fast. Vectoring will go to a tiny subset of cabinets where it can push lines over 24 or 30Mb.
|
|
|
IIRC G.Fast employs vectoring by default doesn't it? At least the Openreach implementation.
The indispensable man or woman passes from the scene, and what happens next is more or less the same thing as was happening before.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
|
It is an integral part of the G.Fast standard.
However, as some of the uses cases involve a G.Fast node with a single port, supporting a single line, there are some cases where vectoring isn't necessary and, I imagine, can be left out of the chipset for cost reasons.
|
|
|
|
Given we're discussing ECI VDSL cabinets I didn't see the point in complicating the issue in the name of pedantry.
G.fast requires vectoring. There are no implementations that don't have it.
|
|
|
|
G.INP wasn't on the radar when the fibre rollout started so the modems didn't have to support it. I think G.INP first appeared in SIN498 v5(?).
|
|
|
|
Sin 498 (v4.3) January 2013 Requirement R.VDSL2.10 for downstream PHY Layer retransmission reinstated.
Sin498 (v5) June 2013 Requirement R.VDSL2.10 for downstream PHY Layer retransmission made mandatory.
Therefore any CPE supplied since June 2013 should support G.INP but the HH5 type A doesn't.
|
|
|
|
I've absolutely no idea if this is anything to do with anything but my max attainable has jumped by 6Mbit to the highest its been for a few years, the up stream has remained the same. This happened after Openreach were working on the cab.
HH 5 Type A to an ECI cab.
|
|
|
|
It's easy enough to check for G.INP.
Just get your IP Profile and your Sync Speed and then as it says in my sig,
Use the Ginp Formula to determine if your vdsl2 connection is with or without G.INP.
Divide your IP Profile by your Sync Speed and the answer is 0.9669 (with) or 0.9679 (without)
|
|
|
It's easy enough to check for G.INP.
Just get your IP Profile and your Sync Speed and then as it says in my sig,
That works on Huawei cabs - you can't assume it will also work on the ECI ones..
|
|
|
|
I can't see any reason why not.
|
|
|
We know the 0.9679 works on ECI as it applied before G.INP was introduced.
It is possible BT Wholesale have two separate parameters for calculating the IP Profile under G.INP depending on the cabinet being Huawei or ECI, but I think extremely unlikely. I'd be very surprised if that information is even presented to the BT Wholesale DLM.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
Edited by RobertoS (Thu 10-Mar-16 13:26:20)
|
|
|
We also know that the 0.9669 applies on an ECI cabinet with G.INP enabled
So it looks like we know everything. Case closed. Game over.
|
|
|
Ah yes, I forgot you have that now.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
no resync here since my cab had the chipset upgrade 35 days ago.
|
|
|
|
I was only 5 days in to the HH5 Type A reboot cycle and it has rebooted again this morning.
5. DSL uptime: 0 days, 05:44:34
6. Data rate: 20000 / 78639 lowest sync i have seen
7. Maximum data rate: 27611 lowest its ever been, not seen it below 33000 before / 108803 highest its been for years, although when the cab was empty it used to be 128000
|
|
|
no resync here since my cab had the chipset upgrade 35 days ago.
The user on the ECI cabinet who had G.INP enabled is still on the old chipset version (204), so sadly it's not an indication of an upcoming G.INP upgrade.
|
|
|
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
I'd say i'm jealous of the 206, but I have G.INP when they fully roll it out, then i'll start my complaints about how I have the old one .
|
|
|
It looks like someone (probably a lot of someones) at BT miscalculated the impact of ECI modems on Huawei cabinets -perhaps believing the ECI modems only existed on ECI cabinets. Result: carnage.
I think BTO must also have a large job lot of ECI modems, everyone around here who has had FTTC enabled has been given the ECI modem. And we are all on Huawei cabinets.
Funny you say that, I have never had anything but ECI no matter where I've done an install for someone. And all the ones I've "acquired" from engineers (which is coming in increasingly handy now they're in short supply) are ECI too!
|
|
|
since 206 is not a requirement for g.inp I have no idea what it the update fixes, I have observed no improvements to error or sync rates tho, so better to have 204 with g.inp than 206 without 
|
|
|
Three ECI users now have G.INP showing on https://www.mydslwebstats.co.uk/
|
|
|
Five now
Edited by deleted (Thu 17-Mar-16 11:51:39)
|
|
|
|
Its nice to see them finally deploying g.inp, does anyone know if it's going to be for all cabinets and as I am on pulse8 who are a talk talk business reseller would I also be able to get g.inp?
|
|
|
|
The cabinets are owned by Openreach so it should be on all cabinets soon.
Is your cabinet an ECI or a Huawei?
Does your modem support G.INP?
|
|
|
|
It was enabled on my line about 20 mins ago along with drop in sync.
|
|
|
My cabinet is ECI and I have a netgear D7000 router which looks to support vectoring and g.inp according to http://www.ispreview.co.uk/index.php/2016/01/2016-up...
Edited by deleted (Thu 17-Mar-16 12:11:05)
|
|
|
Yes, I think it does too. You should be good for G.INP when it gets rolled out to your cab
|
|
|
|
Just have to wait and see now as I am getting RSCORR errors up to 65% on some days (averaging 18% currently) so curious to see if G.INP could fix this.
|
|
|
It will be intresting to see what happens, although RSCORRS are corrections not errors
|
|
|
|
Yeah I know it's just that it was always around 2 to 3% or less since I moved to FTTC from VM and over the past 2 weeks it's jumped to 65% which seems like hell of a lot of corrections.
|
|
|
I checked them out, unlike hauwei users all ECI users seem to get a reduction in sync speed, so this is a different g.inp configuration with higher overheads than hauwei users who actually on average were getting increases in sync speeds.
|
|
|
Line stats can be faked
Hopefully the continued rollout of G.INP on ECI cabinets is enough proof to satisfy you, Batboy!
|
|
|
|
|
|
|
http://forums.thinkbroadband.com/fibre/t/4471176-eci...
Hmm, perhaps you don't recall your opinion when I first posted that the ECI rollout had commenced? I linked my source, a user on Kitz that had uploaded their DSL stats, line config etc.
Let me refresh your memory:
Allegedly
Line stats can be faked
So, you can prove line stats can't be faked? Anyway one swallow doesn't make a summer.
Start your proof anytime....
You only have to fake them in DSLStats which will then upload them to MDWS.
I'm glad you finally understand that G.INP is being rolled out on ECI cabinets.
|
|
|
|
Are you saying that you and Underzone are the same poster?
|
|
|
Are you saying that you and Underzone are the same poster?
No. Are you Underzone?
I'm simply highlighting your thoughts/responses when I first posted here about the user having G.INP enabled on an ECI cabinet.
It's rather entertaining to see how wrong some foolish people can be
|
|
|
I'm simply highlighting your thoughts/responses when I first posted here about the user having G.INP enabled on an ECI cabinet. I was wondering why you conflated 2 separate conversations It's rather entertaining to see how wrong some foolish people can be Whatever.
I'll be happier when the ECI modem and the HH5A support G.INP now
|
|
|
|
so 5 yesterday how many today get activated I wonder...and don't you think guys it's a bit too early to tell if eci cabinets enabled with g.inp mean a loss of sync speed?
|
|
|
|
Yes, definitely too early. The results from yesterday were 3 faster, 2 slower on the downstream sync and 2 slower, 3 the same on the upstream sync. But the differences were tiny.
What really matters is the throughput and the quality of the data stream, how many errors are occurring.
How is streaming affected, how is gaming affected. That sort of thing.
|
|
|
|
Mine went g.inp yesterday morning. I lost some sync speed on up and down but the latency has improved massively from pre g.inp of 20ms to around 11/12ms after g.inp. tested my ps4 last night seemed better on a hard wired connection to the router.
Mydsl user "skyeci"
|
|
|
|
Max attainable rate seems to be slower at the cabinets when g.inp is enabled. 99Mb as opposed to 137 or 155Mb on a recent example I've seen. I've only dealt with Huawei cabinet so far though.
|
|
|
|
That's probably due to interleaving being removed
|
|
|
|
According to the kitz forums MikeZ has joined the party
|
|
|
I ignored those that were on interleaving before the move to g.inp, the one's that were on fast path had a hit on sync speed.
|
|
|
not sure why wombat wont post it here but here is a quote from his explanation of overhead used.
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.
Now I checked baldeagle's stats and his also has the FEC overheads, so the FEC overheads are not unique to ECI cabinets, what is different is that the hawuei cabinets had a speed bump which masked these FEC overheads, whilst the ECI cabinets did not. So sadly us ECI users are on the second rate service but this is at least something, great for those on interleaved lines.
Given my current sync of 72mbit (which I think with the slight snrm drop I have had in the past month would probably resync at 71 to 71.5 range on fast path), I expect a sync speed of approx 68.8mbit on the ECI g.inp configuration, assuming I am on the lightest profile.
Edited by Chrysalis (Sat 19-Mar-16 19:18:14)
|
|
|
|
I think he's too busy at home at the moment actually.
|
|
|
My ECI cabinet started to support G.INP today..
I have two FTTC lines both on fastpath.
The first line got G.INP'd and increased it's sync speed from 66Mb to 68Mb.
My second line (with a HH5a) restarted a few hours later and increased it's sync speed from 61Mb to 65Mb! No G.INP (as confirmed by sync speed calculation) and on still on fastpath.
I don't understand!
Thanks
Tim
Plusnet unlimited FTTC load balanced with BT Infinity 2 and BT TV
|
|
|
|
The HH5A doesn't support G.INP.
|
|
|
|
Is there any criteria for G.INP to be enabled? i.e DLM, FEC error count etc.
|
|
|
That's probably due to interleaving being removed
Could you explain what you mean? You've lost me there a bit. Interleaving wasn't enabled, it was a fresh port as far as I can remember. Just relaying what I was told that the max attainable speed was lower due to "retransmission being enabled".
Removing interleaving increases the sync speed, that's why I'm confused by your comment.
|
|
|
|
Mine went G.INP this morning just after 8am.
I'm not really sure if it affected attainable rates as I've always been pegged at max sync, and the situation is more murky due to it being a brand new cab installed last week after a car crashed into the old one.
BTOR have been working on it every day causing drops and all sorts of other issues. My attainables have been jumping all over the place, from 95-115mbit. Right now seems settled at 101mbit.
Only thing I can see for sure has changed due to G.INP coming on is my latency has gone up by ~3ms. Back in my online gaming days I'd be furious about such a huge (!) increase in latency.. but now.. meh.
|
|
|
|
Interleaving has a side effect of increasing max attainable. Obviously, if there's no interleaving applied it's not that. Maybe retransmission does decrease the max attainable, but the max attainable is mostly irrelevant anyway.
|
|
|
|
24 hours ago my VDSL connection dropped. It was 68/16, now it's 73/16:
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 73350000 bps US Actual Rate : 16613000 bps
DS Attainable Rate : 73590208 bps US Attainable Rate : 16722588 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 : 5 dB
DS actual PSD : 6. 7 dB US actual PSD : 13. 9 dB
NE CRC Count : 20 FE CRC Count : 2909
NE ES Count : 14 FE ES Count : 2711
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
|
|
|
|
Which modem/router model are you using Reado?
|
|
|
What does it mean when interleave is set at 1? my line was recently fixed and dlm reset was done and my interleave is 1, with speeds higher than they have ever been
Edited by zebo (Tue 22-Mar-16 10:22:14)
|
|
|
|
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?
|
|
|
Which modem/router model are you using Reado?
I'm using the DrayTek 2860ac with the latest firmware (3.8.2.2_VT3) which supports Vectoring and G.INP.
|
|
|
for those updating here, please confirm when saying sync speed changes if line was previously interleaved or fast path thanks.
|
|
|
|
My line seemed worse off than most. I had 2 re-syncs and ended up near on a 3mb loss on the upstream with delay and interleaving.
I had bt or out yesterday and showed him the stats fron pre and post g.inp. was worse off post g.inp
Agreed to put me on new pair either end and reset my line to see if it helps.
Now ds is higher than before along with us back to where it was. Snrm is much better as I think I am now away from my neighbour that was giving me crosstalk issues. Profile was reset and g.inp is now off.
Will see how things pan out from here.
In case anyone wants to look it up on mydsl, user=skyeci
|
|
|
|
My ECI cabinet was G.INP - enabled yesterday morning. Four years ago, my max attainable speed was 104000 kbits/sec which progressively fell to 84000kbits/sec. Following yesterday's intervention, my downstream speed is now showing max attainable of 88000 kbits/sec with an INP figure of 42, SNR of 8/9 and line attenuation of 12/11. Downstream bit swap is on/ upstream bit swap is off. Twenty four hours + on, the downstream error counter is showing no errors (ES, SES or CRC).
My FTTC is connected to a Fritz!Box 7490 using Fritz!OS 113.06.36-31667 Beta.
|
|
|
|
Without meaning to go off topic, how did you get the beta? I'm interested in trying that version on my Fritz!Box 7490 as it might fix a few problems around my usage of multiple public static IP's, when I originally used the device that is.
Can't wait until the ECI cabinet I'm connected to is G.INP, fed up with traditional interleaving.
Thanks in advance.
|
|
|
Without meaning to go off topic, how did you get the beta? I'm interested in trying that version on my Fritz!Box 7490 as it might fix a few problems around my usage of multiple public static IP's, when I originally used the device that is.
Can't wait until the ECI cabinet I'm connected to is G.INP, fed up with traditional interleaving.
Thanks in advance.
ftp://service.avm.de/Beta/FRITZ!Box_7490/english/fri...
Lovely interface and stable as a rock. Should be out of Beta very soon according to Whirlpool.net.au
|
|
|
|
It's locked, I tried that earlier. Do I need to email AVM and hope they can provide a login?
|
|
|
What does it mean when interleave is set at 1? That is Fast Path. In simple terms, the interleave depth is how many packets a normal data packet is spread across - i.e. interleaved with data from other packets. If it's 1 then the packet is by definition not interleaved.
See this more detailed explanation.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59504/15641kbps @ 600m. - BQM
|
|
|
The HH5A doesn't support G.INP.
Some users seem to think that it does, but I haven't seen conclusive proof.
However, I have seen stats from an unlocked ECI modem, connected to an ECI cabinet that shows G.INP on DS only:-
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
| Line Mode: G.993.2 (VDSL2) � Annex B � Profile 17a
Status & Uptime: UP � 10h 31m 52s � Resyncs: 3Line State:showtime_tc_sync [0x801]
Power Mode: L0 - Synchronized
Downstream � UpstreamAttainable Line Speed:66.090 Mb/s � 28.269 Mb/s
Actual Line Speed: 66.384 Mb/s � 20.000 Mb/sTrellis: D: ON � U: ON
Bitswap: D: ON � U: ON***G.INP: D: Enabled � U: Not Enabled***
Virtual Noise Support: D: Not Supported � U: Not SupportedInterleave Depth: 1 � 1
Interleave Block: 32 � 255Interleave Delay: 0.21 ms � 0.0 ms
INP: 44.0 � 0.0 NFEC: 32 � 255
RFEC: 16 � 16LSYMB: 16 � 5410
LPATH: 0 � 0Line Attenuation: 14.3 dB / 14.1 dB
Noise Margin/SNR: 5.1 dB / 11.9 dBTransmit Power: 6.0 dBm / 5.8 dBm
Errors Since Line Up
FECS: 0 � 76 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 � 1 FECS: 0 � 3
Errors in 1 Day
Code Violations: 2 � 4 FECS: 0 � 46 |
FYI, I have been working closely with the user to develop initial scripts to harvest the data from ECI modems & ultimately convert them to programs to work with the HG612 Modem Stats graphing programs, so I do know first hand that this is genuine information.
Edited by deleted (Sun 27-Mar-16 16:22:17)
|
|
|
|
Well, that's good to hear. There's no doubt the ECI modem and HH5A are hardware capable of supporting G.INP but the question is whether BT have released the firmware needed to enable this.
My HH5A doesn't use G.INP on my Huawei cabinet whereas my HH5B does.
Is this ECI modem running the supplied BT firmware or is it running a 3rd party firmware?
|
|
|
|
It has OpenWRT on it, a version named Chaos Calmer.
I don't know if it would have managed G.INP with stock BT firmware etc.
|
|
|
|
Not related to G.INP but there's a trial starting early April in some parts of the UK on FTTC circuits regarding SNR levels which will increase speeds. That's all I can say, you can probably figure out what I mean.
|
|
|
|
3db?
|
|
|
|
|
|
|
Oooh.
IIRC, BT figures after activation of G.INP for Huawei cabs were that 60% of lines went error-free. I guess that meant they had a zero ES total per day.
This probably allows them to drop SNR in exchange for an increase in errors - which can still be coped with by retransmission. I'd imagine they could make this exchange dynamically through DLM, and I don't see why they'd have to move the target in increments of 3dB either.
Vice-versa would be true too: increase SNR in exchange for a decrease in errors.
Edit: old rule-of-thumb data I had calculated a year ago...
My rule of thumb for what an extra 3dB of noise margin is worth in the downstream direction:
- For speeds around 20Mbps, 3dB is worth 3Mbps
- For speeds around 40Mbps, 3dB is worth 6Mbps
- For speeds of 60Mbps or more, 3dB is worth 11Mbps.
The figures comes from using the 3dB to buy one extra bit on each tone. If that can happen across all downstream tones (about 2750 tones), it buys 11Mbps.
Edited by deleted (Mon 28-Mar-16 21:10:15)
|
|
|
I said a year ago they could probably now rollout 3db profiles with g.inp. But god BT are slow.
I havent even got g.inp yet (still waiting a 14 months after they started hauwei rollout).
It took them a year to announce this trial for 3db.
I can only assume this is only hauwei cabinets as they will probably need a year to decide to do it for ECI as well.
Do you think adsl power cutback tones will still gain a bit?
Edited by Chrysalis (Tue 29-Mar-16 06:03:56)
|
|
|
Yes, there's no need to move in 3dB increments.
Who said anything about Huawei only? I just thought the people in this thread would appreciate the news.
Edited by deleted (Tue 29-Mar-16 07:59:04)
|
|
|
I would assume its hauwei only at this point as they have not much data on ECI cabinets, but if no issues then I would expect ECI to get next year.
|
|
|
Maybe just take the hint from my last post
|
|
|
That's great news, thanks for sharing
|
|
|
I know the feeling. I'm still waiting for G.INP too, will be glad to see the back of traditional interleaving soon hopefully. 3dB SNRM is also an impressive step forward, pity it can't currently be for both upstream and downstream though (as upstream doesn't get G.INP). Still, it's something good to look forward to eventually. I seriously doubt ECI will get second class service this time as it's just a change in SNRM target. If it wasn't for the fact that DLM limits the maximum sync rate instead of adjusting the SNRM I could override the DSLAM's default downstream SNRM target of 6dB to a downstream SNRM target of 3dB when G.INP is enabled .
EDIT: 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.
Edited by Ixel (Tue 29-Mar-16 11:20:52)
|
|
|
still waiting here.
sods law I be the last one on any forums to get it.
|
|
|
No G.INP (as confirmed by sync speed calculation) and on still on fastpath.
I don't understand!
Thanks
Tim
Not quiet sure why the 'calculation' from Huawei's G.INP rollout would be correct on ECI... specially based on the difference's between the 2 rollouts...
Was your HH5a Interleaved before the restart?
The rollout of G.INP on ECI cabs has revealed that modems pick up the interleaving typoe as fast path where us on Huawei cabs with G.INP have a Interleaved Path type.
|
|
|
|
Post deleted by mlmclaren
|
|
|
Interesting post. Thanks.
Was your HH5a Interleaved before the restart?
Before the restart my HH5a was on fast path. I believe it's still on fast path based on the 6ms ping.
Sync speed for my 8800NL went from 55Mb (no GINP and fastpath) to 61Mb (with G.INP and fastpath) as confirmed by the 8800NL's GUI. The HH5a synced at 61Mb before GINP and now manages near 65Mb. I can only conclude that my HH5a has G.INP enabled on the downstream.
Plusnet unlimited FTTC load balanced with BT Infinity 2 and BT TV
|
|
|
Before the restart my HH5a was on fast path. I believe it's still on fast path based on the 6ms ping.
Sync speed for my 8800NL went from 55Mb (no GINP and fastpath) to 61Mb (with G.INP and fastpath) as confirmed by the 8800NL's GUI. The HH5a synced at 61Mb before GINP and now manages near 65Mb. I can only conclude that my HH5a has G.INP enabled on the downstream.
I thought that was the case and yes exactly what you have said about the HH5a is what I've witnessed with the HH5a too, So I too believe that the G.INP has been enabled on both your connections.
Thanks for sharing
|
|
|
PS. does the following apply to both or either of your connections?
Use the G.inp Formula to determine if your vdsl2 connection is with or without G.INP.
Divide your IP Profile by your Sync Speed and the answer is 0.9669 (with) or 0.9679 (without)
|
|
|
Doesnt look mine has yet, heres my stats
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7101 Kbps, Downstream rate = 35364 Kbps
Bearer: 0, Upstream rate = 7157 Kbps, Downstream rate = 35388 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.0 6.0
Attn(dB): 26.5 0.0
Pwr(dBm): 11.4 3.4
VDSL2 framing
Bearer 0
MSGc: 19 33
B: 239 224
M: 1 1
T: 64 5
R: 0 16
S: 0.2158 0.9995
L: 8896 1929
D: 1 1
I: 240 241
N: 240 241
Counters
Bearer 0
OHF: 230028810 558180
OHFErr: 12830315 1135
RS: 0 806669
RSCorr: 0 3697
RSUnCorr: 0 0
Bearer 0
HEC: 1661579 0
OCD: 1330 0
LCD: 1330 0
Total Cells: 2727805388 0
Data Cells: 4049460110 0
Drop Cells: 0
Bit Errors: 0 0
ES: 703412 856
SES: 3962 0
UAS: 230 23
AS: 797377
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.46 16.30
OR: 57.69 19.13
AgR: 35445.54 7175.70
Bitswap: 376942/377007 633/650
Total time = 9 days 5 hours 33 min 38 sec
FEC: 0 3697
CRC: 12830315 1135
ES: 703412 856
SES: 3962 0
UAS: 230 23
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 38 sec
FEC: 0 0
CRC: 3882 0
ES: 218 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 2
CRC: 17708 0
ES: 900 0
SES: 6 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 33 min 38 sec
FEC: 0 55
CRC: 333910 18
ES: 19721 12
SES: 36 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 421
CRC: 1214226 137
ES: 84242 108
SES: 288 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 9 days 5 hours 33 min 13 sec
FEC: 0 3697
CRC: 12830315 1135
ES: 703412 856
SES: 3962 0
UAS: 207 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
I had a dlm reset 10 days ago, nothings changed since then i had a massive boost from 25000 kbps to now what you can see in my stats after a line fix, any idea if these will be changed by dlm and if my errors are ok anyone?
Edited by zebo (Tue 29-Mar-16 17:49:46)
|
|
|
PS. does the following apply to both or either of your connections?
Use the G.inp Formula to determine if your vdsl2 connection is with or without G.INP.
Divide your IP Profile by your Sync Speed and the answer is 0.9669 (with) or 0.9679 (without)
Some one pointed out this thread to me last night.
That formula has been proven not to work for the ECI modem /modems capable of downstream G.INP only on both Huawei and ECI cabs. They also appear to get slightly different framing parameters.
According to Openreach's Chief Engineer both the ECI modem and HH5A performs retransmission in the downstream direction only.
I specifically asked about the ECI modems & HH5A's. Ian surely would not have been prepared to put his name against something if it wasn't correct. - See Question 3 here.
If you have an ECI modem/ HH5A you cant use the IPprofile method regardless of type of DSLAM as proof 
Its not always much use measuring speeds between different modem types either. For example on my own line the VRX-268 chipset gives me 3Mbps less than the BCM6368 which in turn gives me 3.5Mbps less than one using a BCM63168. It's a known fact that most lines will see speed differentials based on the type of chipset in use.
|
|
|
Thank you very much kitz.... I thought this was the case, Hopefully this will be satisfactory for those insistent on stating otherwise.
Edited by mlmclaren (Tue 29-Mar-16 18:23:33)
|
|
|
According to Openreach's Chief Engineer both the ECI modem and HH5A performs retransmission in the downstream direction only.
I specifically asked about the ECI modems & HH5A's. Ian surely would not have been prepared to put his name against something if it wasn't correct. - See Question 3 here. As you note above, to comply with SIN 498, modems and routers must support retransmission in the downstream Does the HH5A comply with SIN 498?
|
|
|
You already quoted the answer to that question
According to Openreach's Chief Engineer both the ECI modem and HH5A performs retransmission in the downstream direction only.
|
|
|
You already quoted the answer to that question
According to Openreach's Chief Engineer both the ECI modem and HH5A performs retransmission in the downstream direction only. That simply repeats Openreach's assumption that the HH5A supports G.INP, however I have already provided proof that it does not.
Does the HH5A comply with SIN 498?
|
|
|
|
|
|
|
This mythical proof you speak of.... knowone's yet witness it??
|
|
|
I have, and you
|
|
|
I'm curious how you could have proved it. I don't usually read these forums and was only directed to this thread because of a certain post, so apologies if you have already have said, but from a quick scan of the whole thread I couldn't see anything.
AFAIK there isnt any way an EU can determine themselves if their line has g.inp based on any information that they can get from the HH5A.
- The IPprofile % method doesnt work.
- You cant use speed compared against another modem. I get 6.5 Mbps more using a BCM chipset compared to a VRX268 chipset.
- Most lines see speed differentials depending on modem/chipset type.
Openreach have stated that the HH5A meets requirements of SIN 498 which only requires G.INP in the downstream direction.
If the modem is incapable of G.INP in both directions, then you should not be able to obtain a valid PPP session. This is why Openreach had to auto-update the f/w in all their ECI modems in late 2014 to ensure they could do downstream g.inp.
---
btw.. can you get someone from your ISP to do a GEA service test. The figures you want are next to Profile Name.
This should advise your profile at the DSLAM. From indications last year on the Huawei cabs, it seemed to update pretty quickly if you changed your modem, so make sure you have the HH5A on when they run it.
|
|
|
Openreach have stated that the HH5A meets requirements of SIN 498 which only requires G.INP in the downstream direction Except they haven't. The HH5A doesn't seem to be mentioned in that link.
|
|
|
snipped the relevant bits.
Bear in mind we had had an extremely long conversation a few weeks earlier, but I wanted something in writing hence it later being in print. All that info was double checked by Openreach before publication.
Huawei cabs using ECI modems and the BT HomeHub 5A losing anything up to 10Mbps of downstream speed and experiencing large amounts of latency. The affected equipment is BT Openreach/BT Retail supplied that should surely comply with SIN498.
As you note above, to comply with SIN 498, modems and routers must support retransmission in the downstream, but it is not a mandatory requirement in the upstream.
|
|
|
|
So you have made the assumption, not Openreach stating it.
|
|
|
So you have made the assumption, not Openreach stating it.
No.
I was told that both the ECI modem and HH5A could support retransmission in the downstream direction only.
I was sick of people misinterpreting what I was saying about g.inp.. which is specifically why I later got something to put in print.
|
|
|
I was told that both the ECI modem and HH5A could support retransmission in the downstream direction only. Pity there's no proof that the HH5A does support G.INP. As far as I know, it doesn't.
|
|
|
|
Change the record
|
|
|
Change the record Weasel words I was told that both the ECI modem and HH5A could support retransmission in the downstream direction only.
|
|
|
Hang on a minute... a couple of post ago you said.
That simply repeats Openreach's assumption that the HH5A supports G.INP, however I have already provided proof that it does not.
Does the HH5A comply with SIN 498?
I simply said " I'm curious how you could have proved it.". Have you proved it or not?
Openreach say it does.
If it didnt then it shouldnt be able to get PPP.
All the indications Ive seen appear to show it supports downstream only. A personal friend of mine got g'inped about the same time as me. Well Im assuming thats what happened because no proof on his HH5A, but he gained nearly 4 Mbps overnight for no other valid reason, which seems about right for the other lines Ive been watching which previously had INP3.
Jeeze this is complete reversal... 12 months ago it was me going around saying that the ECI modems and HH5A's weren't capable of upstream g.inp and trying to prove there was a problem with the ECI modems, HH5A's and TD-W9980. AFAIK I was the first to bring the HH5A into doubt. I spend months getting something in writing for BT to acknowledge that it was an issue with the upstream. It was also me who contacted TP-link about the TD-W9980's and got them to release new f/w.
Ive given you all the facts as I have them. I went to Openreach and had a long conversation about the issues with the HH5A and eci modems trying to help get it sorted.
Now over to you and the proof you claimed to have.
I'm out of here now, because I have plenty of other things to do... but Im sure others would like to be able to make up their minds from the proof that you can provide.
|
|
|
|
Already provided.
|
|
|
Already provided. Where, please? (The URL to your proof would be appreciated.)
100% Linux and, previously, Unix.
|
|
|
He's talking bull....
He's been saying he has proof for the past 2-3 months to my knowledge, but hasn't provided any.... the only things he has provided is snipped out stats from the HH5's Helpdesk and they looked somewhat invalid with a max attainable showing over 300Mb/s downstream sync...
For some reason, he seems hell bent on wasting peoples time and confusing threads repeatedly.... lost count of how many times I've had to correct his statements informing other users that the compliant CP equipment isn't 'compliant....
I suppose it's a shame he can't be banned for nonsense post's, though maybe spam...
Anyway, as I was made aware mid 2015, the HH5a and ECI modem are compatible with G.INP downstream and now so is the ECI DSLAM's... this has been confirmed by the industry, the industry's press and it's followers... oh and many user's....
|
|
|
We have given you plenty of opportunity to make your opinion heard and it is clear to see that people want you to be very clear and open about the problem.
Using language like 'weasel words' suggests that where people have complained that you are trolling and being obstinate for no real reason may have a point, i.e. its time to put the proof out for proper peer review or just shut up.
Thread closed to draw a line under what will otherwise become a slanging match.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
Pages in this thread: 
Print Thread
dave2150
