Openreach ECI Modem performance

I recently replaced my Billion 8800 NL with the Openreach ECI modem to facilitate fault reporting of a congested line.

The Billion was syncing at 79999/19999 on an IP profile of 77.42Mbps
Minimum latency showing on BQM was around 22ms

The ECI modem is syncing at 72237/19999 on an IP profile of 69.92Mbps
Minimum latency is sitting around 30ms.

In summary, I've lost about 7Mb down speed and latency has increased by 8ms when using the ECI.

I have bought a second hand Huawei HG612 and unlocked it so the plan is to put that on the line at some point but I though I would give the ECI a chance before switching it out.

The ECI modem has been up and synced now for 13 days.

1. Is this as good as the ECI performance is likely to get or should I be more patient and give it a few more days to see if it reaches the same performance as the Billion?

2. If I fit the Billion or Huawei, will that over the course of time reset the IP profile applied?

Edited by deleted (Tue 26-Jan-16 09:40:04)

1. Yes. The problem here is the ECI doesn't support G.INP

2. Yes. As soon as G.INP turns on again, your line will resync at the max. Maybe 2 weeks

1. Did you have upstream G.INP activated with the Billion?

2. Has the ECI been connected long enough to get the most recent firmware update? What firmware is it running?

In the bad old days, the ECI (like the HH5A) couldn't cope with G.INP activation - and the end result was that the sync speed reduced and the latency increased. But there seemed to be a couple of different problems - the use of G.INP upstream, and firmware problems.

Openreach changed DLM to not activate G.INP upstream by default, and the HH5A received new firmware. The ECI, though, is rather harder to figure - but if there is a firmware update, you need to be plugged in for a while to be updated. You'd think 13 days was enough.

Loads more detail at Kitz...
http://forum.kitz.co.uk/index.php/topic,15283.msg284...

Putting the HG612 on should fix things in a very short order.

I'll check back on my logs/screengrabs to see what the G.INP status was on the Billion prior to swapping it for the ECI.

From the link on Kitz, I've had both issues listed with the ECI. The first one 24 hrs after installing it, it hung and wouldnt connect to internet despite the sync light being on. Following a reboot, thats when the latency increased and sync speeds dropped. It hasnt re-synced since and its been up for 13 days now.

I think I will stick the HG612 on, at least then I can see the stats and tell what is going on, the lack of any info from the ECI is frustrating.

Is it even possible to find out what firmware the ECI is running without taking it offline?

In reply to a post by craski:

I've had both issues listed with the ECI. The first one 24 hrs after installing it, it hung and wouldnt connect to internet despite the sync light being on.

This is due to G.INP being enabled which the ECI doesn't support

Following a reboot, thats when the latency increased and sync speeds dropped. It hasnt re-synced since and its been up for 13 days now.

This means that G.INP has gone off - all IMO of course.

I just swapped out the ECI for the Huawei.

Noticed an immediate increase in sync to 77375 down.

Now I can see stats, i can see that for ECI, G.INP was not enabled and interleave depth on downstream is currently 1515 and 1 on upstream.

Is interleave depth of 1515 bad?

Yes quite bad. It doesn't sound like G.INP is on yet.

An interleaving depth that is in the hundreds or thousands tells us DLM has intervened old-style, with relatively aggressive FEC and interleaving without retransmission.

However, you really need to quote more of the line stats to tell just how aggressive; DLM used to set INP=3, delay=8 for "low interleaving" and INP=4, delay=16 for "high interleaving", and other values if upstream intervention has happened too.

I've seen a couple of recent examples that suggest DLM intervention nowadays might come with different settings.

The set of parameters that show the modem's reaction are found in R, D, I and N - not just the depth. They will help work out the FEC overhead too.

Here is the whole lot from DSLstats...

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 33956 Kbps, Downstream rate = 89688 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 77375 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 15.7
Attn(dB): 13.9 0.0
Pwr(dBm): 13.7 3.9
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 51 237
M: 1 1
T: 64 42
R: 12 16
S: 0.0214 0.3781
L: 23944 5374
D: 1515 1
I: 64 127
N: 64 254
Counters
Bearer 0
OHF: 3073787 1064097
OHFErr: 0 0
RS: 786704812 1722649
RSCorr: 2133 0
RSUnCorr: 0 0

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

ES: 0 0
SES: 0 0
UAS: 90 90
AS: 4224

Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.37 3.98
OR: 139.75 64.22
AgR: 77515.20 20063.54

Bitswap: 3054/3054 0/0

Total time = 1 hours 11 min 54 sec
FEC: 2133 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 90 90
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 54 sec
FEC: 186 0
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: 27 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 = 1 hours 11 min 54 sec
FEC: 2133 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 90 90
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 = 1 hours 10 min 23 sec
FEC: 2133 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

Assuming you have the latest unlocked firmware/software, (V100R001C01B030SP08 easily seen if you go in through the GUI), then also assuming G.INP is implemented on your cabinet in a few days it will probably be turned on for your line.

If that happens your sync will go up and you will also get data for Bearer 1.

In reply to a post by WWWombat:

Openreach changed DLM to not activate G.INP upstream by default, and the HH5A received new firmware.

Which didn't fix the G.INP problem as can be seen here:

In reply to a post by BuckleZ:

I think Openreach resolved the G.INP themselves, the firmware was fixes for other things i guess

In reply to a post by WWWombat:

1. Did you have upstream G.INP activated with the Billion?

I've checked back on my screen grabs of the Billion and it does look like G.INP was enabled.
The setting they call "INP (DMT symbol)" was set at 48.
"D (interleaver depth)" on downstream was 16.

So it looks like the ECI definitely caused G.INP to be removed. Now I'd just like to find out how to read the current firmware version on the ECI to see if that was the latest available version.

Why bother? You have the HG612.

There hasn't been a fw update to enable G.INP on ECI modems.

OK.
I thought I had read somewhere that ECI modems didnt initially work well with G.INP but that they got a patch to support downstream only but I must have picked that up incorrectly.

Seems like a great reason for Openreach to completely disable the UI/feedback from these modems so people cant tell what they are doing and directly compare their stats to other (more capable) hardware.

Yes, following your and others advice on a previous thread I made sure I got a model 3B and updated it to the B030SP08 firmware c/w the GUI.

Now happy that I can see whats happening with DSLStats and that I can log into it remotely (as I work remote from my FTTC connection).

There's a lot of conflicting opinions about G.INP on devices that don't have a Broadcom chipset, but no definitive evidence.

I am aware of someone who created some firmware for the ECI modem that supports G.INP but it's not official.

I remain appalled at the decision by ISPs to remove any useful stats, but thank goodness for Asbokid's initial brilliance in hacking the HG612 in the first place, and for Howlingwolf's later work on enabling G.INP on the hacked firmware.

Ta.

That's a standard DLM intervention of "low interleaving" for downstream, with 19% of your bandwidth allocated to FEC protection, and 8ms of interleaving in that one direction.

There are some bit-errors happening on the line, but they've all been caught and corrected by the presence of FEC; none of the errors have been uncorrectable so far ...so there is nothing (currently) causing DLM to stay intervened. If it stays like that, it should de-intervene in due course. I wouldn't expect any intermediate reductions - just a straight removal of FEC and interleaving.

Attainable speed will probably settle around 84Mbps when this happens.

In the meantime, it may be good to monitor the average rate of FEC's per day, so they can be compared with the eventual rate of ES's per day once DLM de-intervenes.

Wow, in less than 24 hours the Huawei has removed all the extra latency the ECI added and throughput is up around 7 to 8Mb too. Its shocking to think Openreach are happy to fit these sub-standard ECI modems on managed installs.

BQM shows a nice drop in latency ...
Huawei BQM magic

In reply to a post by craski:

Its shocking to think Openreach are happy to fit these sub-standard ECI modems on managed installs.

It's also shocking to see the fanbois roaming the forums claiming that ECI modems and HH5As support G.INP when all the available experience says that they don't. Presumably this is done at the behest of BT who refuse to admit they have fouled up.

An excellent result for you.

In reply to a post by craski:

Its shocking to think Openreach are happy to fit these sub-standard ECI modems on managed installs.

The Kelly "engineer" who turned up for my second installation appointment failed to do anything but deliver an ECI modem for the Huawei All In One cabinet on the footpath by the exchange. Probably the first he fished out of his van, or perhaps the only type he had. Either way, pretty shoddy. That it took at least 6 weeks from order to successful installation did not please me either.

I had been expecting this, and had already bought a second hand HG612 and flashed it, connecting it shortly after the real BTOR engineer who arrived for the third and last installation attempt had left. After a month upstream G.INP kicked in.

My attainable rates are impressive. A pity that they cannot be reached.

With upstream G.INP, speed tests, Samknows and real world use all show delightfully high transfer rates, especially as this is the same short EO line that behaved so poorly with ADSL2+ Annex M.

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 4041 4243 4445 46

Max:    Upstream rate = 41657 Kbps, Downstream rate = 134328 Kbps Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 KbpsBearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps Link Power State:       L0Mode:                   VDSL2 Annex B VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode(0x0) Trellis:                U:ON /D:ONLine Status:            No Defect Training Status:        Showtime                Down            Up SNR (dB):        21.4            23.3Attn(dB):        9.3             0.0 Pwr(dBm):        13.9           -8.2                        VDSL2 framing                         Bearer 0MSGc:           -6              26 B:              130             237M:              1               1 T:              0               42R:              8               16 S:              0.0518          0.3781L:              21468           5374 D:              16              1I:              139             127 N:              139             254Q:              16              0 V:              14              0RxQueue:                60              0 TxQueue:                20              0G.INP Framing:          18              0 G.INP lookback:         20              0RRC bits:               0               24                         Bearer 1MSGc:           186             -6 B:              0               0M:              2               0 T:              2               0R:              16              0 S:              5.3333          0.0000L:              48              0 D:              3               0I:              32              0 N:              32              0Q:              0               0 V:              0               0

As I understand HG612 stats those show downstream G.INP, but not upstream. See lower down your output, as here:-

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16289 Kbps, Downstream rate = 59812 Kbps
Bearer: 0, Upstream rate = 15142 Kbps, Downstream rate = 59997 Kb
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): 5.9 6.7
Attn(dB): 19.7 0.0
Pwr(dBm): 13.6 7.4
VDSL2 framing
Bearer 0
MSGc: -6 25
B: 243 237
M: 1 1
T: 0 64
R: 10 16
S: 0.1295 0.5000
L: 15691 4064
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 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 2097145
OHFErr: 47 1108
RS: 1303019440 4294559
RSCorr: 13025391 10531
RSUnCorr: 0 0
Bearer 1
OHF: 480623190 0
OHFErr: 0 0
RS: 3844985027 0
RSCorr: 623 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 324285 0
rtx_c: 344707 0
rtx_uc: 98185 0

G.INP Counters
LEFTRS: 3675 0
minEFTR: 60008 0
errFreeBits: 3394949551 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1657296495 0
Data Cells: 831218580 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: 135 1507
SES: 38 1
UAS: 333 311
AS: 7720179

Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.03
OR: 0.01 30.87
AgR: 60058.37 15172.73

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 5942289/5942289 26126/26170

The Bearer 1 upstream figures are essentially zero.

In reply to a post by BatBoy:

It's also shocking to see the fanbois roaming the forums claiming that ECI modems and HH5As support G.INP when all the available experience says that they don't. Presumably this is done at the behest of BT who refuse to admit they have fouled up.

Long answer? Short answer? Long answer? Short answer?

Oh, go on then. Short answer it is ....

[censored]

I have no idea what you're trying to say - sorry, perhaps?

Bzzzt. Try again.

I guess you have no intention of halting your mis-information campaign

In reply to a post by RobertoS:

As I understand HG612 stats those show downstream G.INP, but not upstream.

Agreed.

Upstream has FEC turned on, using 6% of bandwidth as overhead (16 bytes out of 254). Neither interleaving nor G.INP retransmission are turned on.

In reply to a post by BatBoy:

I guess you have no intention of halting your mis-information campaign

My "campaign" is merely to stop your mis-information from being taken seriously.

Your experience of your HH5A is welcomed into the collective. But your experience isn't any more valid than anyone else's.

When you respond with answers that put your experience in context, I have no problem. When you respond with a context that implies your truth is the only one, then I do have a problem.

Bluntly, there are some people whose trouble-shooting abilities, and logic, I trust more than yours. Failure to understand, and acknowledge, the broader context merely reduces this trust.

If I don't trust your posts, why should I leave some poor suffering newbie to trust it?

I'm waiting for evidence, proof, call it what you will. Is there any? All the experience is that the ECI modem and the HH5A don't support G.INP.

Wrong. "ALL" the experience does not show this. You've been told, in very recent days, of someone whose experience of HH5 modems (both A and B) is the exact opposite to yours. You've ignored this.

I trust his abilities more than I trust yours. But that isn't enough to make me believe his experience is any more proof than yours is proof.

You kindly produced a link earlier, to a post by BuckleZ, where the one useful phrase was "I guess". The rest of the thread was full of people getting equivocal results: for some, the firmware upgrade had a good result. For others it didn't.

None are proof.

Because we can't see enough detail, we don't know why those who have good experiences, have them. Equally we don't know why those who have bad experiences, have those. I suspect there is some other interaction going on with DLM settings, but we can't see that either.

The one incontrovertible fact is this: The Lantiq VRX268 chipset is capable of supporting G.INP downstream. And that a firmware fix was necessary to get this support working.

The chipset has been seen to fail in the same way as the ECI and HH5A, with a bug found in the firmware. The firmware fix has been seen to fix the fault - such that the chipset properly supported downstream G.INP. All seen with the TP-Link W9980

Context?

This chipset is the same one used in the ECI modems and in the HH5A.

That tells me there is the potential for both the ECI and the HH5A to be fixed to support downstream G.INP. And it may have happened already. But we cannot tell - not to a level of "proof".

At this point, I differ between the two models. While both share the same potential, I believe it more likely that the HH5A firmware has actually been updated, and less likely that the ECIs' firmware have been updated. That difference comes from the balance of posts of I have seen.

I remain open on the issue. In the presence of equivocal evidence in both directions, and the permanent potential, I believe others should remain open too.

In reply to a post by WWWombat:

None are proof.

Exactly. There is no proof. Yet you continue to make posts saying the HH5A supports G.INP. - even in this thread where it is completely off-topic.

In reply to a post by BatBoy:

In reply to a post by WWWombat:

None are proof.

Exactly. There is no proof.

Which means your continual insistence that G.INP is NOT supported is not itself supported by ALL the evidence.

Care to quote anything from the rest of the post that demonstrates how hopelessly wrong you are?

In reply to a post by WWWombat:

In reply to a post by BatBoy:

In reply to a post by WWWombat:

None are proof.

Exactly. There is no proof. Yet you continue to make posts saying the HH5A supports G.INP. - even in this thread where it is completely off-topic.

Which means your continual insistence that G.INP is NOT supported is not itself supported by ALL the evidence.

Care to quote anything from the rest of the post that demonstrates how hopelessly wrong you are?

Care to post any proof that the off-topic HH5A supports G.INP?

Sorry. I did mean downstream G.INP.
Must keep brain engaged while typing.