Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 9 10 [11] 12 13 ... 17

Author Topic: G.Inp on ECI Possibly Delayed  (Read 55574 times)

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #150 on: January 17, 2018, 07:05:47 PM »

supposedly if g.inp was/is broken ayeaye on mdws has managed to keep his g.inp from when it was first seen on ECI so it can't be all that bad. still seems odd Openreach left it enabled on some cabs etc after it was suspended.

It was broken for some modems - they never said which.   

I'm not sure if it was left enabled on a per cab basis, but rather more per line basis.   eg if the EU had BT-TV..  and thus most likely using a HH?
I'm sure I said at the time that they were leaving it on for users with TV services.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

skyeci

  • Kitizen
  • ****
  • Posts: 1383
    • Line stats
Re: G.Inp on ECI Possibly Delayed
« Reply #151 on: January 17, 2018, 07:23:50 PM »

Hi Kitz

yes I am sure you did and I understand why but. It just seems odd to leave it partially enabled for some. either turn it on or switch it off...its either broken or it's  not  ::)  ;D

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #152 on: January 17, 2018, 07:40:56 PM »

Quote
It just seems odd to leave it partially enabled for some.

Indeed, but to have done so means that they were confident it was working perfectly fine for those users.

So what makes them so special?   OK so those using streaming IPTV are those who benefit most from g.inp.

<tin foil hat>
Most likely to be using HH which Openreach knows works OK.
</tin foil hat>

Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Ktor

  • Member
  • **
  • Posts: 37
Re: G.Inp on ECI Possibly Delayed
« Reply #153 on: January 17, 2018, 07:52:49 PM »

So we know ECI g.inp worked fine for certain lantiqs and it worked fine with the BCMs....

If it were as simple as this modem or that modem why did they roll out to 1/4 million subscribers before noticing? Why didn't they already know about modems problems on Huawei cabs? If it is something simple why isn't it fixed two years on?

I don't think anyone outside openreach and ECI knows much about it.

So what makes them so special?   OK so those using streaming IPTV are those who benefit most from g.inp.

g.inp lets BT flog IPTV services to a few more customers - that is why they bothered with it at all isn't it?

Maybe the line cards don't have enough processing power to implement g.inp on all channels at high sync rates.
« Last Edit: January 17, 2018, 07:59:08 PM by Ktor »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.Inp on ECI Possibly Delayed
« Reply #154 on: January 17, 2018, 07:54:31 PM »

The obsolete models were the Draytek 2750 and 2850 which used a Metanoia VDSL2 chipset, not Lantiq.

All the Lantiq chipset modems, such as the BT HomeHub 5A and the ECI Openreach modem are now perfectly capable of doing upstream G.INP if BT bothered to update the modem firmware. In the early days, such firmware may not have been available, and so the SIN 498 requirements were probably written with the limitations of the modems at the time in mind.

Now what if the problem is the M41's aren't capable of being able to cope with certain rulesets depending on which modem is in use. THAT would make more sense to me when it comes to disabling upstream g.inp.
Perhaps (just perhaps) the issue may not actually be with g.inp itself but trying to identify modems on the other end and what to do with them depending on the modems capability for g.inp.

That sounds very unlikely to me. I thought all the logic of selecting what profile to use was done by some part of the DLM, and then the DSLAM in the cabinet simply does what it's told regarding enabling G.INP in whichever direction(s) on a particular line. I still think it's much simpler: just because the ECI M41s can do N tasks simultaneously, it's doesn't mean they will be able to do N+1 tasks simultaneously, even if the extra task may be relatively simple compared to all the things it's already doing.

I think part of the problem originates from BT never enforcing any modem compatibility rules, but I suppose it may originate from them having to fudge the system so that downstream G.INP, a mandatory requirement, is switched off until something detects your modem supports it, which was needed so that the Openreach modems could get a working network connection to update their firmware for G.INP support. So then if an Openreach person replaced one of their modems, with one that may have been sitting around in its box for a while, they might have to do a DLM reset, to switch off G.INP, so that the modem could connect, and then its firmware would update.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.Inp on ECI Possibly Delayed
« Reply #155 on: January 17, 2018, 08:01:16 PM »

why isn't it fixed two years on?

It's taking a very long time to fix because they are now being extremely careful to avoid breaking anything if and when they try it again. I'm sure they already what the problem was and which modem(s) were involved. I thought they said a while ago that they'd developed a fix. But if they do something, it will then be their fault if something goes wrong, so it's much safer for them to just do nothing and forget about it really.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #156 on: January 17, 2018, 09:01:38 PM »

Quote
The obsolete models were the Draytek 2750 and 2850 which used a Metanoia VDSL2 chipset, not Lantiq.

Thank you I couldnt recall the numbers, although I did say "non Lantiq and BCM chipset based modems eg".  Again I cant recall model nos but iirc some of the others were MediaTech?

Quote
That sounds very unlikely to me. I thought all the logic of selecting what profile to use was done by some part of the DLM, and then the DSLAM in the cabinet simply does what it's told regarding enabling G.INP in whichever direction(s) on a particular line.

Thats the theory, but theres some oddness that goes on if the modem isnt capable of G.INP.   

As it currently stands on Huawei cabs g.inp only goes on for upstream on those modems capable of doing so.  Yet it can still apply g.inp and INP for those that are capable.
It wasn't until in a live situation that Openreach saw the [unexpected] effects that trying to apply g.inp to modems that couldnt do so that they changed things and came out with G.INP Mk2.
How is DLM able to totally turn off G.INP for those ASUS modems, yet within quite a short timeframe (~2 weeks) then go back to using G.INP when a modem capable of re-tx is put back on the line.  If it was just DLM then you would fully expect g.inp to go back on the line immediately a compatible router is put on the line.

Right from the very start and before re-tx went live, we were told non g.inp modems would not sync, yet on the Huaweis they still did.   It wasn't until they applied re-tx to the ECI's that we started seeing the non-sync and sync instability problems.

The ECI's seem less capable of handling non compliant modems. Which is why I said I wonder if this is why they totally turned off upstream g.inp for the ECIs from the very start...  knowing full well that the ECI modems and HH5As wouldnt work for upstream.    In theory the ECI DSLAMs should be able to handle upstream.   
In theory the ECI modems should be...  and are, just they never got around to updating f/w for some reason.

Quote
I think part of the problem originates from BT never enforcing any modem compatibility rules,

^This.
It also remains to be seen if they do ever take any action against those modems causing issues. So far they don't appear to have done so other than trying to find a fix at their end.  Thus delaying the roll out for the rest of us.

I suspect there were probably far more modems than anticipated being non compliant.  ASUS has quite a large following as do several other modem manufacturers who havent yet bothered to apply for MCT.

All the evidence suggests that it is a compatibility issue and one which has affected the ECI's far more than the Huaweis. 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: G.Inp on ECI Possibly Delayed
« Reply #157 on: January 17, 2018, 09:08:46 PM »

kitz it was a question hence the ? after capacity.

you didnt mention any of these technical advances other then capacity in that sentence.

The system level vectoring you mentioned doesnt really apply to to the openreach ECI rollout as they didnt order ECI vectoring kit.  So what were the technology advances that are present in the M41?
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.Inp on ECI Possibly Delayed
« Reply #158 on: January 17, 2018, 09:25:04 PM »

If it was just DLM then you would fully expect g.inp to go back on the line immediately a compatible router is put on the line.

I wouldn't. Like I wouldn't expect the DLM to immediately remove someone's banding after say a line fault had been fixed.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #159 on: January 17, 2018, 10:38:31 PM »

kitz it was a question hence the ? after capacity.
you didnt mention any of these technical advances other then capacity in that sentence.

Read again.  I did not just type line card capacity, it just so happened that was mentioned first

At the time ECI cabs were considered superior :/   The line cards had more capacity and historically ECI had made some serious technological advances when it came to VDSL. Ironically vectoring!   I know when I found out my new cab was an ECI several people said they were considered better than the Huaweis. ECI were known and respected by other Telco's outside of the UK.

Ok I typed VDSL when I should have typed DSL or telecoms, but I didn't realise you wanted me to type a full breakdown.   They've been respected in Telecoms since 1961 in many other countries.

They were the
  • First to market CWDM (Wave Division Multiplexing for Backhaul) This was pretty major compared to FDM and why we can now have much larger & cheaper backhauls
  • First to market optical rings.
  • First to market SDH (Transportation Layer protocols used for 21CN networks)
  • First to market System Level Vectoring
  • Pioneers in DSM (I'm sure you know what that is - but for others its Dynamic Spectrum Management)
  • .. and more if you go check out their site

Quote
The system level vectoring you mentioned doesnt really apply to to the openreach ECI rollout as they didnt order ECI vectoring kit.  So what were the technology advances that are present in the M41?

Theyve been doing system level vectoring since 2009. If memory serves me right it was for one of the South American countries somewhere like Argentina or in that region. 

As I said in that very same post quote

It could have perhaps been a different story if Openreach had gone with the V41's

Jeeze now I feel like some sort of marketing rep for ECI which was definitely not my intention.   
All I was trying to say is that they have a good history behind them and were respected in the industry at what they do, so BT was not dumb for going with ECI based on their past history.

So something is stuffed up with g.inp, being on a ECI cab myself that would definitely benefit from it I'm not too chuffed either, but that would appear to be some sort of incompatibility issue with modems rather than with the DSLAMs.

Yes compared to Huawei it is now poor, because without g.inp, Openreach wont do xdB,  yet again I could benefit from that.   The fact that Openreach ordered M41s rather than V41's again isnt the fault of ECI.
Ironically the man in the street doesn't have a clue nor care about g.inp.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: G.Inp on ECI Possibly Delayed
« Reply #160 on: January 17, 2018, 10:43:18 PM »

Ok thanks for the info kitz, sorry for misunderstanding you.

I just feel broadcom is always the safest bet as they seem to always have the best compatibility with other modems, and the features that broadcom support are usually more reliably working.

I remember my days on ukonline who used conexant based dslams.

In turn this utilised a feature called SRA which conexant supported, it worked really well with conexant modems, but had massive compatibility issues, I dont think there was a single success story with a single non conexant modem, and even newer conexant modems were not fully compatible so it had to be same generation of chipsets as well as same vendor.

Yet with broadcom devices, features seem much more universally reliable across different vendors and across different generations of broadcom chipsets. I suspect its because pre launch testing likely includes testing against broadcom dslams.
« Last Edit: January 17, 2018, 10:51:04 PM by Chrysalis »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #161 on: January 17, 2018, 10:49:22 PM »

I wouldn't. Like I wouldn't expect the DLM to immediately remove someone's banding after say a line fault had been fixed.

If DLM has decided line needs action (for Huawei) then first thing it does is apply re-tx and apply that profile.   With the ASUS it doesn't & it goes to INP and takes a couple of weeks to remove.

When we had g.inp mk1, if the modem couldn't do upstream g.inp, then it applied it as a ridiculously high level of INP which affected both upstream and downstream.   Yet if the EU switched from say HH5A to HH5B then immediately they got G.INP when they plugged in the other modem.    This was repeated time and time again...  because the actual line profile was re-tx. 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: G.Inp on ECI Possibly Delayed
« Reply #162 on: January 17, 2018, 11:03:30 PM »

I just feel broadcom is always the safest bet as they seem to always have the best compatibility with other modems, and the features that broadcom support are usually more reliably working.
/snip/
Yet with broadcom devices, features seem much more universally reliable across different vendors and across different generations of broadcom chipsets. I suspect its because pre launch testing likely includes testing against broadcom dslams.

I must admit broadcom is my choice too, just because their chipsets have always worked best on my line.   Even some of the old Speedtouch 585 modems which many hated, yet loved by those in the 24Mbps club with BE*   
There has been one other modem that I really liked and that was the Solwise SAR110 which at the time (15yrs ago) was really quite good for the money and had some advanced features that no other router at the time did.    Under the hood it was Globespan Virata.    They were also in a few other modems such as the BT Voyager 205 & the Huawei MT882 that used same chip.

Generally speaking the BCMs do tend to do well on most lines and tend to give good performance.    Things can change a little though on very long lines or lines getting lots of errors..  then some of the other modems may work better.   The 2 wires were a good example of this.. they were brilliant for long lines, but garbage for short lines. 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

smallal

  • Reg Member
  • ***
  • Posts: 126
Re: G.Inp on ECI Possibly Delayed
« Reply #163 on: January 18, 2018, 10:38:13 AM »

I was obviously unlucky, despite having BT-TV they switched G.INP off on my line at the same time as everyone else.
Logged

skyeci

  • Kitizen
  • ****
  • Posts: 1383
    • Line stats
Re: G.Inp on ECI Possibly Delayed
« Reply #164 on: January 18, 2018, 10:42:19 AM »

so this still doesn't explain why some lines  or cabs still have it working..... ::)
Pages: 1 ... 9 10 [11] 12 13 ... 17