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.