Interleaving off but latency unchanged?

So finally interleaving is off my line but my latency hasn't changed at all! Speeds are slightly lower as expected but that's all... Strange?

Any sign that g.inp is turned on?

Surely speeds should be higher, not lower.

Have you got the stats please?

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7456 Kbps, Downstream rate = 46615 Kbps
Bearer: 0, Upstream rate = 7365 Kbps, Downstream rate = 45191 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): 6.7 6.2
Attn(dB): 24.3 0.0
Pwr(dBm): 11.9 3.9

VDSL2 framing
Bearer 0
MSGc: -6 30
B: 227 78
M: 1 1
T: 0 14
R: 6 16
S: 0.1605 0.3410
L: 11666 2229
D: 1 94
I: 234 95
N: 234 95
Q: 4 0
V: 0 0
RxQueue: 78 0
TxQueue: 26 0
G.INP Framing: 18 0
G.INP lookback: 26 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 400209
OHFErr: 0 0
RS: 142253116 2807376
RSCorr: 12053 26
RSUnCorr: 0 0
Bearer 1
OHF: 356731 0
OHFErr: 0 0
RS: 2853354 0
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 3639 0
rtx_c: 3393 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 45198 0
errFreeBits: 3947727 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 497921784 0
Data Cells: 20956255 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 0
SES: 0 0
UAS: 25 25
AS: 5731

Bearer 0
INP: 49.00 2.50
INPRein: 0.00 0.00
delay: 0 8
PER: 0.00 14.37
OR: 0.01 20.03
AgR: 45290.57 7385.50

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: 4040/4041 0/0

Total time = 1 hours 35 min 56 sec
FEC: 12053 26
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 5 min 56 sec
FEC: 128 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: 1461 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 35 min 56 sec
FEC: 12053 26
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 25 25
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 35 min 31 sec
FEC: 12053 26
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>

Interesting. Both Bearer 0 and Bearer 1 active.

Bearer 0 appears to have upstream interleaving and an 8ms latency delay. Downstream is fastpath and G.INP appears to be implemented on it.

So G.INP is similar to interleaving and would be causing this issue? Also no idea why my Billion is now showing two Bearers, was fine before interleaving came off

Oh goody. A whole new style of line stats to work out

Seeing bearer 1 makes me wonder what other features have been turned on alongside G.INP, and what will attempt to use that bearer.

In some places, SRA has been mentioned - which adapts speed to noise in a relatively slow way. Other places have mentioned SOS - which reacts to noise quickly. SOS seems to be related to a "robust overhead channel".

I note that bearer 1 has no speed allocated to it (or it rounds to zero Kbps, anyway), but is heavily FEC protected: the overhead is (R=16/N=32), or 50% - so whatever uses bearer 1 absolutely wants the packet to get through. I wonder if it the means by which SOS communicates?

Anyway, back to specifics for the OP:

I note that bearer 0 downstream might well have interleaving turned off (D=1) but it still has FEC turned on: the overhead is (R=6, N=234), or 3%. That's a lot lower than usually seen with old-style DLM.

When looking at the requirements from DLM, we can see that, for bearer 0 downstream, it has specified an INP of 49, an INPrein of 0, and a delay of 0. That suggests that it wants no interleaving, and is not attempting to fix the REIN-type noise, but is trying to fix SHINE-type noise.

However, as RobertoS notes, bearer 0 upstream still allows a delay of 8ms.

Perhaps this is why there appears to be no change to your end-to-end latency? I guess it depends what your old line stats were.

I think the interleaving matrix is being used for the upstream interleaving.

I'm assuming the Bearer 1 stuff isn't a Billion peculiarity. Do you happen to know?

I'm *still* waiting for BT to fix my routing records with the correct PCP identity, so an FTTC order will complete - which means I can't see what is happening first-hand.

I have a Billion 8800NL that is just dying to get a better workout than plain ADSL2+ though...

I don't think the bearer 1 stuff is a Billion peculiarity. Over on Kitz, someone reported some line changes on his Asus, and that has Bearer 1 being allocated 128Kbps, being shown in the midst of SOS settings.