G.INP question

Sorry for the ignorance here, but how do I find out if G.INP is supported by my cabinet (SMKBN cab 2)? And will it work with a HH5A or would I need to get a different modem/router?

Your cabinet is a Huawei so G.INP is available but your HH5A doesn't support G.INP. I recommend you get a Huawei HG612 v3B and unlock it with the B030SP08 firmware. You can then plug this into the HH5A and get G.INP

Thanks BatBoy. Will this be worth it i.e will I get a speed increase?

I went from 77 Meg to 80 Meg when G.INP was switched on.

OK sounds worthwile. So if I get a HG modem, how do I plug it into the HH5? just via ethernet to a port on the HH5? I don't really like the HH5, the wifi is [censored], so would consider changing that...

Yes, LAN1 on the HG612 to the red WAN port on the HH5. I find the wireless really good on my HH5A, but if you don't like the HH5 anyway, you could replace it.

It's not true that the HH5A doesn't support g.inp with one proviso, it's downstream only. I have one, and it does, and have tried both an A & B (don't ask why I have both - to do with moving and currently having two properties). Both give similar downstream speeds and rock-solid connections (about 56mbps on an 80mbps service). The B does give about 1mbps more upstream though.

When g.inp was enabled on my local (Huwai) cabinet, the change was very noticeable as prior to that I'd average one disconnect a day (now its only on the fortnightly scheduled modem reboot - and the B does the same thing). However, the first sign had been an increase in sync speed followed, within a day, with a reconnect with interleaving turned on (which lost a lot of speed) and then, about a week later a resync with interleaving turned off and the return of the lost speed.

The g.inp situation is a lot more complex that HH5A doesn't support it.

In reply to a post by TheEulerID:

It's not true that the HH5A doesn't support g.inp with one proviso, it's downstream only.

The g.inp situation is a lot more complex that HH5A doesn't support it.

Err I don't understand, these two statements seem to be contradictory.

Frm what I'd heard the latter was true? Hence the reason to get another modem...

The HH5A definitely doesn't support G.INP.

I had G.INP enabled and i'm using a Billion 8800NL and used this article here: http://www.increasebroadbandspeed.co.uk/g.inp

to determine that it had been switched on although my INP/DMT value is 47 and not 48 but interleaving is switched on at 8 on the downstream and 1 on the upstream. and i got a 3mbps increase.

Does anyone know if the bandwidth will increase further?

It's unlikely to increase further if your noise margin is on target of 6.

In reply to a post by BatBoy:

It's unlikely to increase further if your noise margin is on target of 6.

My SNR margin is 6.3 down and 16.6 up. I've not gone in to the billion and specified an SNR.

I don't think you can, all you can do is cap your speed if you ever want to raise your SNR margin.

I'm unsure if 0.3 SNRM will amount to much change in sync speed.

I'm not quiet sure of why there's still so much of an argument behind this topic however I can confirm that the BT HH5a does support G.INP however it is only on downstream and has to have the correct firmware...

In test I saw a HH5a gain an extra 6mbps from G.INP after BT rolled out firmware that fixed the incapability...

In reply to a post by mlmclaren:

I'm not quiet sure of why there's still so much of an argument behind this topic

Because nobody has come up with any proof one way or the other

however I can confirm that the BT HH5a does support G.INP however it is only on downstream and has to have the correct firmware...

In test I saw a HH5a gain an extra 6mbps from G.INP after BT rolled out firmware that fixed the incapability...

That's not a measurable metric though.

A speed increase could be due to any number of things, the most likely being DLM deciding to change the sync speed banding.

What made you think it was G.INP, given that ECI cabs and ECI modems don't support G.INP?

This is exactly my finding having had the opportunity to use both an A & B HH5 on the same line and having seen what happened when g.inp was enabled on my local cabinet (back last year from what I recall).

I've seen no definitive information from OR, and all that people are ever able to point to is posts people have made to various forums, none of which provide links to authoritative data sources. The issues over the OR modems are, in contrast, well documented and evidenced.

Of course the two HH5 models do not provide definitive information on g.inp status (or interleaving for that matter), but it's possible to make reasonable inferences from behaviour, other stats, especially when it's possible to compare the two models on the same line.

My belief is still that the HH5 model A is able to support downstream g.inp, but not upstream, based on comparing the stats and behaviour on the same line. The only real advantage with the model B that I can see is that the upstream sync is about 10% higher. I find stability to be similar with resyncs normally only on a 15 day scheduled cycle.

nb. one slightly odd incompatibility between the A & B models is the power supply jack. It looks identical (as is the voltage), but the type B power supply won't fit a type A HH5 as it has a slightly "fatter" central pin (but a type A power supply fits a type B HH5).

Yeah, this illustrates the problem - people make these announcements but no stats are ever provided as a comparison and the Homehub doesn't mention G.INP in it's limited stats that are available.

Note the power supplies are different ratings so shouldn't be swapped anyway.

Also note the HH5B is much chunkier and much heavier than the HH5A.

In reply to a post by TheEulerID:

My belief is still that the HH5 model A is able to support downstream g.inp, but not upstream, based on comparing the stats and behaviour on the same line.

I'm of the same belief - that the HH5A supports G.INP downstream only. Batboy is convinced that G.INP is not supported in either direction.

Meanwhile, there seems to be no direct evidence - only experiments by people like yourself, able to see the end result with a variety of devices.

Note that the Openreach requirements in SIN 498 are that it must support G.INP downstream, while support for G.INP upstream has always been optional.

However, they've just released a new version of 498 (v7), which now indicates upstream G.INP is expected to be turned on "in due course", and "strongly recommends" that G.INP be implemented in both directions.

its a bit late to amend the requirements after millions of vdsl devicers have been rolled out?

We'd better drop VDSL2 then because of all the ADSLx devices in use.

In reply to a post by WWWombat:

I'm of the same belief - that the HH5A supports G.INP downstream only. Batboy is convinced that G.INP is not supported in either direction.

Meanwhile, there seems to be no direct evidence - only experiments by people like yourself, able to see the end result with a variety of devices.

Note that the Openreach requirements in SIN 498 are that it must support G.INP downstream, while support for G.INP upstream has always been optional.

However, they've just released a new version of 498 (v7), which now indicates upstream G.INP is expected to be turned on "in due course", and "strongly recommends" that G.INP be implemented in both directions.

Agreed- I also believe that the HH5A supports G.INP downstream but will go further and say its capable of supporting G.INP upstream as well if/when BT roll out a firmware update.

That's all very well but I'm actually running a HH5A and I assure you, it does not.

Disagree all you like, but please say whether you're running a HH5A or not.

In reply to a post by Chrysalis:

its a bit late to amend the requirements after millions of vdsl devicers have been rolled out?

It's a bit late only if you need to tighten the requirements. Not to loosen them.

Upstream G.INP remains optional, so this requirement hasn't changed. The test specification has now clarified a couple of the tests to say which of them applies when the device only supports downstream G.INP, and which applies when the device supports both directions.

The V7 SIN does have an additional requirement: that the device support vectoring at the same time as downstream G.INP, and adds a test specification for this.

I wonder if that impacts any devices? I wonder what prompted them to add a test of the combination, given that they already have tests of the 2 features independently.

I'll read the ever-growing SIN some other time, but that last point is interesting as vectoring seemed to have disappeared into the long grass since G.FAST came along.

(I wonder if it is yet the longest ever SIN?)

Yes - I wonder about this too. Why keep concentrating on vectoring down in the details, when strategy is going elsewhere?

I wonder if it really means that vectoring isn't on the front burner, in the sense that there will be no programme to roll it out *deliberately* , but it remains on a back-burner.

I recall that the expected life of the electronics within the cab was perhaps half of that of the cab itself, though that is from a long time ago. Perhaps there will be a rolling programme of in-life upgrades to the cabs, even while G.fast is being rolled out, and we could expect vectoring to be a natural part of the upgrades then.

Or perhaps it is a backup plan, in case G.fast doesn't pan out.

Well I have both an HH5A & HH5B and both (in a downstream direction) give pretty well identical results on two lines (and on one of those lines, I actually saw what difference it made when it was enabled).

Quite how you can say for certain g.inp isn't working on your particular HH5A, I've no idea. You can only really work it out by inference on behaviour. In any event, just because it's not working on your particular combination doesn't mean it doesn't work at all. My experience indicates that it does.

I would prefer proof rather than guesswork. We can all guess. My guess is the HH5A doesn't do G.INP.

Edited by deleted (Sat 23-Jan-16 16:08:26)

In reply to a post by BatBoy:

That's all very well but I'm actually running a HH5A and I assure you, it does not.

Disagree all you like, but please say whether you're running a HH5A or not.

Yes, I have both a HH5A and a HG612 - both showed an improvement in my maximum attainable sync rate once G.INP was enabled on the line.

Not sure how you can assure me the HH5A doesn't have G.INP when all the evidence is to the contrary.

FWIW Openreach made support for downstream retransmission (G.INP) a mandatory requirement of its CPE testing for VDSL modems in June 2013. The HH5A was launched after this...

Because I prefer proof to conjecture and I assume the worst until proved otherwise. Incidentally G.INP is a lot more than an increase in sync. A sync increase can be due to fastpath rather than interleaving.

In reply to a post by BatBoy:

Because I prefer proof to conjecture and I assume the worst until proved otherwise. Incidentally G.INP is a lot more than an increase in sync. A sync increase can be due to fastpath rather than interleaving.

With respect, by all means prefer proof to conjecture and feel free to assume the worst until proved otherwise if you want.

BUT you are making categorical statements that the HH5A does not support G.INP which is not the same thing as not knowing if it does or not.

As I have two modems available - one of which is a HG612 - I can get view the modem stats for my line and tell that G.INP has been turned on. The sync speeds when I had fastpath and interleaving applied to this line instead were difference

You can't tell this is you only have a HH5A.

I have also stated that one of Openreach's requirements for its VDSL CPE connected to its network is that it supports downwards G.INP

Given the HH5A was launched after this are you perhaps suggesting that:

1. BT Retail didn't let Openreach test the HH5A?; or that
2. the HH5A failed the mandatory Openreach CPE spec but BT Retail rolled it out anyway?

Hopefully, you will accept both are unlikely.

I think you know that other VDSL modems using the same chipset as the HH5A also support G.INP..

If you still don't accept that the HH5A supports G.INP thats fine - its your view - but don't go about proclaiming it as "a fact" which is what you keep doing.

Edited by gt94sss2 (Sun 24-Jan-16 13:50:07)

There is a list of devices approved by Openreach and the HH5A isn't on it, which speaks volumes.

Link?

You will also know that Plusnet have only recently adopted the HH5A for their own fibre service as well which they wouldn't have done if it wasn't fit for purpose.

Edited by gt94sss2 (Sun 24-Jan-16 14:42:38)

I'm not saying the HH5A or the Hub one isn't fit for purpose, mine is very stable. It's just that they don't support G.INP.

If they did, I'm sure some enterprising user or supplier would be very eager to provide evidence - which is so far, non-existent.

For example: the Huawei HG612 can be shown to have G.INP active and working. Similarly, the ECI modem can be shown to not have G.INP, for it to be inactive. Further the ECI modem can have modified firmware that will activate G.INP.

None of this is possible with the HH5A so it is impossible to be shown to have G.INP active and working.

In reply to a post by BatBoy:

There is a list of devices approved by Openreach and the HH5A isn't on it, which speaks volumes.

Evidence?

It seems so.

NO! Where is it....

You've provided no links to any evidence and to be fair no other user or forum has mentioned any other such evidence so I think you might be talking .........

That's what I'm saying - without any evidence it's all just opinion. What I want is proof.

Your saying you have documentation from Openreach not listing the HH5a. however you haven't provided a link and I you haven't said if the HH5b was listed?

As far as I'm concerned the HH5B supports G.INP. It's wireless throughput is very poor though, so between the two I prefer the HH5A - until my connection starts playing up.

LMAO... That's Nice....

In reply to a post by gt94sss2:

Link?

You will also know that Plusnet have only recently adopted the HH5A for their own fibre service as well which they wouldn't have done if it wasn't fit for purpose.

Yeah... I don't think we're getting a link.. or any type of evidence for that matter... this area stinks... almost like someone.......

Are you using a HH5A?

Type B..... however synced on fast path with an attainable of over 110Mb/s so no need for G.INP right now...

However I've told you before that I've done a lot of testing at the time G.INP was enabled and can be certain that HH5a is G.INP capable...

If your hub don't work with G.INP it must be a dud or your lines capability shrunk around the time G.INP came about... its not like you can prove G.INP is enabled or not... a HH don't tell such tales....

In reply to a post by mlmclaren:

its not like you can prove G.INP is enabled or not... a HH don't tell such tales....

I know, that's what I've been saying. So your assurance it does is to be taken with a pinch of salt.

In reply to a post by BatBoy:

In reply to a post by mlmclaren:

its not like you can prove G.INP is enabled or not... a HH don't tell such tales....

I know, that's what I've been saying. So your assurance it does is to be taken with a pinch of salt.

So why do you keep on insisting it doesn't support it then... the facts say that it does and currently your saying it doesn't support it based on using one and not being able to tell...

I accept your arguments of there being no 'official' evidence however this doesn't mean you can continue to tell the 'majority' it doesn't...

Edited by mlmclaren (Sun 24-Jan-16 16:14:26)

Because if it did, there would be evidence. As someone pointed out, a GEA test result would show if retransmission was present on a line having a HH5A.

And although Plusnet have been known to post GEA test results, (though not for the Hub One so far as I know), or at least give them to customers who have posted them, it is only posters who have decided the Hub One is a rebadged HH5A.

It is certainly based on the HH5A, or whatever that is based on, that has been confirmed by Plusnet, but we haven't been told of any internal or firmware changes that may or may not have been made.

We do know of one obvious configuration change at least.

So GEA test results from one of those wouldn't help, and the assertion earlier that the deployment of it means the HH5A is downstream G.INP compliant is unsafe.

In reply to a post by RobertoS:

We do know of one obvious configuration change at least.

Not having been a Plusnet customer for a while, out of interest what config change do you refer too?

So GEA test results from one of those wouldn't help, and the assertion earlier that the deployment of it means the HH5A is downstream G.INP compliant is unsafe.

Unlike BB appears too, I hope you would accept that support for downstream G.INP was a mandatory requirement when the HH5A was launched - and would have had to have demonstrated this in order to be approved as a CPE (even if you discount the experiences of those who have multiple CPEs to play with)

Edited by gt94sss2 (Sun 24-Jan-16 16:55:55)

They disabled smart setup.

It's not "guesswork" on my part, it's a reasonable conclusion based on a number of experiments and observations. That's a long way from a "guess", even if it isn't definitive proof. Unfortunately nobody appears to be able to produce this, one way or another.

Can you detail an experiment to demonstrate G.INP?

I know of at least one ISP who is currently issuing non-approved modem/routers. OR approval is not compulsory.

I've also seen somewhere a list of approved ones, but haven't managed to find it yet. It's not high up my priority list .

Edited by RobertoS (Sun 24-Jan-16 18:38:50)

In reply to a post by RobertoS:

I know of at least one ISP who is currently issuing non-approved modem/routers. OR approval is not compulsory.

Could you say who/which modem?

I would have thought under their contracts with OR issuing the correct equipment was a requirement.

I've also seen somewhere a list of approved ones, but haven't managed to find it yet. It's not high up my priority list .

Or mine - but neither of us was the one who raised it

Nor mine. I read it somewhere and remembered the salient points.

In reply to a post by BatBoy:

Your cabinet is a Huawei so G.INP is available but your HH5A doesn't support G.INP. I recommend you get a Huawei HG612 v3B and unlock it with the B030SP08 firmware. You can then plug this into the HH5A and get G.INP

OK managed to pick up a HG612 off ebay, now do I need to unlock it to see its stats and if so how?

No immediate change with download speed but the upload has incleased from 8.5-9Mb/s to 9.5Mb/s.

thanks!

See here http://www.kitz.co.uk/routers/hg612unlock.htm

and here http://forum.kitz.co.uk/index.php/topic,14262.0.html

I recommend you use the _webgui version which has the BT Agent turned off.

You've checked it isn't already unlocked?

In reply to a post by BatBoy:

See here http://www.kitz.co.uk/routers/hg612unlock.htm

and here http://forum.kitz.co.uk/index.php/topic,14262.0.html

I recommend you use the _webgui version which has the BT Agent turned off.

Unfortunately the links are either out of date or a bit sparse.

So I unplugged the HH5 from LAN2 on the HG612 and plugged the PC into LAN1.
Set the IP address of the PC to 192.168.1.100 (what to set the subnet mask to? And the default gateway?)

Powered off the modem, then pressed reset, powered back on and held reset for 5s. The power and LAN2 lights were both flasing.

Tried to acess 192.168.1.1 on the PC but it said page could not be found...

What am I doing wrong?

In reply to a post by RobertoS:

You've checked it isn't already unlocked?

How do I do that?

Subnet mask is 255.255.255.0. Gateway would be 192.168.1.1 but it doesn't actually matter as you are using it to get at the modem/router not the Internet.

In reply to a post by ian72:

Subnet mask is 255.255.255.0. Gateway would be 192.168.1.1 but it doesn't actually matter as you are using it to get at the modem/router not the Internet.

Yes I tried using them. Made no difference. A netstat -r shoowed up all the same old addresses as before, no sign of e.g the new gateway or the HG612 address.

if you do an ipconfig does it show the new IP address on the LAN adapter?

Can you ping the router? If so, try an ipconfig /flushdns and then try reconnecting to router again. Shouldnt' make a difference but I've seen stranger thing happen in the past

Edited by WelshWArrior (Thu 28-Jan-16 13:09:24)

In reply to a post by ian72:

if you do an ipconfig does it show the new IP address on the LAN adapter?

Before:
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : home
Link-local IPv6 Address . . . . . : fe80::e463:3cf8:aba6:3ed8%10
IPv4 Address. . . . . . . . . . . : 192.168.1.68
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.254


After:
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::e463:3cf8:aba6:3ed8%10
Autoconfiguration IPv4 Address. . : 169.254.62.216
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

Here's what I did, please correct me if I missed something (Windows 7 btw):

1) Control Panel->Network and Internet->Network and Sharing Centre->Local Area Connection
Properties on dialog->Internet Protocol v4->properties
Use the following address:
IP address 192.168.1.100
subnet mask 255.255.255.0
gateway 192.168.1.1

2) plugged ethernet cable from PC into LAN2, disconnected HH5 from LAN1

3) powered down HG612

4) Held down reset button, power up modem and waited 5s (and a bit). Both power and LAN2 lights flashing.

5) set browser to 192.168.1.1

6) Browser says can't find web page...

IIRC you should be connecting to LAN1 to do the flashing. The point being that LAN2 is currently disabled.

In your "after" the adapter is not using the static IP so something is configured wrong. Can you paste the full results of an

ipconfig /all

when you have it set up with the static IP?

In reply to a post by ian72:

In your "after" the adapter is not using the static IP so something is configured wrong. Can you paste the full results of an

ipconfig /all

when you have it set up with the static IP?

Here it is:

Windows IP Configuration

Host Name . . . . . . . . . . . . : OGRI
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controlle
r
Physical Address. . . . . . . . . : 00-1E-4F-CA-8A-83
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::e463:3cf8:aba6:3ed8%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.100(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 234888783
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-7A-C3-E3-00-1E-4F-CA-8A-83

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1
Physical Address. . . . . . . . . : 00-50-56-C0-00-01
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::7088:ba2d:a701:1061%24(Preferred)
Autoconfiguration IPv4 Address. . : 169.254.16.97(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 486559830
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-7A-C3-E3-00-1E-4F-CA-8A-83

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
8
Physical Address. . . . . . . . . : 00-50-56-C0-00-08
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::c44b:6931:22db:8e8d%25(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.8.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 503337046
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-7A-C3-E3-00-1E-4F-CA-8A-83

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{E44E9299-74ED-44FA-B9B2-2A4B83B97339}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.apache-da.com:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{A900A309-7CD7-4892-85F1-48642D815936}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Local Area Connection* 14:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Reusable ISATAP Interface {E3433703-2B15-414E-B145-72D8300B6844}:


Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #7
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.home:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Reusable ISATAP Interface {408B0DA4-E511-4BBE-B9B1-67295E3ACE12}:


Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #8
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{58D2D82A-C27D-4973-8BEF-8CA54FA5E75B}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #9
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

C:\Users\keith>

OK, that confirms your network adapter does have the new IP Address configured. I'm afraid that is as far as I can go then as I don't have access to an H612 - but your network adapter does look to be correctly configured. Sorry.

EDIT : Did you do this bit of the instructions?

Press the RESET button on the modem and keep it pressed.
5.Do not release the button yet.
6. Power on the modem.
7. Keep the RESET button pressed for a further five seconds.

From here

Edited by ian72 (Thu 28-Jan-16 13:47:40)

Yes I followed that bit. Oh well, at least I'm getting an improvement in upload speed.

Following on from my original thought, was this sold with no mention of already being locked or unlocked?

There's a vague possibility it is unlocked and someone has set it to a different IP address than 192.168.1.1.

I suggest doing a factory reset on it. That will either set it to OR defaults or to the defaults of the flashed version. In other words it will ensure it is on 192.168.1.1. Then try again.

In reply to a post by RobertoS:

Following on from my original thought, was this sold with no mention of already being locked or unlocked?

There's a vague possibility it is unlocked and someone has set it to a different IP address than 192.168.1.1.

I suggest doing a factory reset on it. That will either set it to OR defaults or to the defaults of the flashed version. In other words it will ensure it is on 192.168.1.1. Then try again.

Good idea. As it was from eBay there was no indication it had been unlocked but I guess it's worth a try.

Latest update: I managed to unlock the HG612 today and get access to stats.

According to the TBB checker, my average download speed has gone down to 39.11 Mb/s and the upload is now 10.7Mb/s. When I was first connected back in July I was getting about 54Mb/s download, 8.5Mb/s upload on a HH5A only.

The info from the HG612 is appended. Does this look normal i.e. is the speed dropoff on download due to crosstalk and the increase on upload due to the HG612 supporting G.INP (the increase happenned when I started using the HG612, but the download has been getting slowly worse ever since lasy July)?



# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 12683 Kbps, Downstream rate = 51360 Kbps
Bearer: 0, Upstream rate = 12687 Kbps, Downstream rate = 43998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps



# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 12683 Kbps, Downstream rate = 51360 Kbps
Bearer: 0, Upstream rate = 12687 Kbps, Downstream rate = 43998 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): 8.1 6.1
Attn(dB): 20.4 0.0
Pwr(dBm): 12.4 7.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 89 227
M: 1 1
T: 0 0
R: 8 14
S: 0.0648 0.5716
L: 12108 3387
D: 8 4
I: 98 242
N: 98 242
Q: 8 4
V: 3 0
RxQueue: 135 21
TxQueue: 27 7
G.INP Framing: 18 18
G.INP lookback: 27 7
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 21352688 2428343
RSCorr: 79 13
RSUnCorr: 0 0
Bearer 1
OHF: 21665 21690
OHFErr: 0 0
RS: 129619 86763
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 227561531 1
rtx_c: 15 4307
rtx_uc: 0 8202

G.INP Counters
LEFTRS: 0 98
minEFTR: 43989 12688
errFreeBits: 233508 86033498

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 29423105 0
Data Cells: 16661 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 31 31
AS: 349

Bearer 0
INP: 55.00 45.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 44305.29 12714.56

Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87

Bitswap: 106/106 18/18

Total time = 6 min 20 sec
FEC: 79 13
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 6 min 20 sec
FEC: 79 13
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 6 min 20 sec
FEC: 79 13
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 min 47 sec
FEC: 79 13
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

I haven't time to think about those stats in depth but notice a couple of things.

1) From your suspiciously close to 44000kbps sync and 8.1dB SNRM after 6 minutes uptime I think the line has probably been banded.

2) Not only is G.INP enabled, it is also operating on your upstream. That may be why the upstream interleaving D: line is set to 4 rather than the normal 1.

I believe that now you have the HG612 running that in a few weeks the banding will be removed and your speed increase.

So the reality in this thread seems to be that there's still no evidence to suggest the HH5a isn't capable of G.INP on the 'downstream' and that upstream G.INP is coming back,

However changing from the HH5a to the HG612 would show the line as being Fastpath/Interleaved (If it wasn't capable of G.INP) for little while whilst DLM determined the change and placed the line on a G.INP profile...

SO would this continue to lean towards saying the HH5a is indeed capable on 'downstream' and the small boost seen when the HG612 was connected was the configured G.INP being used to its full potential...

However what hasn't been mentioned is whether any decreases in latency has been seen since the swap?

In reply to a post by BatBoy:

Because if it did, there would be evidence. As someone pointed out, a GEA test result would show if retransmission was present on a line having a HH5A.

Have you got the results of a GEA test to hand... though I will probably see if someone on Plusnet could get such things though things on that ship have certainly changed since I was a customer so they might not share that stuff anymore.

The fact that the Plusnet Hub One is the same hardware as an HH5A doesn't mean the firmwares are the same.

Of course, however the likelihood of BT & Plusnet HH5a's having different DSL specification's is very unlikely surely?