Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ktor]

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.

[ejs]

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.

[gt94sss2]

This document 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.

[Ktor]

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.

[Ktor]

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.

[ejs]

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.

[WWWombat]

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.

[Ktor]

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.

[Chrysalis]

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.

[j0hn]

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

[broadstairs]

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

[S.Stephenson]

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.

[Ktor]

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?

[j0hn]

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.

[Ktor]

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.