Kitz Forum
Broadband Related => Broadband Technology => Topic started by: kitz on April 09, 2016, 12:23:38 PM
-
As already reported Openreach commenced rollout of G.INP to their ECI estate in March 2016 (http://forum.kitz.co.uk/index.php/topic,17286.0.html).
We have been following progress of the roll-out and for the vast majority of lines this appears to have been successful, with most users have seen an increase in their sync rates.
However, it became apparent a few days ago that some lines were seeing behaviour that looks suspiciously like the ECI modem - Issue 1 problem (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1). Affected lines are able to sync but not get a valid PPP session.
Openreach have identified those lines which they suspect could be susceptible to this particular fault.
As a precaution Openreach has ceased rollout of g.inp for those affected lines only.
Retransmission has also been removed from any lines which have an increased risk of developing this fault regardless if they were affected or not.
Links:
What is G.INP Retransmission? (http://www.kitz.co.uk/adsl/retransmission.htm)
Questions about Openreach implementation of G.INP (http://www.kitz.co.uk/adsl/ginp-retransmission.htm)
G.INP - BT rollout 2015 (http://forum.kitz.co.uk/index.php/topic,15283.0.html)
ECI cabinets & G.INP discussion (http://forum.kitz.co.uk/index.php/topic,17195.0.html)
-
I dont know for certain and I must stress that this is just pure speculation on my part, but Im wondering is the 'affected lines' could perhaps be those on ECI cabinets which were updated to IFTN:0xb206.
This update had some sort of fix applied in respect of the upstream FEC count.
-
thanks for the update kitz, I am confused tho by this line.
"As a precaution Openreach has ceased rollout of g.inp has ceased for those affected lines only."
Have they suspended the rollout or have they just suspended it for those lines identified as problematic? So in other words what does it mean for people like me who havent been moved over yet.
For reference my cabinet is 206.
-
Hello Kitz,
Your comment about IFTN:0xb206 appears to tie in with my line. Since the flurry of activity with the news of rollout of G.inp to ECI cabinets, I have been eagerly waiting to see what effect it might have on my line. It appears from stats displayed in DSLstats that my local cabinet is indeed IFTN:0xb206, and there has been no indication that G.inp has been applied to my line. The only thing that I did notice was that on or around 23 March, my power levels were reduced from 11 DS to 2.9 and 2.9 US, which seems to have followed a resync at this time.
I suppose it's a waiting game again, until the boffins sort this problem out.
toulouse
-
Have they suspended the rollout or have they just suspended it for those lines identified as problematic?
Its not been totally suspended - Only for those lines which Openreach suspect could develop a problem.
-
For reference my cabinet is 206.
Your comment about IFTN:0xb206 appears to tie in with my line.
Thanks guys for the confirmation. So far its looking like it may be.
I dont know yet what they are going to do. If it is that, then presumably they either need to roll back to IFTN:0xb204 or put a fix out for 206.
-
ok thanks, so its possible somehow they have detected my line to be in the category of risk and took it out of the queue for migration.
you think its 206 lines that are been suspended then?
-
Its looking like it, but its speculation on my part. I dont have anything official that says whether it is or not.
-
Then again, it may not be. Just noticed mikeZ still has g.inp and I think he's on 206.
Will have to wait see if his gets removed over the next few days.
---
ETA
I now think it may be a Red Herring!
mikeb (http://forum.kitz.co.uk/index.php/topic,17443.0.html) is showing typical signs of the problem, but according to his stats ATU-C Information Vendor ID: b5004946 544eb204
---
Edited again.
On closer inspection of stats - this leads me to suspect a modem issue rather than ECI cab specific.
-
Then again, it may not be. Just noticed mikeZ still has g.inp and I think he's on 206.
Will have to wait see if his gets removed over the next few days.
---
ETA
I now think it may be a Red Herring!
mikeb (http://forum.kitz.co.uk/index.php/topic,17443.0.html) is showing typical signs of the problem, but according to his stats ATU-C Information Vendor ID: b5004946 544eb204
I am on a 206 version and lost g.inp yesterday.
Cheers
-
I think the 206 reasoning is logical, we will have to wait and see if other 206 users get disabled, or if other 206 users get enabled.
-
I am still on 206 with G.inp at the moment
-
ETA
I now think it may be a Red Herring!
mikeb (http://forum.kitz.co.uk/index.php/topic,17443.0.html) is showing typical signs of the problem, but according to his stats ATU-C Information Vendor ID: b5004946 544eb204
Having just looked at mike's stats in more detail. It's far more likely that in his case the issue was with modem firmware not being g.inp compatible. After updating with new firmware the line is now showing more normal behaviour. An Openreach Engineer has also recently reset the DLM, which is probably why he now has downstream interleaving and no g.inp.
-
I am still on 206 with G.inp at the moment
I have no idea if/when it will be removed.
It has taken them a several weeks so far to get around to applying retransmission on those lines they have as there's only so many they can do in one day.
It was only a couple of days ago that they decided to start reversing it, so this will take longer than suspending.
I'm sure I said somewhere in the long thread about 2015 roll-out (http://forum.kitz.co.uk/index.php/topic,15283.0.html) how many lines they could do per night, but I cant recall what that figure was now.
-
I had a reset last night about 1am, IP profile has risen back up to 46Mb and latency has dropped back down to it's normal 13-15ms It could well be that G.INP has been turned off on my line as Bob on the Plusnet forum said was happening Or Openreach already has a fix i dunno, I can't confirm if G.INP is off until tomorrow when the Plusnet staff are around to check due to my locked Openreach ECI modem but i have a feeling it's off because everything is as it was before G.INP was enabled
seems things are indeed not going to plan ECI G.INP Mk2 incoming sometime soon :D.
-
If you consider they need to have board meetings, run trials for potential fixes and so forth, I would be surprised if we had a fix before June.
I am hoping my line hasnt been pulled and I am simply very late in the rollout, but I have a feeling the 206 reasoning is correct and I am in the set of lines pulled from the rollout.
-
I am hoping my line hasnt been pulled and I am simply very late in the rollout, but I have a feeling the 206 reasoning is correct and I am in the set of lines pulled from the rollout.
I am sorry Chrysalis but you should have had G.INP acitvated by now and the delay looks like its has been pulled as you call it but at least your still on the so called fastpath profile nothing is going to change to what you already see in the stats.
I just can't believe my eyes we are seeing the same situation acting out again this time on the ECI cabinets most people seeing great results and others seeing negative results.
You would have thought Openreach got their fingers burnt with G.INP Mk1 on huawei cabinets in May 2015 and the ECI G.INP rollout would go very smooth this time with the knowledge they gained.
It looks like ECI issue 2 those bloody ECI modems and HH5a but seeing not much activity on BT forums yet the source seems to be coming from the Plusnet Forums
-
well I am not even using an ECI modem.
-
I just can't believe my eyes we are seeing the same situation acting out again this time on the ECI cabinets most people seeing great results and others seeing negative results.
You would have thought Openreach got their fingers burnt with G.INP Mk1 on huawei cabinets in May 2015 and the ECI G.INP rollout would go very smooth this time with the knowledge they gained.
It looks like ECI issue 2 those bloody ECI modems and HH5a but seeing not much activity on BT forums yet the source seems to be coming from the Plusnet Forums
Sorry NS, Ive read your post about 6 times and cant make out what you are trying to say here.
What do you mean about ECI and HH5a and issue 2 and BT and Plusnet forums? Im confused?
This is a totally different issue to what happened with G.INP Mk1.
What has happened this time is that a number of users have been unable to obtain PPP. The modem syncs up, but doesn't connect to the ISP.
ie the ECI Issue 1 problem (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).
They have identified which lines this problem could to happen to... and for those lines only they have ceased the roll-out regardless if the EU has a problem or not.
I suspect that its the 206 cabs. 206 cabs had some type of new firmware rolled out about 2 months ago.
Those of us on 204 seem ok, but then again anyone on here is most likely to have fully g.inped modems anyhow.
As I mentioned in my earlier post I am speculating about it being 206, it certainly looks like the 206 change could somehow affected something to do with g.inp.. and whatever it is, it causes problems for some people to establish a PPP session.
So it looks like what Openreach is doing is removing g.inp for people on those cabinets so that the affected users can at least get online.
I have a niggle about 206 FEC/EMP whatever number it was, that I cant quite put my finger on... but I wont speculate further and make out 2+2 equals 5
I dont have much more info other than appx how many lines have the potential to be affected but I have absolutely no idea of how many actually are affected - TBH Im not even sure if all ISPs are aware yet.. or even if its filtered down to the OR engineers yet, because its was less than a week ago that they identified the problem.
-
BTW
If someone cant get PPP, then they aren't very likely to be posting about it on forums, because they wont be able to get online to post, so most of the support will be say via phone. The average man in the street wont know about the difference between sync and PPP - as far as they are concerned they struggle to connect to the internet. These are the type of posts we should be looking out for.
Even then we have to be careful, you can see here (http://forum.kitz.co.uk/index.php/topic,17446.msg318653.html#msg318653) that initially mikeb was displaying all the signs that his line could be related to the issue because he was having difficulty obtaining PPP, however when I actually sat down and looked at the stats in more depth, his problem was that he was using a Draytek router that was known to have problems with g.inp Mk1. He's updated his f/w and since then things appear to have been stable. So I think in his case it was the Draytech using old f/w.
- note he said he could connect using a HG633, but things have since been complicated further because the OR engineer did a DLM reset. A DLM reset for G.INP'd lines will cause interleaved to be applied by default and he will have to wait for DLM to put g.inp back on again.
-
BTW
If someone cant get PPP, then they aren't very likely to be posting about it on forums, because they wont be able to get online to post, so most of the support will be say via phone. The average man in the street wont know about the difference between sync and PPP - as far as they are concerned they struggle to connect to the internet. These are the type of posts we should be looking out for.
Even then we have to be careful, you can see here (http://forum.kitz.co.uk/index.php/topic,17446.msg318653.html#msg318653) that initially mikeb was displaying all the signs that his line could be related to the issue because he was having difficulty obtaining PPP, however when I actually sat down and looked at the stats in more depth, his problem was that he was using a Draytek router that was known to have problems with g.inp Mk1. He's updated his f/w and since then things appear to have been stable. So I think in his case it was the Draytech using old f/w.
- note he said he could connect using a HG633, but things have since been complicated further because the OR engineer did a DLM reset. A DLM reset for G.INP'd lines will cause interleaved to be applied by default and he will have to wait for DLM to put g.inp back on again.
just thought it was worth mentioning I had no issues with access to the net with g.inp on my 206 cab. What I did see was high upstream es which seems to have led to reysnc at which point it was removed be it BT OR or DLM . I am not sure which one it was in the end as I was away and my monitoring was down at the time.
-
kitz I havent read about anyone been unable to connect at all I had assumed this was suspended (I hope not a complete cease) because of the increase of tech support calls, from people not been happy about losing sync speed etc.
I trust you got this from a reliable source so its accurate regarding the PPP and I accept those who cannot get online will have been most likely reporting it by phone rather than internet.
-
I had no issues with access to the net with g.inp on my 206 cab.
That will be because you were using the Billion which is fully g.inp compatible.. and then later the ECI with custom F/W with g.inp support.
The PPP problem is something we were pre-warned about as far back as 8th of Jan 2015 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1) which could affect the ECI modems.
Openreach have without a doubt received an increase in call-outs over the past week or so from people who cant get PPP, so an engineer has had to be sent out who confirmed PPP type faults. Last week they identified which lines (on certain cabs?) are most likely to experience this issue.
It's strange that in 2015 they anticipated this may happen and even warned to look out for it.... but we never really saw much of it on the Huawei cabs and the type1 issue was much of a non-event. Yet now theyve rolled it out to the ECI's suddenly it is. ???
-
kitz I havent read about anyone been unable to connect at all I had assumed this was suspended (I hope not a complete cease) because of the increase of tech support calls, from people not been happy about losing sync speed etc.
Not fully suspended across the whole ECI estate. Just for those lines identified that had potential to be affected by the PPP issue even though they weren't seeing it. They did this as a preventative measure even though the vast majority had no issues.
The above is fact from a reputable source.
----
The following is speculation on my part & trying to read between lines, but say as they got to about 75% of the rollout, they noticed that call-outs for people having problems with PPP were clustered in certain areas and on certain cabs.
The number wasnt very high, but as a preventative measure they decided to stop rollouts to people who were on those cabs. The cab was g.inp active, but as we know not everyone in the same area gets the DLM g.inp part activated at the same time.
A hypothetical scenario could have been that an engineer noticed that 2 people on Chrys's cab couldnt connect to the Internet... but Chyrs himself hasnt yet had the DLM part updated.. best not do that because we dont know if Chrys has a modem which might stop him from being able to connect.. but what they dont know is that Chrys has a Billion so would be ok.
Because g.inp is a 2 part process at the cab f/w level and at the DLM level, Im guessing they will be removing the DLM aspects for those currently already on DLM so they can reverse whatever is wrong at cab level. Its looking like a bug was introduced in 206 that only affects some modems. I guess we need to watch over the next week if those being removed are the 206 cabs.. so far it is looking like it. However we only have a small representation on MDWS, so as yet were not able to draw a positive conclusion.
-
kitz I havent read about anyone been unable to connect at all I had assumed this was suspended (I hope not a complete cease) because of the increase of tech support calls, from people not been happy about losing sync speed etc.
Not fully suspended across the whole ECI estate. Just for those lines identified that had potential to be affected by the PPP issue even though they weren't seeing it. They did this as a preventative measure even though the vast majority had no issues.
The above is fact from a reputable source.
----
The following is speculation on my part & trying to read between lines, but say as they got to about 75% of the rollout, they noticed that call-outs for people having problems with PPP were clustered in certain areas and on certain cabs.
The number wasnt very high, but as a preventative measure they decided to stop rollouts to people who were on those cabs. The cab was g.inp active, but as we know not everyone in the same area gets the DLM g.inp part activated at the same time.
A hypothetical scenario could have been that an engineer noticed that 2 people on Chrys's cab couldnt connect to the Internet... but Chyrs himself hasnt yet had the DLM part updated.. best not do that because we dont know if Chrys has a modem which might stop him from being able to connect.. but what they dont know is that Chrys has a Billion so would be ok.
Because g.inp is a 2 part process at the cab f/w level and at the DLM level, Im guessing they will be removing the DLM aspects for those currently already on DLM so they can reverse whatever is wrong at cab level. Its looking like a bug was introduced in 206 that only affects some modems. I guess we need to watch over the next week if those being removed are the 206 cabs.. so far it is looking like it. However we only have a small representation on MDWS, so as yet were not able to draw a positive conclusion.
I suppose the issue I still can't get my head round was I was/am still using a fully g.inp compatible modem but I still lost the g.inp even though at the time the modem had been stable for a week. I guess maybe other users on my cabinet (version 206) were having issues so if they removed it from the cab or exchange I was affected as well ??? ???
-
Many thanks Kitz for explaining what is going on with those 206 ECI cabinets it's the fully g.inp compatible modems which has me confused yes the HG612 is an the Billion 8800nl and Zyxels are and others.
Ok I am going stop beating around the bush it looks like the ECI modems and HH5a's do not support G.INP in any directions and they just use the Fastpath or Interleaving profiles and the ECI cabinet update to v206 has made those modems unable to get a PPP session since the G.INP rollout.
-
Many thanks Kitz for explaining what is going on with those 206 ECI cabinets it's the fully g.inp compatible modems which has me confused yes the HG612 is an the Billion 8800nl and Zyxels are and others.
Ok I am going stop beating around the bush it looks like the ECI modems and HH5a's do not support G.INP in any directions and they just use the Fastpath or Interleaving profiles and the ECI cabinet update to v206 has made those modems unable to get a PPP session since the G.INP rollout.
Bear in mind the flashed openwrt eci modem does support g.inp as I used it and saw 8-9mb increase on ds plus a large drop in latency. I only stopped using it due to missing the online stats with mydslwebstats...
-
Bear in mind the flashed openwrt eci modem does support g.inp as I used it and saw 8-9mb increase on ds plus a large drop in latency. I only stopped using it due to missing the online stats with mydslwebstats...
I fully understand have a fully working G.INP Arcadyan 63168 Modem & Router but no access to DSLstats when using that modem have to use my trusty HG612 which gives me - 4Mbps on the downstream than the Arcadyan 63168.
The Billion 8800nl would be the best for both worlds :fingers:
-
I've been away for a few days & as I'm only just starting to catch up, I wasn't aware of the issue.
FWIW, I have attached the 12 day Full__Monty montage using a HG612 modem from a line connected to an ECI DSLAM (ChipSet Vendor Id: IFTN:0xb204), where G.INP was applied 1st April & then deactivated again 8th April.
Interestingly, US CRCs & ES increased when G.INP was applied yet unlike the other stats, they haven't really changed much since G.INP was deactivated.
This may/may not be a different issue though????
-
I can say that it was deffo 8th April the deactivating began. :)
-
Bear in mind the flashed openwrt eci modem does support g.inp as I used it and saw 8-9mb increase on ds plus a large drop in latency. I only stopped using it due to missing the online stats with mydslwebstats...
I fully understand have a fully working G.INP Arcadyan 63168 Modem & Router but no access to DSLstats when using that modem have to use my trusty HG612 which gives me - 4Mbps on the downstream than the Arcadyan 63168.
The Billion 8800nl would be the best for both worlds :fingers:
Whilst the 8800nl does indeed work on my line it syncs lower than the eci when g.inp was applied. Now g.inp is off it is showing high amounts of ds es where as post g.inp it was the other way around ???
Spoke to billion and sent them pre and post stats. Advised to use the older firmware so not totally convinced its the right choice for me
-
"Spoke to billion and sent them pre and post stats. Advised to use the older firmware so not totally convinced its the right choice for me"
Exactly why I have just ditched my 8800NL and moved to a TP-Link device! One with a Lantiq VRX268 chipset...
-
Exactly why I have just ditched my 8800NL and moved to a TP-Link device! One with a Lantiq VRX288 chipset...
Is your Billion 8800NL sitting in the corner gathering dust or has it found it's way onto ebay ?
-
"Spoke to billion and sent them pre and post stats. Advised to use the older firmware so not totally convinced its the right choice for me"
Exactly why I have just ditched my 8800NL and moved to a TP-Link device! One with a Lantiq VRX288 chipset...
Yeap much like the eci with openwrt. It synced the fastest out of all the tests once g.inp was applied. I just prefer having stats so at the moment its back on the billion till I can try somethimg else... latency was the same post g.inp
-
"Spoke to billion and sent them pre and post stats. Advised to use the older firmware so not totally convinced its the right choice for me"
Exactly why I have just ditched my 8800NL and moved to a TP-Link device! One with a Lantiq VRX288 chipset...
which tp model?
Although seems pointless as I could be stuck without g.inp for several months now and I think I have the honour of been the only forum member of not ever having g.inp activated.
-
No Chrysalis, you are not alone. I've also not been activated yet. Not really sure what it's going to buy me, but I live in hope.
toulouse
-
ok good to hear I am not alone :p
-
Is your Billion 8800NL sitting in the corner gathering dust or has it found it's way onto ebay ?
I will keep it a few more days until I am certain the TP-Link is as reliable.
-
which tp model?
A TP-Link VR200, £69.99 from Maplin with a 3 year warranty.
-
the ECI modems and HH5a's do not support G.INP in any directions and they just use the Fastpath or Interleaving profiles
Just a note on this.
According to Openreach, the HH5A and the ECI modem (as long as it has the updated f/w rolled out last year) support G.INP in the downstream direction only.
See question 3 here (http://www.kitz.co.uk/adsl/ginp-retransmission.htm), where I specifically asked about the HH5A and ECI modem.
-
This?
We have been seeing all users on Huawei cabs using ECI modems and the BT HomeHub 5A losing anything up to 10Mbps of downstream speed and experiencing large amounts of latency. The affected equipment is BT Openreach/BT Retail supplied that should surely comply with SIN498. Yet these are the ones seeing the most problems due to automatic DLM intervention -regardless if the line needed it or not - by application of Error Correction (RS overheads cause reduction in sync) and Interleaving (causes delay). The increased delay through application of Interleaving of 8ms may be the intention but we are often seeing more like 16ms added due to application to both upstream and downstream. What is happening?
As you note above, to comply with SIN 498, modems and routers must support retransmission in the downstream, but it is not a mandatory requirement in the upstream. Taking this into account and to maintain a high level of service, when we first rolled out retransmission to our Huawei estate we introduced interleaving on all lines where the modem/routers did not support retransmission in the upstream.
We found that in some occasions this introduced increased latency of approx. 8ms, and could also impact some downstream headline rates for some modem/routers.
As soon as we realised that for some modem/routers that don’t support retransmission in the upstream, that the introduction of interleaving in the upstream was causing issues, we set about trialling, and subsequently rolling out a reduced interleaving profile in the upstream. This trial has now completed, and all lines have returned to their normal pre-retransmission interleaved state.
Which bit confirms the HH5A and the ECI modem support G.INP?
-
Taken in the context of the question, which you have chosen not to quote, I don't think there can be any doubt that the modem/routers referred to are the ECI and HH5A.
-
As far as I know the HH5A and the ECI modem pre-date the amendment to SIN 498 for G.INP
-
SIN498 V5 in 2014 contained G.INP. The ECI's and HH5A firmware updates for G.INP were 2015. SIN498 certification is based on a combination of hardware and specific firmware.
-
Which was the firmware update for G.INP on the HH5A?
-
I refuse to be drawn into a debate about this. Suffice to say I don't believe any reasonable person could interpret the answer given to Kitz by OR as anything other than relating specifically to the ECI AND HH5A.
-
Maybe someone else knows which HH5A firmware was for G.INP?
-
For the HH5A: Software version 4.7.5.1.83.8.204 will support g.inp in the downstream direction only.
I suspect that it was a previous version that included the g.inp update, but that was buggy.
Im not sure when the ECI modem update was rolled out nor the version #, but probably most likely mid/late 2014 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).
Huawei modems were also upgraded mid 2014 (http://forum.kitz.co.uk/index.php/topic,14262.0.html).
-
For the HH5A: Software version 4.7.5.1.83.8.204 will support g.inp in the downstream direction only.
Thanks
-
As far as I know the HH5A and the ECI modem pre-date the amendment to SIN 498 for G.INP
They do, as does the HG612. Which is why they had to roll out f/w updates in order to comply with SIN498.
I spoke to Ian in person for the best part of and hour in Jun 2015 (http://forum.kitz.co.uk/index.php/topic,15598.0.html) and it was during this convo I asked if he would be prepared to put his name to some of the questions asked by our community in print. I also asked about ECI cabs, but he would not be drawn on the topic of upstream g.inp or vectoring.
Didnt manage to get permission to print anything until Aug 2015 as it had to be double checked and there was also a couple of other events that got in the way.
--
PS the specific reason I wanted it in print is because then there could be no doubt about some facts that I'd already been told.
-
Good idea.
I suppose the reason my HH5A doesn't support G.INP is that it didn't get the firmware upgrade.
-
I suppose the reason my HH5A doesn't support G.INP is that it didn't get the firmware upgrade.
Can see your stats on MDWS and you don't have G.INP enabled did you swap the HH5a over to HG612 modem for testing.
-
No, there was a problem on my line which needed an engineers appointment and he did a DLM reset. I guess G.INP will come back soon
-
Ok I see hope the issue has been fixed by the engineer
-
Well if not, they'll just have to come out again and have another go :)
I've tested the HH5A before and it doesn't seem to support G.INP but there's no way to tell for sure.
-
I've tested the HH5A before and it doesn't seem to support G.INP but there's no way to tell for sure.
Everyone keeps telling you the HH5A currently supports G.INP in the downstream direction only atm. If they updated the firmware, it could do it in both directions.
FWIT here (https://community.plus.net/t5/Fibre-Broadband/G-INP-suddenly-gone-from-line/m-p/1324231#M36685) is a Plusnet rep saying the HH5A does as well
Do you think BT/Openreach would have issued the model if it didn't (or that Openreach would have amended the SIN as they have otherwise)?
I suppose the reason my HH5A doesn't support G.INP is that it didn't get the firmware upgrade.
If you think your HH5A doesn't support it - leave it plugged it to upgrade its firmware - but not all lines are enabled for G.INP (only if DLM thinks its needed)...
-
It doesn't have the right firmware though
-
What firmware version does it have?
As I said in my earlier edit, If you think your HH5A doesn't support it - leave it plugged it to upgrade its firmware - but not all lines are enabled for G.INP (only if DLM thinks its needed)...
Software version 4.7.5.1.83.8.204 that Kitz quoted earlier was released in 2014 and is at least a couple of versions behind the latest version BT use
-
Its 4.7.5.1.83.8.173.1.4 and has been plugged in for months maybe a year
-
Its 4.7.5.1.83.8.173.1.4 and has been plugged in for months maybe a year
Ah, hadn't realised that - do the system logs show it connecting to the update server?
(edit: I presume you are using it as a router as you are reporting stats to MDWS - you don't have any firewall rules which could be blocking the HH5A?)
You could try performing a factory reset to default settings on the HH5A to see if that encourages it to upgrade. If not, I suspect you will need to call BT or use their online forum to get them to either upgrade it or replace it.
-
Its 4.7.5.1.83.8.173.1.4 and has been plugged in for months maybe a year
Dray I had a HH5A and that firmware is very old like 2013/2014
-
Yes it contacts the tr69 server. Those things have all been tried but BT refuse to replace it as its working properly.
-
My HH5 Type A hasn't received an update for yonks and its been playing up (i'm on an ECI cab installed in 2011). Anyway i asked on Facebook if anyone had a HH5 Type B they didn't want and to my absolute surprise someone said yes and they gave me it for nowt. The Type B updated its firmware that night and i then did a pinhole reset and my line has been brilliant since.
-
Yeah I'm sure the HH5B supports G.INP I just wish someone would prove the HH5A does too
-
Its 4.7.5.1.83.8.173.1.4 and has been plugged in for months maybe a year
Interesting- that is really old f/w :(
I don't know exactly which f/w it was enabled on.. all I know is that with regards to any BT equipment it is supposed to 'be capable with the latest firmware' and I made a note of the current f/w version in the main 2015 G.INP thread last year, which is also why I was able to quote that particular software version to you. As I also said above, I suspected it may have gone earlier, but that the prior version was known to have introduced several bugs.
If, as the others say your f/w relates to 2013/2014 then it may possibly not be.
I just wish someone would prove the HH5A does too
Typical signs would be an increase in latency of 8/16ms if your line isnt interleaved normally.
Sync speed is not a good indicator - Even on my own line prior to g.inp I got ~7Mbps difference between a Lantiq VRX-268 and BCM63168 based modems.
The best way to check would be to put the HH5A on your line and keep it on your line for at least a day so that DLM has a chance to catch up. Then whilst the HH5A is on the line ask your ISP to do a GEA service test to get your DLM profile.
See: How can I tell if G.INP / Retransmission has been applied to my line? (http://www.kitz.co.uk/adsl/retransmission.htm#retransmission-enabled)
You must ensure that the HH5A is on the line when they run the test and I recommend that it has been on for the previous 24hrs just as a precaution against it picking up any previous profile related to another router that may be fully g.inp capable. Whilst guides say DLM changes occur over night we have been seeing far more happen much later in the day - I may be being over cautious - but hence me recommending at least a day to ensure that the ISP is seeing the correct profile.
-
ask your ISP to do a GEA service test to get your DLM profile.
I have no idea who to ask for that
-
Anyway what's the point? We already know my HH5A firmware doesn't support G.INP. :doh:
-
Its 4.7.5.1.83.8.173.1.4 and has been plugged in for months maybe a year
You've probably tried it but a pinhole reset? My HH5 Type A firmware wasnt that old.
-
fraid so :comp:
-
ask your ISP to do a GEA service test to get your DLM profile.
I have no idea who to ask for that
Your ISP.
Raise a support ticket. I asked mine for one and got one... only cause I wanted to put the image up on the site - although they didnt know that.
Say your HH5A is on old f/w and wont update or something and you want to know your DLM profile.
-
Anyway what's the point? We already know my HH5A firmware doesn't support G.INP. :doh:
You asked for a way to find out and I told you.
Does your latency massively increase when using the HH5A?
-
Yeah but I can't find out. Anyone else could though.
Ping up, sync down. I'm on a Huawei cab so a bit O/T in this thread.
-
Just to say for Me I'm using the ECI OR Modem and i for sure had G.INP enabled on the downstream confirmed by Plusnet this caused a increase in latency from 13-15ms to 22-25ms and my Download speed dropped from 46Mb to 42Mb I had no issue getting a PPP session, Two days later everything went back to normal I believe G.INP has been removed i did ask clarification from Plusnet but they haven't responded and seem reluctant to do so.
I have no means to check whether i'm on 204 or 206 nor what firmware the ECI is using so it's hard to see and know what is is going on.
the issue at least for me wasn't PPP related but looked very much like the issue that G.INP MK1 had, so I hope they are looking into that aspect as well and not just a PPP issue .
-
Earlier I logged a fault for my line, it took a lot of effort and firmness to get sky support to accept it.
But the fault is logged as broken g.inp. I am just one guy , and it probably wont do anything, but I call on all us non g.inp's to register faults with our isp's to make the numbers grow as much as possible.
-
I'm not too sure if it is a good idea logging a fault. What good is it going to achieve?
If they have pulled G.INP on some cabinets, then they already are aware there is a problem and not sure now it can make it get resolved any quicker if they are already trying to resolve it.
Is it causing a detrimental effect to your line, whilst they try find out what the problem is. They had to halt it because people were experiencing problems with their line and couldn't even get internet access. They are working on a fix.
Conversely they could think "We never made any public announcement that we are rolling it out" nor that it has been suspended. Think about it - practically all info points back here to this forum. The result is likely to be BT are just more closed lipped in future and certain people wont pass on info.
Thanks :(
Ive also just seen what the reaction to the 3dB trial is too.. I was about to give a little bit more info on that but to be honest people are likely to moan about that too and then that is going to point the finger directly at one of my sources.
Seriously I really bust a gut to find out info and each and every god-damn single time someone moans about it. :( It's not worth it and Im not going to put someone job on the line. All that will happen is info will cease. Ive already had one source dry up because people reacted negatively to some info I put out. Its not about being protective to BT, its about Im sick and tired of trying to find out more info for the community and then me getting the backlash. I do my god-damn best to get info out there to you guys and believe me its not an easy task sometimes.
If it was negatively impacting your line then I'd be behind you all the way... but its not. Its far more important that they find a fix first for those lines which are having problems.
It should not take a genius to work out that I'm becoming sick of it and wonder why I bother. :(
-
Earlier I logged a fault for my line, it took a lot of effort and firmness to get sky support to accept it.
But the fault is logged as broken g.inp. I am just one guy , and it probably wont do anything, but I call on all us non g.inp's to register faults with our isp's to make the numbers grow as much as possible.
If you've never had G.INP activated i'm pretty sure it isn't a fault, that's like me claiming Vectoring is broken because i'm not on one of the very few cabinets that have it activated.
It's just a matter of patience if you truly need faster speeds do what I've done and put your money where your mouth is. In my case I require >100mbps for my needs therefore I have a 2nd FTTC line on order due to be activated on Tuesday.
-
It should not take a genius to work out that I'm becoming sick of it and wonder why I bother. :(
I certainly appreciate your work and I am sure the majority of other users do also. It can just be infuriating at times on why BT do what they do.
Take ECI Ginp BT may have worked relentlessly for over 12m to get this to work as it is but unless they are a bit more open it just looks like they have cobbled something half baked together at the last minute and then still not got it right.
-
its just to add to the data.
From an ISP perspective they probably requested openreach to do the halt based on support calls logged, so I thought I would add one in the other direction.
Yes one single fault wont do jack, but I did it anyway.
--edit--
Just read your entire post.
Kitz there is no moaning at you, the issue is with how they managed to bodge up two rollouts.
My previous comment has been edited out as it came across in an offensive manner.
-
But the fault is logged as broken g.inp. I am just one guy , and it probably wont do anything, but I call on all us non g.inp's to register faults with our isp's to make the numbers grow as much as possible.
If I can't have it then I am going to make sure no one else can. Is that what your saying ?
-
No.
I got no issue with others who still have it enabled, and they should keep it enabled.
Its more so to put pressure for a quicker fix, as I am concerned this will be left alone for several months with only a small amount of end users been affected.
Newt, I believe you was supportive of this predicament, have you done a U turn? As you yourself was impacted by the hauwei delay last year. but back then openreach had bad PR from it and it affected a lot more users.
I think its wrong to tell someone affected "tough luck its not part of your service spec, live with it".
-
The change from the G.INP MK1 to MK2 took just under 3 months to be resolved before it was rolled out again and I was one of those people that had to wait for the fix, did I call my ISP or ask others to rally up with the same issue NO
-
Why is the NO bolded?
-
Why is the NO bolded?
To make sure you noticed it, let say Vectoring comes are way next year and I have issues with it would you like me to call my ISP and complain and the result could cause others on that same cabinet to lose Vectoring and it was working well for them the answer is no i'll wait until its fix for all.
-
I took it as you was shouting NO at me, and quite rude.
I already said to you I dont expect and want others to have it disabled, yet you still think that.
The difference between now and last year, is there is last year there was a lot of fuss made about it and as such openreach were compelled to act, now its just a very small part of the userbase and not a single media site has picked up on a story, you cannot compare the two situations. Also last year they had stated they identified the cause and was working on a fix, so you knew it was coming.
If you had issues with vectoring, yes you should call your isp, why? because they the only people you can call, you have no direct relationship with openreach.
-
I think G.INP has been enabled on my line. I am defiantly on an ECI cab.
> adsl info --vendor
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 5502075242
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 27192 Kbps, Downstream rate = 94915 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 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): 9.6 9.6
Attn(dB): 15.5 0.0
Pwr(dBm): 13.6 4.9
VDSL2 framing
Bearer 0
MSGc: -6 150
B: 178 236
M: 1 1
T: 0 5
R: 6 16
S: 0.0712 0.3771
L: 20780 5410
D: 1 1
I: 185 255
N: 185 255
Q: 16 0
V: 2 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 77146
OHFErr: 277 213
RS: 3202382816 2193489
RSCorr: 90816 3823
RSUnCorr: 0 0
Bearer 1
OHF: 41801027 0
OHFErr: 0 0
RS: 501611580 0
RSCorr: 134 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 28653 0
rtx_c: 34587 0
rtx_uc: 785 0
G.INP Counters
LEFTRS: 5 0
minEFTR: 79982 0
errFreeBits: 2762619456 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 215463798 0
Data Cells: 915143465 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: 40 361
SES: 11 12
UAS: 45 45
AS: 671545
Bearer 0
INP: 46.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 6.15
OR: 0.01 202.87
AgR: 80111.28 20203.27
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 152138/152138 0/0
Total time = 14 days 4 hours 28 min 59 sec
FEC: 152213 16945
CRC: 444 427
ES: 40 361
SES: 11 12
UAS: 45 45
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 13 min 59 sec
FEC: 14 1
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 26 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 28 min 59 sec
FEC: 274 55
CRC: 0 5
ES: 0 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1340 347
CRC: 0 24
ES: 0 23
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 7 days 18 hours 32 min 41 sec
FEC: 90816 3823
CRC: 277 213
ES: 19 168
SES: 8 5
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
ChipSet Vendor Id: IFTN:0xb204
Yes, an ECI equipped cabinet.
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Yes, G.Inp has been enabled for your circuit. :)
-
A question or two before I try out some old devices on an ECI DSLAM. What is the expected or known consequence of attaching a non g.inp device? A sync failure with no DLM action or DLM action back to fast path or interleaved. If there is a DLM action is a quick recovery likely when a g.inp device is put back?
From what I can read I think just a simple resync failure with no DLM action is expected? I am intending to try an HG622, an HG630 and a HG658 the later two are vector ready so I expect g.inp as well. I am not sure about the HG622.
-
I seem to have both G.INP and FastPath (Interleave Depth = 1) enabled. Or am I reading this wrong?
Stats recorded 19 Apr 2016 09:28:27
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 4 days 23 hours 41 min 37 sec
Resyncs: 0 (since 15 Apr 2016 08:47:47)
Downstream Upstream
Line attenuation (dB): 17.2 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 58844 16218
SNR margin (dB): 6.1 6.0
Power (dBm): 13.2 6.9
Interleave depth: 1 1
INP: 50.00 0
G.INP: Enabled Not enabled
RSCorr/RS (%): 0.0483 0.1782
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 2.89
-
http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html (http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html)
An Openreach Spokesperson told ISPreview.co.uk:
“Openreach constantly monitors its fibre network and this identified some lines which would perform better without retransmission.
We’ve returned these lines to a pre-retransmission state, so that customers continue to receive the optimum speed. All other lines on the platform remain enabled with retransmission.
We’re investigating options to apply retransmission for all customers, and we’re working closely with equipment vendors. Openreach has communicated this position to all fibre CPs and we continue to provide regular updates to them.”
-
Is G.INP needed when G.fast comes in or are they seperate technologies?
I'm unsure of the answer so thought I'd ask you guys.
Because if they are seperate technologies then if they prioritise ECI cabinets for G.fast then its not long to wait (I'm on an ECI cabinet).
If G.INP needs to be used for G.fast then I think its time BT/OR started to make some noise either at ECI or its time to bring in another cabinet maker. It seems ECI cabinets and modems/routers have been a big stumbling block for the past few years in anything that OR tries to do.
-
I have switched the line I am monitoring on DSLWS so I haven't had G.INP disabled, I just haven't had it enabled on this line yet.
-
Is G.INP needed when G.fast comes in or are they seperate technologies?
I'm unsure of the answer so thought I'd ask you guys.
Because if they are seperate technologies then if they prioritise ECI cabinets for G.fast then its not long to wait (I'm on an ECI cabinet).
If G.INP needs to be used for G.fast then I think its time BT/OR started to make some noise either at ECI or its time to bring in another cabinet maker. It seems ECI cabinets and modems/routers have been a big stumbling block for the past few years in anything that OR tries to do.
I would also like to know the answer to this question
-
They are separate technologies, new equipment will need installing for G.fast, I don't think the FTTC cabinet vendor will particularly matter.
-
http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html (http://www.ispreview.co.uk/index.php/2016/04/bt-briefly-start-stop-g-inp-roll-eci-fibre-broadband-cabinets.html)
An Openreach Spokesperson told ISPreview.co.uk:
“Openreach constantly monitors its fibre network and this identified some lines which would perform better without retransmission.
We’ve returned these lines to a pre-retransmission state, so that customers continue to receive the optimum speed. All other lines on the platform remain enabled with retransmission.
We’re investigating options to apply retransmission for all customers, and we’re working closely with equipment vendors. Openreach has communicated this position to all fibre CPs and we continue to provide regular updates to them.”
that was fast :) I asked them last week to look into it for us :)
The problem is it doesnt answer the question about my line, because my line was never in retransmission mode at all. Openreach seem to think they have only reverted lines that got g.inp enabled and had problems.
-
But it's also been said on here that they've disabled it for lines that they suspect will be affected, and I guess you're one of them, just be patient ;)
-
yeah, so the kitz statement I believe to be the one nearer the truth.
I am starting to suspect tho because my line is on a overide profile (sky use standard), and I have it on speed, maybe this overide has stopped it been changed.
-
Just a thought I did have G.inp on my old pair but after DLM reset yesterday and pair swap will I get G.inp back or will I have to wait till BT start rolling it out again
-
I would normally say yeah, but your reset put you back on fast path which surprised me, I have never seen a g.inp enabled line on fast path before. So there is a chance somehow your line got pulled of g.inp, you will just have to wait and see I guess.
-
Ok. I just wish they would decide what they are going to do, as off later this evening or early doors tomorrow I will be showing Red
-
I would normally say yeah, but your reset put you back on fast path which surprised me, I have never seen a g.inp enabled line on fast path before. So there is a chance somehow your line got pulled of g.inp, you will just have to wait and see I guess.
I went from g.inp to default profile and now fastpath. Date g.inp lost was 8th april.
-
So I found an old unused router in the office which I've reflashed and installed openwrt onto.
Installed it yesterday using my sky username and password with my ECI router and noticed a drop in speed of a couple of meg from my sky sr102. I'm guessing it may not have had the upgraded firmware as I've not used it for a while.
I'll put in my modded HG612 tonight and check my g.inp status. If I do have g.inp I'll probably send my ECI off to get upgraded and flashed and see what difference it makes.
I'll just put my stats here, so I can monitor.
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5426 Kbps, Downstream rate = 21928 Kbps
Bearer: 0, Upstream rate = 5386 Kbps, Downstream rate = 19403 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.1
Attn(dB): 26.6 0.0
Pwr(dBm): 10.3 6.4
VDSL2 framing
Bearer 0
MSGc: 26 33
B: 51 168
M: 1 1
T: 64 5
R: 12 16
S: 0.0852 0.9966
L: 6008 1485
D: 379 1
I: 64 185
N: 64 185
Counters
Bearer 0
OHF: 95334 32189
OHFErr: 29 0
RS: 24359284 2091575
RSCorr: 505577 0
RSUnCorr: 52 0
Bearer 0
HEC: 11 0
OCD: 0 0
LCD: 0 0
Total Cells: 19457370 0
Data Cells: 59 0
Drop Cells: 0
Bit Errors: 0 0
ES: 81 1
SES: 0 0
UAS: 343 343
AS: 523
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 5.47 16.25
OR: 46.75 19.18
AgR: 19450.02 5405.15
Bitswap: 359/359 0/0
xdslcmd info --vendor
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 7035499874
-
I see on kitz's latest FEC burst there was also 5 ES.
-
They are separate technologies, new equipment will need installing for G.fast, I don't think the FTTC cabinet vendor will particularly matter.
Openreach are not trialling any G.fast equipment supplied by ECI. I'm not even sure if ECI have any G.fast equipment to be tested. They are off the table this time around it seems.
-
can hauwei node's work with ECI cabinets?
-
can hauwei node's work with ECI cabinets?
The G.fast nodes aren't connected to the VDSL ones in any way. They co-exist by the G.fast node not using the VDSL spectrum.
-
so there is no need for them to link up to the fibre feed fed to the chipset in the cabinet at all? Completely independent.
I suppose all that would happen then is that if they want to enable G.FAST in ECI area's then just deploy hauwei equipment in those areas.
-
so there is no need for them to link up to the fibre feed fed to the chipset in the cabinet at all? Completely independent.
I suppose all that would happen then is that if they want to enable G.FAST in ECI area's then just deploy hauwei equipment in those areas.
I'd assume that when BT installed the cabinets they installed more fibre than was needed, so all they need to do is hook it up.
Also correct me if I'm wrong but didn't they use Skipio hardware in the trail?
-
Completely independent.
The three vendors they have run / are running trials with are Huawei, Alcatel-Lucent and ADTRAN.
-
The fibre is blown on demand, there's not an abundance already delivered to cabinets, and some cabinets have WDM kit in them to reduce fibre count from aggregation nodes so in at least some areas there isn't an abundance available from the aggregation node either.
Sckipio are a chipset manufacturer. They supply reference designs for CPE and chipsets for some of the G.fast nodes Openreach have tested. The actual nodes, at least one of which includes Sckipio's chipset, are produced by the three I mentioned below.
-
Never heard of ADTRAN but the other 2 vendors are good news.
-
This has probably been said answered somewhere but I don't think I've seen it.
So why can't the BT Home Hub 5 Type A fully support G.INP? We know lantiq can support it and its not a lack of resources like with the ECI modems and even then theres ECI modems on eBay which support it so why cant BT make it work when other companys/people can?
-
I don't believe there's any lack of resources on the ECI modems. I believe the memory used for ReTx is the same memory that would otherwise be used for interleaving, and it's possible that this relatively small amount of memory is integrated within the main VRX268 chip rather than allocated from main system memory.
It's also been assumed that because the ECI modems and the HH5A apparently haven't been given a suitable firmware update, then there must be some technical reason why this isn't possible, rather than that no-one wants to do it because it would cost too much. The lack of detailed stats from the HH5A and ECI modems with their OEM firmware make it difficult to determine if ReTx is enabled in either direction, but hopefully the OpenWRT builds for the HH5A and ECI modems demonstrate the hardware is capable of doing it.
I think the reason a suitable firmware doesn't seem to have been done is not known.
-
Never heard of ADTRAN but the other 2 vendors are good news.
Interesting. They do a lot of different kit (http://portal.adtran.com/web/url/products).
Data sheet for G.fast products. (http://portal.adtran.com/pub/Library/Data_Sheets/International_/I611321707Fx-8_UBB%20500600G%20Series.pdf) There are 48 port indoor and outdoor variants of the G.fast CPE.
16 port G.fast FTTdp node. (http://portal.adtran.com/pub/Library/Data_Sheets/International_/I611321712F1-8%20516G%20Gfast%20Outdoor%20ONU.pdf)
-
Is there any hope left for another attempt of GINP for ECI cabinets? Mr Sheep are you happy to share some cryptic clues?
-
Yes there is, but not this year by the looks of it, see post linked to below
http://forum.kitz.co.uk/index.php/topic,18124.msg328484.html#msg328484