But I can comment on the text of rp00's line statistics...
I was looking at these last night and started scratching my head as I noticed some of the bearer 0 and bearer 1 figures were possibly mixed up and I too got an RS OH of 50% which I thought could not be right. I'd got a headache so went to bed and left it. Glad that you find them strange too.
- INP=44 is a new value, lower than I've seen before, I think.
We dont have anyone else on 44 on the ECIs. However, for some reason that figure rings a bell.
Was that the default figure that they put on the Hueweis if the modem couldnt fully support G.INP and which gave a ridiculous overhead and why people lost so much sync speed? I'm pretty certain Ive seen 44 before when g.inp mk1 went tits up.
ETA - I just noticed that some others have since commented on this value.
The R and N values (labeled RFEC and NFEC here?) seem to be 16 and 32. At 50% overhead, this seems huge ... but they match the settings on my Billion 8800NL for bearer 1. Is this a translation issue with OpenWrt?
Yep. same conclusion that the
downstream R & N values are reporting from Bearer 1.
The downstream values match my bearer 1 figures, the upstream match my own bearer 0 figures.
Likewise the interleaving depth and block size are 1x32, which are the right scale to be bearer 1 too. On my Billion, I get 3x32 on bearer 1, so perhaps ECI cabs don't do interleaving on bearer 1 either.
Whilst my bearer 1 block size is 32, I like you have a depth of 3, indicating that the ECI cabs are capable of interleaving on bearer 1. So this is either a reporting issue or ECI modems behaving differently.
I'll zip and attach my plink stats for both pre g.inp and post g.inp so you can see everything.
- The interleaving delay is reported to be 0.22ms, which matches my calculations for my Broadcom modem on a Huawei cab. I wonder how the interleaving delay can be anything when depth is 1?
Its looking more likely that its possibly the firmware pulling some figures from bearer 0 and some from bearer 1.
If Bearer0 =1 (which is what it should be) 1 and
if Bearer1 is 3 and not the reported 1, then it would all tie up.
I put rp00's stats in the table as best I could. The attainable figures aren't quite accurate but interpreted as best I could from the graph. Note the massive jump on the sync speed, but not so big on the attainable - it looks like that the additional sync speed was always there, just possibly eaten up by RS overhead.
