Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Ornum on May 28, 2016, 09:10:50 PM
-
For the couple of months I had G.INP active on my line my connection was the best it has ever been in the 3 or so years I've been on infinity. After the rollback of G.INP my connection is now worse than it was before G.INP was rolled out. With G.INP my ping in games was a third to half what it was before and I gained around 8mb extra download and 2mbs upload.
I've read that OR are working to fix the issues, but do you think they will actually find a fix? And if so does anyone have an idea of how long this could take?
Cheers!
-
I've not even heard a detailed description of what the actual problem(s) are, just vague very high-level statements that there was an increase in the number of faults reported, plus a few mentions of certain incompatible devices, but I can't believe Openreach would have disabled G.INP on all ECI cabinets due to a small number of third-party incompatible devices.
-
I am 100% sure it will be re-enabled they just need to find away to differentiate incompatible modems from compatible modems a guess this will need to done at a low level stage in the FTTC ECI cabinet.
So If your modem is incompatible with G.INP then you will get either Fastpath or Interleaving and no G.INP.
If the modem is compatible then G.INP will be available if the end-users line needs it.
I would hope to see G.INP ECI MK4 coming back in late July :fingers:
PS this is only a predication
-
I am 100% sure it will be re-enabled they just need to find away to differentiate incompatible modems from compatible modems a guess this will need to done at a low level stage in the FTTC ECI cabinet.
Since most cabinets are Huawei and have had G.INP for a year they have plenty of information about what modems are and are not compatible with G.INP. This huge mess is obviously down to a faulty and completely inadequately tested implementation of G.INP on the ECI cabinets.
Don't know why you are trying to pin it on modems all of which must be working adequately on Huawei cabinets.
-
Don't know why you are trying to pin it on modems all of which must be working adequately on Huawei cabinets.
I know only to well we lost G.INP on the upstream on Huawei cabinets last year down to incompatible modems and it's the same for ECI users only this time it's on the downstream as the ECI cabinet can't do G.INP on the upstream.
-
Just seeing someone predict July makes me happy:)
Anyway, I don't really understand all this stuff, why cant ECI cabinets have G.INP on the upstream?
Would anyone care to educate me on the ins and outs on why there are different cabinets, why G.INP works on one but not the other, etc?
Cheers!
-
The best place to start is at the beginning Ornum
with this thread http://forum.kitz.co.uk/index.php/topic,15283.0.html (http://forum.kitz.co.uk/index.php/topic,15283.0.html)
-
Cheers mate
-
I know only to well we lost G.INP on the upstream on Huawei cabinets last year down to incompatible modems and it's the same for ECI users only this time it's on the downstream as the ECI cabinet can't do G.INP on the upstream.
ECI cabinets are probably as crap as the modems you are calling incompatible, neither having enough processor and/or memory to implement G.INP in both directions.
My Asus modem supports G.INP in both directions but against the ECI implementation just got banded to 64Mb and interleaved in both directions and I still have downstream interleave 70 days after this farce started. How hard would it have been for BT to buy one of each modem from their own god damn BT Shop and try them before rolling out on 1/4 of a million lines? The incompetence is stunning.
-
I really don't think Openreach need to make allowances for end user modems not supporting downstream G.INP. SIN 498 makes downstream G.INP mandatory, whereas upstream G.INP is optional (but recommended). The vast majority of end users will be using a modem/router supplied by their ISP.
Didn't the Asus modems get a firmware update to fix the G.INP issue on ECI cabinets? Doesn't that suggest the problem was with the Asus modem?
-
A while ago someone (cant remember who - sorry) posted a link to an update on the ECI cabinet situation from BT which was intended for ISPs so no one here could read it. After my complaint to the CEO office at TT I sent an email referring to this document asking for an update. The reply I got was less than helpful - a point blank refusal to tell me what it said.
So ISPs do have some information on this but they are not saying what is happening. Now that could be bad news that they dont want to pass on or it could be that they are genuinely constrained by non-disclosure, we are unlikely to know. Currently anything said here about if/when ECI may/may not get G.INP reinstated is pure speculation I believe.
Stuart
-
I really don't think Openreach need to make allowances for end user modems not supporting downstream G.INP. SIN 498 makes downstream G.INP mandatory, whereas upstream G.INP is optional (but recommended). The vast majority of end users will be using a modem/router supplied by their ISP.
Didn't the Asus modems get a firmware update to fix the G.INP issue on ECI cabinets? Doesn't that suggest the problem was with the Asus modem?
The only comment I have seen about Asus modems and ECI G.INP is that a G.INP connection is not established and they get +1 level of DLM applied - exactly what I got. There was no firmware update for the issue. I have also not seen comment on any problem with the DSL-AC68U and G.INP on Huawei cabinets which as far as G.INP is concerned makes it better than many. I have seen modem screenshots of G.INP active up and down in Italy and Australia. It likely doesn't have a G.INP problem to be fixed.
-
The firmware release notes for the DSL-AC68U version 3.0.0.4.380_3034 dated 2016/05/13 lists:
Fixed IOT issues with specific version of ECI DSLAM
IOT possibly an abbreviation for "interoperability testing". I'm assuming that line is referring to G.INP. The same line is in the release notes for other Asus VDSL2 models, as they all use MediaTek VDSL2 chipsets.
-
The best thing for now is I think to forget about this, as this could be several months before it reappears. BT will be more cautious to try it again as they wont want to do another rollout and then pull it again.
-
Since most cabinets are Huawei and have had G.INP for a year they have plenty of information about what modems are and are not compatible with G.INP.
Things aren't as straightforward as that.
The standards allow for multiple implementations of G.INP, at both ends. When you see something working, all you can say is that one particular combination works.
With Huawei cabs working with lots of modems, we know that one set of combinations work - which might amount to around 10% of all combinations. But we know nothing about other combinations. So...
This huge mess is obviously down to a faulty and completely inadequately tested implementation of G.INP on the ECI cabinets.
... it is really hard to make this conclusion stick as the *only* possibility.
It is indeed one possibility amongst many. Unfortunately, faulty modem implementations are also a possibility - and become more likely if other modems work just fine.
What is certainly true is that the combination of ECI cabinet and at least one modem hasn't been tested together. Whose fault is that? Who specifies the range of modems that *should* be tested against? Should we expect more than, say, those modems put forward by ISPs for conformance testing?
IMO, there isn't one problem here, some aspects seem more likely to be caused by the cabinet; some by modems.
-
The best thing for now is I think to forget about this, as this could be several months before it reappears. BT will be more cautious to try it again as they wont want to do another rollout and then pull it again.
I would love to forget about it but the seemingly permanent downstream interleave this crap has left me with is a constant reminder.
It is indeed one possibility amongst many. Unfortunately, faulty modem implementations are also a possibility - and become more likely if other modems work just fine.
Well if you want to take the Asus as an example G.INP appears to be working in Italy, in Australia, in the UK with Huawei cabinets but not at all against a brand new implementation on ECI cabinets - what are the odds the cabinet isn't the problem?
Regardless they shouldn't have rolled out without testing against all modems users might reasonably be expected to be using, you know like ones they sell in the BT Shop, and Currys and Tesco FFS.
-
So what about the other devices that did work fine while G.INP was enabled on ECI? And what about the ECI fix mentioned in the Asus firmware release notes?
I thought the Asus VDSL2 devices have a long history of general VDSL2 stability problems, and they also defaulted to G.INP being disabled by default until recently, this is from the DSL-AC68U Firmware version 3.0.0.4.378_9296 release notes (2016/03/15)
- For Quick Internet Setup(QIS) VDSL WAN(PTM) Country: UK/ Australia/ Germany, enable G.INP (G.998.4) by default.
- Administration > DSL Setting > G.INP (G.998.4) remains disabled by default. If supported by ISP, could enable it.
-
This document (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/downloads/ProcessGuideforCPEeModemConformanceTestingIssue1.3.pdf) outlines some of the testing process that Openreach carry out on modems submitted to them for modem conformance testing (MCT) to ensure that they meet the requirements of SIN498 to ensure they are compatible with Openreach's network.
For the purposes of this discussion slides 11-13 seem the most relevant.
No Asus model is known to have passed the MCT process.
-
So what about the other devices that did work fine while G.INP was enabled on ECI? And what about the ECI fix mentioned in the Asus firmware release notes?
What about it? Doesn't change the odds and fix didn't fix G.INP, you don't even know if "specific version of ECI DSLAM" means in this country.
I thought the Asus VDSL2 devices have a long history of general VDSL2 stability problems, and they also defaulted to G.INP being disabled by default until recently, this is from the DSL-AC68U Firmware version 3.0.0.4.378_9296 release notes (2016/03/15)
On my short line it has been rock solid. Between getting it in January and this crap starting in March I had 80/20 fastpath sync and a 50 day DSL uptime, I currently have 9 CRC errors logged in 10 days uptime.
The modem has a setting to enable/disable G.INP support, implying a change of the factory reset default for that setting is an indication that G.INP does/doesn't work is grasping at straws.
-
For the purposes of this discussion slides 11-13 seem the most relevant.
No Asus model is known to have passed the MCT process.
And according to to list you posted here http://forum.kitz.co.uk/index.php?topic=17086.0
Neither has any TP-Link, Netgear, Linksys, or Trendnet model all of which can be purchased from the BT Shop.
-
What about it?
Well, it would be quite a coincidence that Asus just happened to be updating the firmware for some other ECI DSLAM issue around the same time as G.INP was being enabled then disabled again on Openreach's ECI cabinets.
The modem has a setting to enable/disable G.INP support, implying a change of the factory reset default for that setting is an indication that G.INP does/doesn't work is grasping at straws.
And the default setting was unsuitable until recently, owners of the device would need to know to switch it on. I wasn't implying having a setting means it doesn't work properly, most devices have settings to enable or disable such features, although not necessarily in the web interface. I was saying it wouldn't have been configured correctly (by default), unless the owner knew how to configure all those settings properly.
If your line is very short, it might be easy for any modem to achieve the maximum product speed.
Asus VDSL2 devices are the only ones I can think of using the MediaTek VDSL2 chipsets. There probably are some others, but they don't seem to be as common as Broadcom based modems.
Unless it's a BT branded item, I think the availability of something from the BT Shop does not indicate it's endorsed or approved by BT.
-
Well if you want to take the Asus as an example G.INP appears to be working in Italy, in Australia, in the UK with Huawei cabinets but not at all against a brand new implementation on ECI cabinets - what are the odds the cabinet isn't the problem?
Who knows? Without putting much effort into it, I can come up with 16 fundamentally different framing setups on the wire. The Asus/Huawei combination would seem to prove one of those combinations, leaving another 15 to go. If the blame could be apportioned 50:50, then a 50:50 chance over 15/16 scenarios leaves you at odds of 47:53.
If the Asus is working in Australian VDSL2 deployments, it is likely to be working with Alcatel-Lucent DSLAMs, which could well be an entirely different setup.
I'm sure that both pieces of equipment will have been through testing - but I'd be a liar if I thought that the Asus had been through anything like the rigorous testing that a telco would insist on for network equipment. Can we really say it is likely to be 50:50? I don't know.
The fact is that these are complicated pieces of kit, and being shown to work in one narrow way usually leaves plenty of other options to go wrong.
However, with @ejs finding a firmware update from Asus making reference to changes for the ECI DSLAM, I'd say it stacks the odds in one direction somewhat.
I've spent most of my professional career chasing and fixing bugs in interworking between telco equipment. If I started out with the certainty you do over the source of a problem, I wouldn't have solved anywhere near as many problems.
Regardless they shouldn't have rolled out without testing against all modems users might reasonably be expected to be using, you know like ones they sell in the BT Shop, and Currys and Tesco FFS.
Why? They have a properly-placed requirement that modems must have gone through conformance testing before being allowed on the network. Should that be just thrown away? Ignored?
And according to to list you posted here http://forum.kitz.co.uk/index.php?topic=17086.0
Neither has any TP-Link, Netgear, Linksys, or Trendnet model all of which can be purchased from the BT Shop.
Ability to buy is not the same as being allowed to use.
And all are likely to also support other modes where they can be used: ADSL and PPPoE modes.
-
Well, it would be quite a coincidence that Asus just happened to be updating the firmware for some other ECI DSLAM issue around the same time as G.INP was being enabled then disabled again on Openreach's ECI cabinets.
So it must be a fix specifically for G.INP issues in the UK on ECI cabinets regardless of the update notes not mentioning G.INP or the UK. Seriously. That firmware was in beta before release, it didn't fix G.INP issues. I have not seen any report of G.INP working on UK ECI cabinets.
I've spent most of my professional career chasing and fixing bugs in interworking between telco equipment. If I started out with the certainty you do over the source of a problem, I wouldn't have solved anywhere near as many problems.
Smug much, the only certainty I stated was that it was inadequately tested. The fact is if the update wasn't faulty they wouldn't have had to rollback and if the had tested adequately they wouldn't have rolled out to 1/4 of a million customers before discovering it was faulty.
-
The problem sadly wombat does point at openreach, they started out with the right mindset only using their equipment on installs and having a set of guidelines in place for authorised equipment, even having rules which gave them the right to ban rogue equipment.
However at some point they lost their way, they started allowing self installs, isp supplied modems and of course end user choice of chipset, they have even not yet banned if at all asus devices ignoring dslam parameters such as target SNRM and UPBO yes the dreaded asus devices and to a lesser extent the fritzbox devices.
Also I think choosing a barely known supplier called ECI hasnt helped matters either.
As I tried to explain in older threads, whilst there is a set standard for g.inp, that standard is relied upon been executed by firmware developers and its inevitable will be issues across different chipset suppliers.
Openreach have gone the path now they unwilling to kick off (or incapable) rogue devices, so they left in a position to see if they can make this work somehow or simply have to abandon g.inp on ECI dslams.
My advice to forget is simple really, one can stress out about it on a daily basis, or just forget about the problem and before you know it a fix is in place.
-
What about it? Doesn't change the odds and fix didn't fix G.INP, you don't even know if "specific version of ECI DSLAM" means in this country.
it was this country, I was beta testing these firmwares with Asus.
Asus didn't even know the ECI G.INP rollout had been halted, and were still sending out betas to fix it after the fact.
Paul Lee from Asus emailed me this
"According to the diagnostic debug log, your ISP TalkTalk DSLAM did not
enable G.INP support, as the log indicated GINP_Field_length = 0 which means
DSLAM did not inform DSL-AC68U G.INP support available during initiating
process, if this GINP_Field_length > 0 that means G.INP support available.
This beta John has G.INP working on ECI DSLAM when DSLAM announces it. Can you send me screenshot of your Talktalk modem syncing with G.INP for reference."
His English is not so good. Looked to me like they fixed any problems they had, and that some of the reports of it not working with ECI cabinets were probably on lines that never had G.INP or had it removed from their lines. that beta was made an official release after the rollout was halted.
And the Asus modems would never in a million years pass OpenReach MCT. they have options that shouldn't be available for me to change, UPBO enable/disable being 1
-
I have some sympathy for Wombat here and also feel in some ways Chrysalis has a point over BT. What I think quite a lot of people here either choose to ignore or don't understand is the complexity involved in trying to manage an environment where there is very little control over the mix of devices, and how software (for that is what is involved here) works and how it has to be debugged. Software never breaks - yes I know that will upset and annoy some here - but I speak from practical professional experience. Software starts out with some design specs which are interpreted by the coder or coders and then tested, but this testing can ONLY be on a subset of situations which might exist in the real world - sadly the ONLY way to test something is to put it out there and wait for the end user to break it. This means that when something goes awry it has not broken light hardware would break but there is a flaw in the implementation of the design and this becomes very difficult to resolve because almost invariably someone somewhere has done something and not considered the consequences and therefore we have fault.
Now as Chrys says if BT only allowed approved devices on their network we would have a better playing field, and yes if the roll out of something like G.INP has been slower and more controlled we might just be in a better position.
However despite all this we are where we are and we will just have to wait for BT and/or ECI to resolve this or not. No amount of debate here will resolve this issue.
One last point is that apart from the strange cases of upstream FECs which Ronski, myself and some others experienced G.INP did work well for me for 40+ days with faster speeds and very good reliability so in some cases it did work, not perfectly perhaps, but it did basically work here in the UK on an ECI cabinet, and I'm sure I'm not the only one to say this.
Stuart
-
Well very few still have G.INP myself included and it has caused me no issues since the 19th of March if I remember correctly
It has worked with no issues on my HG612 and OpenWRT ECI modem.
-
And the Asus modems would never in a million years pass OpenReach MCT. they have options that shouldn't be available for me to change, UPBO enable/disable being 1
It wouldn't take Asus a million years to remove the UPBO option, and being able to frig downstream SNRM so I could do my own 3db (actually only 4db) trail suits me fine. Unfortunately according to the ispreview article on MCT they would have to wait in a ridiculous 11 month queue for re-testing.
No doubt openreach see MCT as a source of revenue. I imagine for equipment manufacturers it is onerous, tedious and expensive while offering no real benefit. Openreach should be doing MCT themselves on all readily available equipment for free and publishing the results instead of trying to keep them secret. 5 billion turn over and they can't afford to test a few tens of modems?
-
It wouldn't take Asus a million years to remove the UPBO option, and being able to frig downstream SNRM so I could do my own 3db (actually only 4db) trail suits me fine. Unfortunately according to the ispreview article on MCT they would have to wait in a ridiculous 11 month queue for re-testing.
No doubt openreach see MCT as a source of revenue. I imagine for equipment manufacturers it is onerous, tedious and expensive while offering no real benefit. Openreach should be doing MCT themselves on all readily available equipment for free and publishing the results instead of trying to keep them secret. 5 billion turn over and they can't afford to test a few tens of modems?
well seeing as Asus have taken a firm stance on not releasing country specific firmwares, their modems would never pass the MCT tests. recently lost the ability to use a bunch of 5ghz channels just because they are banned in the states. as for "re-testing", I'd be surprised if they put any up for testing in the 1st place.
-
I'd be surprised if they put any up for testing in the 1st place.
Of course they won't put any up for testing because pass or fail will have zero impact on their sales to consumers.
Cisco and Draytek seem to have put a few through testing I assume because they think it will help command a premium price.
I would bet just about all MCT of other modems was due to the requirements in large orders from ISPs.
-
One of the MCT documents (from here (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/cpeenablement/cpeenablement.do)) says devices can only be submitted by ISPs, and ISPs are required to supply a device that has passed the testing. Some might have been submitted to Openreach by BTWholesale, I think all of the lists of approved devices are from BTWholesale, which is why they don't list the ISP-branded custom built devices.
BT SIN 498 not only details all the requirements, but it also details how to perform all the tests, so it would be possible for a manufacturer to do almost equivalent testing themselves, although they might not be able to exactly replicate the DSLAM and its firmware.
Perhaps it would be better if whether or not a device has passed the testing did affect sales, but that would require better informed consumers, or perhaps some kind of mandatory prominent labelling and advertising. And of course it would need to be possible for manufacturers to submit devices for testing themselves (I previously thought this was possible, but perhaps it isn't).
-
Draytek have certainly put 3 of their products through testing, see below:-
http://www.draytek.co.uk/information/our-technology/bt-sin-498
-
I don't think it actually says Draytek themselves submitted the devices to Openreach for testing. It says they've been tested, and of course Draytek made the necessary changes to get the devices to pass, but not who actually got Openreach to do the testing.
-
Are you suggesting then that an ISP submitted 2 Draytek modem/routers and 1 Draytek modem for MCT certification, and was happy for Draytek to claim all the credit and marketing hype whilst remaining completely anonymous?
-
KCOM also maintain a list of approved hardware at http://business.kcom.com/products/connect/broadband/approved-hardware/
This shows that Draytek (for example) have 12 approved models - though I note, all share the same chipset and firmware.
I guess Openreach are not concerned if modems support WiFi, 3G/LTE etc. - which actually makes the testing regime easier if only one version model has to qualify.. But it also makes it less acceptable that Asus/others haven't had their kit approved.
Self install FTTC has been around for several years now.
-
One or more ISPs (who are customers of BTWholesale) asked BTWholesale for the Drayteks to be certified I expect. Is there much marketing hype to be had for saying you've got something that you're required to have? ISPs have to supply certified devices.
If you are a reseller or a CPE Vendor and wish to have your devices verified, you will
need to contact your GEA-FTTC service supplier who will engage with Openreach on
your behalf. Please note that such requests to test your devices should be made by
service providers and not by yourself
-
they might not be able to exactly replicate the DSLAM and its firmware.
BT have a testing facility at Adastral Park where manufacturers can pay to test their modems in a live network situation. I'd guess they have various DSLAMs all hooked up to test firmware on.
edit: going by your post above, perhaps the manufacturers can't book this themself, but it's there for them to use.
-
KCOM also maintain a list of approved hardware at http://business.kcom.com/products/connect/broadband/approved-hardware/
Which is identical to the list you posted here http://forum.kitz.co.uk/index.php/topic,17086.0.html supposedly released by some ISP so it doesn't look like KCOM did any more than nick that list from somewhere.
-
Very briefly as I'm not well and backlogged with everything.
- AFAIK MCT testing is free (certainly for SPs) although retest upon failure isn't.
- There is or at least was a way in which modem/router manufactures could approach Openreach for MCT testing. I have seen something in the past to indicate there is/was 2 routes.
- I discussed MCT with TP-link in Oct 2014 with their UK product manager who was going to take it up with their Head Office in China. Since I havent heard anything further, their HO may either have decided against it OR not realised back in 2014 how important it could be.
- Zyxel apparently applied off their own back. I spoke to someone @ Zyxel UK about 7/8 months ago when I asked which f/w they used on the test equipment. Their official announcement last year also indicates that they did so.
- I note that some of the big ISP branded modems do not make that list although they obviously should have been through testing. ie the Sky Hub, BTr/consumers HH5, Plusnets Hub One. Why isnt the HG612 and ECI modem on there yet they should be. What about the likes of some of the other ISPs (say EE) theyve had more than enough warning to ensure that their modems are tested and Openreach make it abundantly clear that support will not be given if they don't.
- Last year at one of the ISP forum events, Openreach asked for suggestions from the ISPs for modems to go through testing. I doubt the big names will have put anything forward since they will have all been concentrating on their own equipment.
supposedly released by some ISP so it doesn't look like KCOM did any more than nick that list from somewhere.
Updated lists are issued to the ISPs and there is the ISP forum documentation provided by BT wholesale/Openreach, which is why all the ISP lists are identical.
-
Updated lists are issued to the ISPs and there is the ISP forum documentation provided by BT wholesale/Openreach, which is why all the ISP lists are identical.
Do KCOM provide any FTTC service through openreach cabinets? I assumed that list was approved for use with their own cabinets in Hull and it being identical to others indicating that they didn't do any independent testing against their own equipment.
-
Eclipse Internet were renamed KCOM (reflecting the fact they have been owned by them for years).
In Hull, they provide the Zyxel VMG8924 for their LightStream product
-
The ISP forum is done by BTWholesale. I thought it was BTWholesale asking for devices that BTWholesale would then send to Openreach for testing. I think the lists we've seen come from BTWholesale, and they only list generic devices that could be used by lots of different (smaller) ISPs.