Broadband Related > FTTC and FTTP Issues
Is this right?
banger:
Currently with TTB and reasonably happy on FTTC, seems stable. My sync is 65.9mbps and download tests are 58.84mbps on average. This is 88% of sync speed. Seeing another thread on another forum getting 82% was wondering how my speed fairs. What is the default percentage for FTTC on Huwauei cabs?
Weaver:
Your ‘speed’ in terms of TCP payload speed depends on whether you’re using IPv4 or IPv6 and, if you’re using TCP, whether or not you have TCP timestamps enabled, which is a choice of the operating systems at both ends. In FTTC / VDSL2 the speed also depends on the G.INP setting, efficiency of 96.69% if G.INP is ON and at the normal setting or 91% if G.INP is set to ReTx HIGH (not entirely clear what that is). My spreadsheet tells me that with VDSL2 and G.INP = ON, normal the efficiency of TCP + IPv6 payload should be 92.8% (I think that’s without TCP timestamps, but I need to check the calculations again). TCP+IPv4 will be slightly faster than IPv6 because the IPv4 header is 20 bytes shorter. If you have TCP+IPv6 and G.INP=ReTx HIGH then the TCP payload efficiency should be 87.36%, or 88.57% for IPv4. So it’s possible that you have G.INP ReTx HIGH. If you are getting any retransmissions at all due to CRC errors then you won’t be getting full TCP speed. There could be other reasons why your TCP speed isn’t as high as it could be.
banger:
Hmm thanks for the reply. TTB is IPv4 only at the moment. I cant see ON or HIGH for G.INP on DSL stats only the following.
--- Code: --- Downstream Upstream
General
rtx_tx 143188 0
rtx_c 129777 0
rtx_uc 1 0
LEFTRS 7 0
minEFTR 65952 0
errFreeBits 1222862150 0
Bearer 0
RxQueue 75 0
TxQueue 15 0
G.INP Framing 18 0
G.INP Lookback 15 0
RRC Bits 0 24
Interleave depth 8 1
INP 55.00 0.00
INPRein 1.00 0.00
Delay 0 0
Bearer 1
Interleave depth 3 0
INP 4.50 0.00
INPRein 4.50 0.00
Delay 3 0
--- End code ---
Weaver:
From those stats I would think G.INP is enabled for downstream and not for upstream. I don’t know enough about this because I’ve never been lucky enough to have any experience with VDSL2. So as I suggested earlier IPv4+TCP without timestamps and VDSL2+G.INP ReTx HIGH would nicely fit your 88% downstream experience. We need to ask others about the ReTx HIGH thing and how to tell if it’s in effect. The base efficiency figures for VDSL2 that I’m using came from Kitz I think. G.INP ReTx High is a bad thing, losing some 6%.
However I found this old thread: https://forum.kitz.co.uk/index.php/topic,20307.msg354345.html#msg354345
j0hn:
--- Quote from: banger on May 18, 2022, 02:00:03 AM ---Hmm thanks for the reply. TTB is IPv4 only at the moment. I cant see ON or HIGH for G.INP on DSL stats only the following.
--- Code: --- Downstream Upstream
General
rtx_tx 143188 0
rtx_c 129777 0
rtx_uc 1 0
LEFTRS 7 0
minEFTR 65952 0
errFreeBits 1222862150 0
Bearer 0
RxQueue 75 0
TxQueue 15 0
G.INP Framing 18 0
G.INP Lookback 15 0
RRC Bits 0 24
Interleave depth 8 1
INP 55.00 0.00
INPRein 1.00 0.00
Delay 0 0
Bearer 1
Interleave depth 3 0
INP 4.50 0.00
INPRein 4.50 0.00
Delay 3 0
--- End code ---
--- End quote ---
You're on Retx High so maximum throughput is around 91-92%.
As Weaver said with Retx Low that can increase to up to 96.69% of sync speed.
If you wanted to squeeze that little bit more then capping the line for a few days/a week usually nudges the DLM to Retx Low where it usually stays.
Navigation
[0] Message Index
[#] Next page
Go to full version