Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Interceptor121]

It looks like my line on a Huawei cabinet has both GINP and retransmission applied. As a result my IP Profile is set at 38.67 despite a max rate of 43400 best case
Those are the stats. The value of INP is 45 but looks like GINP is active anyway and the line is also interleaved though latency is pretty good
Is this normal?

# xdslcmd info --show 
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 7790 Kbps, Downstream rate = 43304 Kbps
Bearer:   0, Upstream rate = 7790 Kbps, Downstream rate = 40000 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):    7.8       6.0
Attn(dB):    21.1       0.0
Pwr(dBm):    12.3       4.6
         VDSL2 framing
         Bearer 0
MSGc:      -6      26
B:      138      237
M:      1      1
T:      0      34
R:      8      16
S:      0.1101      0.9699
L:      10684      2095
D:      16      1
I:      147      127
N:      147      254
Q:      16      0
V:      12      0
RxQueue:      27      0
TxQueue:      9      0
G.INP Framing:      18      0
G.INP lookback:      9      0
RRC bits:      0      24
         Bearer 1
MSGc:      90      -6
B:      0      0
M:      2      0
T:      2      0
R:      16      0
S:      10.6667      0.0000
L:      24      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      121084
OHFErr:      0      4
RS:      643396320      290542
RSCorr:      44115      1756
RSUnCorr:   0      0
         Bearer 1
OHF:      1106614      0
OHFErr:      0      0
RS:      6639315      0
RSCorr:      0      0
RSUnCorr:   0      0

         Retransmit Counters
rtx_tx:      117186081      0
rtx_c:      122      0
rtx_uc:      0      0

         G.INP Counters
LEFTRS:      1      0
minEFTR:   40006      0
errFreeBits:   10842687      0

         Bearer 0
HEC:      0      0
OCD:      0      0
LCD:      0      0
Total Cells:   1367255223      0
Data Cells:   15522514      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      4
SES:      0      0
UAS:      24      24
AS:      17776

         Bearer 0
INP:      45.00      0.00
INPRein:   0.00      0.00
delay:      0      0
PER:      0.00      8.27
OR:      0.01      30.93
AgR:      40252.99   7821.57

         Bearer 1
INP:      2.50      0.00
INPRein:   2.50      0.00
delay:      0      0
PER:      16.06      0.01
OR:      47.81      0.01
AgR:      47.81   0.01

Bitswap:   13565/13565      188/188

[gt94sss2]

Your IP profile is set at 38.67 as your downstream sync rate of 40000 Kbps.

What product/ISP are you with?

[Interceptor121]

Your IP profile is set at 38.67 as your downstream sync rate of 40000 Kbps.

What product/ISP are you with?

Yes I know that, BT infinity 1 52 mbps. However I think this has to do with overhead of RS error connection and not just GINP on a banded profile

[roseway]

It looks very much to me as though you're still on a 40 Mbps package, or banded at that rate. There's some spare downstream SNRM which should give you a rather higher connection speed.

[Interceptor121]

That what it seems but RS error correction does have a payload of 0.1101 if you look at this it gives exactly 38.67 from 43.5
I do not mind banding too much but RS and interleaving at the same time of GINP seems excessive

[roseway]

The IP Profile is calculated as a percentage of the connection speed. Other parameters don't come into it. From memory the percentage is ~96.7% on FTTC, and this matches your result.

It's quite normal to have RS error correction at the same time as G.INP.

[Interceptor121]

I thought there is a payload because of the bytes used for redundancies in the frame and only if error correction is off you get the full benefit of GINP

[ejs]

The capacity used to carry the RS FEC data is not included in the "sync speed" reported by the modem. The "sync speed" is technically the actual net data rate, it's "net" in the sense that all the various overheads have already been subtracted and the net data rate is the bandwidth available to carry your data (PTM codewords in the case of most VDSL2 deployments).

Therefore, there is no need to subtract some percentage from the net data rate to account for any framing overheads, they've already been taken account of.

Also, the RS coding will not necessarily cause an overall reduction in bandwidth. The modem will take into account the coding gain from the RS coding, which can result in more bandwidth even after the overheads have been taken into account.

[Interceptor121]

The sync speed is net but the profile is not and also the bt modem reports attainable of 40000 instead huawei reports 43400?

[roseway]

I'll say it again: The IP profile is a fixed percentage of the connection speed.

The attainable speed is just a judgement by the modem, and it's quite possible that different modems will use different algorithms for making that judgement.

[ejs]

The IP Profile is to allow for some of the higher level overheads (higher than the VDSL2 layer). With ADSL, the IP Profile was mostly to allow for the ATM layer overheads (5 octet header and up to 48 octets of data per ATM cell). With VDSL2 using PTM, the IP Profile is a much higher percentage of the net data rate than it was on ADSL.

Considering it's such a round figure of 40,000, and the SNRM being above 6, it very much looks like it's capped at 40Mb.

Is there any particular problem? The stats look completely normal for a line with G.INP in use.

[Interceptor121]

Well it has been like this for a very long time and without retrains or significant Errored Seconds I am still interleaved with error correction
Also the drop from 43400 to 40000 is pretty much 8% which is a typical RS overhead
I would like the line to be less interleaved as a starter with lower pings

[William Grimsley]

Only DLM will make that decision for you.

[ejs]

The max attainable net data rate also does not include any RS overhead.

The level of interleaving that is used with G.INP is negligible, and as shown in the stats, the delay is practically zero. Interleaving depth of 16 compared to the maximum interleaving depth of 3072 for VDSL2 profile 17a. FTTC lines really using interleaving tend to have interleaving depths of a few hundred to a little over one thousand.

Lines using G.INP tend to have very few Errored Seconds because G.INP is very effective at correcting errors.

[Interceptor121]

The max attainable net data rate also does not include any RS overhead.

That is pretty much what I am saying. My line is capable of 43500 however RS correction is applied therefore a payload of 8% applies bringing sync speed to 40000 (a bit what happened with DSL 7616 vs 8192)

The modem syncs at 40000 and G.INP takes the IP profile to 38.67

In summary I do not think my line is capped at 40, I think the line has RS error correction and this takes it to 40 mbps. G.INP will always be activated on the cabinet

What I struggle to understand is what errors is RS correction fixing that G.INP can't? When I was running stats rx counts are very high and GINP retrains very low as if the line is choosing to use RS correction by default