Announcements > News Articles
Openreach UK Trial Finally Brings G.INP to ECI FTTC Broadband
skyeci:
yes it has come from the correct person who is in touch with the team working on eci g.inp etc.
Sounds like next year to me sadly if at all??
kitz:
--- Quote ---with ECI and their partners to fix a bit loading algorithm problem in one of the chip sets which was causing anomalies on a subset of lines on the trial
--- End quote ---
First thoughts "ECI and partners" = Lantiq ?
"one of the chip sets" - Don't the M41's all contain the same chipset, therefore do they mean a particular type of modem.
"bit loading algorithm" - isn't it the modem which is responsible for bit loading
"causing anomalies on a subset of lines" - are we now back to the known issue whereby certain modems can cause problems for neighbouring lines when used with g.inp.
Putting 2+2 together to make 5
ECI has not been able to come up with a solution to protect neighbouring lines if a rogue modem in use.
I haven't yet figured out why rogue modems would affect neighbouring g.inp lines, other than know if certain settings are changed on the rogue modem, that it will most likely increase noise for those neighbouring lines..... and that g.inp works far better on certain types of noise than others.
T-REC G.998.4 does slightly cover bitloading but some of it applies to in use with SRA. I've only had a quick scan and don't really feel like breaking it all down.... I doubt if me spending a long time reading that document would enable us to come up with a theory that the experts will not have already covered.
@ ejs - what do you reckon on that statement?
Thanks for the update skyeci - appreciated. TBH it's not looking too good is it. They've had 3 years now since g.inp was first rolled out and we are still no further forward :(
[Moderator edited to fix a problem with a pair of nested bbc tags.]
skyeci:
well 2 years come april 16th for my line since its removal after the initial 2 week period.
I wonder if that chap on here and mdws still has it on his line, trying to remember his name. got it "EvilShubunkin"
ejs:
I think all we know for definite about the M41 line cards is that the line cards are either "v2" or "v3", but we don't really know anything about the chipsets in the line cards, beyond the IFTN and the 4 hexadecimal digits we see in the stats. It could be the same or very similar chip set in both the v2 and v3 line cards.
I think it's probably going to be the receiving end that is responsible for initiating a bit swap, so for the downstream, that would be the end user modem. The bit swapping must be coordinated between both ends, a problem might be the modem requesting bit swaps and the other end refusing them. The word "algorithm" doesn't really tell us anything, and a bit swapping problem could be a problem at either end.
"causing anomalies on a subset of lines on the trial" - I read that as the subset of lines using that particular chip set in question. Not as one line causing problems for others.
I would not be at all surprised if the problem were Lantiq modem firmware related yet again, and if they're still trying to debug some ancient firmware version numerous iterations behind the latest.
kitz:
afaik Openreach use VTU-C64 line cards in their ECI cabs which supposedly contain Infineon VINAX V3 chipsets.
I believe ECI also retailed VTU-C48 line cards at one point but not sure if these were ever used with VDSL2 DSLAMs.
>> I would not be at all surprised if the problem were Lantiq modem firmware related yet again,
To me, from everything they say appears to be pointing to something at the modem end... but how come TP-Link could fix this on their modems which contained the same chipset as the ECI modems. Also during the [ECI] roll-out it was users of other makes of modem which were reporting problems retaining sync.
One thing we do know is that Openreach are remaining tight lipped on the fact they have discovered there is an issue with some modems and g.inp.. but arent saying anything when it comes to disclosing the actual modem/chip type of that modem(s).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version