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.

As I understand it, bearer 1 is used by G.INP (but can also be used by certain other things like SOS I believe). Retransmitted data units are sent through bearer 1 instead of bearer 0, while all 'good' data units which haven't needed to be retransmitted are sent through bearer 0 still. Obviously it's a bit more complicated than that, but I think that summarises what I've read.

Old line stats below, same modem etc.

I've lost 5mbit down and 1mbit up and my latency has stayed the same, all from this interleaving off change it seems.... :/

adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8577 Kbps, Downstream rate = 49615 Kbps
Bearer: 0, Upstream rate = 8420 Kbps, Downstream rate = 40691 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.4 6.1
Attn(dB): 24.3 0.0
Pwr(dBm): 11.8 4.0

VDSL2 framing
Bearer 0
MSGc: 18 28
B: 51 238
M: 1 1
T: 64 30
R: 12 16
S: 0.0407 0.9027
L: 12592 2260
D: 797 1
I: 64 255
N: 64 255

Counters
Bearer 0
OHF: 131094445 512661
OHFErr: 2450 65
RS: 3495309746 1428775
RSCorr: 19047941 192
RSUnCorr: 141575 0

Bearer 0
HEC: 32123 0
OCD: 12 0
LCD: 12 0
Total Cells: 1029900545 0
Data Cells: 928282293 0
Drop Cells: 0
Bit Errors: 0 0

ES: 538 64
SES: 0 0
UAS: 24 24
AS: 342475

Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.61 13.59
OR: 73.49 20.01
AgR: 40764.76 8439.81

Bitswap: 153473/153478 75/78

Total time = 3 days 23 hours 8 min 31 sec
FEC: 19047941 192
CRC: 2450 65
ES: 538 64
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 8 min 31 sec
FEC: 17693 0
CRC: 11 0
ES: 3 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: 28805 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 8 min 31 sec
FEC: 1895099 43
CRC: 580 13
ES: 144 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2381660 58
CRC: 742 21
ES: 119 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 3 days 23 hours 8 min 5 sec
FEC: 19047941 192
CRC: 2450 65
ES: 538 64
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Usually sync speeds are slightly lower, but throughput speeds are higher as they have less error correction overhead.

Are you sure you aren't confusing "Max" and "Bearer". Max rises when interleaving is introduced, and Bearer falls. When interleaving is removed, "Max" falls and "Bearer" rises.

The sync is the "Bearer" figures.

Thanks, that's just what I was going to say. Having just had interleaving applied after months without it, I know that only too well. I am now down to roughly your d/s sync at only 450m.

(Edit: Thanks for posting the old stats. It makes for an interesting comparison, but I'd add that we should beware ... this is the first G.INP comparison I've been able to make)

That looks like your sync speed has gained near 5Mbps (from 40691 to 45191), which is what I'd expect.

When full FEC+Interleaving was in place (before G.INP), the HG612 would tend to overestimate the "max" rate by a long way. From the old settings, I'd have guessed your line would sync around 44-45Mbps if DLM de-intervened.

In the old settings, you have downstream FEC settings of (R=12, N=64), or 12 bytes out of 64 used for protection, or 19%. This has obviously reduced a lot with the new settings, giving you that extra 5Mbps speed.

In the old settings, DLM allowed a delay of 8ms down, and 0ms up; overall impact on end-end ping times would likely have been 10ms.

In the new settings, DLM has removed the delay from downstream, but put the same amount (8ms) in the upstream; that would explain the your observation that end-end latency has not changed.

In this new upstream configuration, FEC and interleaving have been applied. The interleaving obviously makes use of the 8ms of delay allowed, while FEC uses (R=16, N=95), about 17% of the upstream bandwidth for protection.

The old upstream settings had no interleaving, but FEC was turned on minimally, using 16/255 bytes, or about 6% of your upstream.

The difference in the amount of FEC protection explains why your upstream sync has reduced by around 1Mbps.

Overall, DLM has been quite nice to your downstream settings, but there is little indication why it has decided to be so severe to your upstream.

Edited by deleted (Tue 20-Jan-15 11:54:07)

In reply to a post by Ixel:

Retransmitted data units are sent through bearer 1 instead of bearer 0,

That would make sense. The added protection on bearer 1 should ensure the DTU gets through, so causing no additional latency from further failures.

In my own experiences I've always found upstream to become interleaved (with downstream also being effected) if I re-sync too often. I believe DLM operates downstream and upstream independently, or so that's been the observation I've seen on my connection.

Interesting.

There seems to be very few occasions where both downstream & upstream both require interleaving. It is noticeable that, if this happens, both get a reduced delay setting rather than the standard 8ms. 4ms or 6ms, IIRC, but I could be wrong because it has been rare...

On the other hand, upstream having FEC present without interleaving (and without any obvious instruction from DLM) does seem to be common.