In reply to a post by RobertoS:

I have very strong suspicion there is now also a 3.5dB setting in the DLM. I have several times had sync's that appeared to be stable at that level even given more than one forced re-sync at appropriate times.

Yeah, that's because of G.INP overheads - 3 dB + 0.5 db for the overheads.

Edited by deleted (Thu 11-Oct-18 16:58:40)

I don't know what in my post you are referring to, but whatever it is, nope! It isn't.

It definitely is, think about it! Why would there be a 3.5 dB target SNRM? What evidence do you have to prove that this may be the case? Has it been officially announced? Nope! A line with G.INP doesn't sync bang on x.0 dB, there's always a few .x for overheads (depending on the interleaver depth and INP level etc.)

Edited by deleted (Thu 11-Oct-18 17:56:31)

Overheads on SNRM, first time I've heard of such a thing. I am afraid you are totally wrong.

Oh my. Ok, think about a line that goes from fastpath to interleaving, say it's capped at 40/10, if it gains interleaving the SNRM goes up, even though the target SNRM stays the same. Now, do you understand what I'm saying? One thing's for sure though, there's no source to say that there's a 3.5 dB target SNRM.

Edited by deleted (Thu 11-Oct-18 19:33:03)

In reply to a post by WilliamGrimsley:

Oh my. Ok, think about a line that goes from fastpath to interleaving, say it's capped at 40/10, if it gains interleaving the SNRM goes up, even though the target SNRM stays the same. Now, do you understand what I'm saying? One thing's for sure though, there's no source to say that there's a 3.5 dB target SNRM.

You are once again talking total garbage. It is nothing whatsoever to do with "overheads".

Plus, in this latest post you are also confusing what happens at sync time with what happens during the time from then until the next re-sync, and making the glaring error of either not knowing or forgetting that a line cannot go from Fast Path to Interleaving without a re-sync. So your example doesn't prove your point to Realalemadrid because it is tripe.

Still holding strong and the fluctuations in SNRM are minor. So I think the previous re-syncs were down to DLM.
Just hope this is what I can expect now and as a result, the line moves to retransmission low.

Paul

Retransmission low seems quite rare. As far as I know I've always been on High and I can only remember seeing one poster on these forums on low out of the large number on G.INP.

The main nuisance value of Retransmission high is that on BT Wholesale backhaul like mine the IP Profile is set lower than normal. (I forget the exact percentage value at the moment, somewhere just above 94% IIRC). The connection speed reported to the AA Radius server is lower than the sync speed , and is the value BT Wholesale have used to set the IP Profile.

What happens on the TalkTalk Business backhaul I don't know. Perhaps they too are told a lower than sync line speed.

In case you don't know the easiest place to check, it is the INPRein line of Bearer 0, that I've emboldened in the next to bottom block below. 1=High, 0 = Low. What the equivalent values mean in the Bearer1 block below that I don't know.

xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 13491 Kbps, Downstream rate = 72727 Kbps
Bearer: 0, Upstream rate = 13506 Kbps, Downstream rate = 71908 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): 3.2 5.9
Attn(dB): 19.7 0.0
Pwr(dBm): 13.7 7.4

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 58
R: 10 16
S: 0.0000 0.5604
L: 18806 3626
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 80 0
TxQueue: 20 0
G.INP Framing: 18 0
G.INP lookback: 20 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 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 10185
OHFErr: 2851 29
RS: 1520037680 489959
RSCorr: 32476602 182
RSUnCorr: 0 0
Bearer 1
OHF: 60575563 0
OHFErr: 33 0
RS: 605755019 0
RSCorr: 294 0
RSUnCorr: 253 0

Retransmit Counters
rtx_tx: 477434474 0
rtx_c: 140727 0
rtx_uc: 113734 0

G.INP Counters
LEFTRS: 207 0
minEFTR: 71895 0
errFreeBits: 1067242453 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1393905431 0
Data Cells: 226743256 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: 130 29
SES: 63 0
UAS: 33 33
AS: 973162

Bearer 0
INP: 50.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 8.15
OR: 0.01 31.38
AgR: 71981.24 13537.48

Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01

Bitswap: 462256/462256 9752/9780

Edited by RobertoS (Fri 12-Oct-18 14:41:12)

In reply to a post by RobertoS:

The main nuisance value of Retransmission high is that on BT Wholesale backhaul like mine the IP Profile is set lower than normal. (I forget the exact percentage value at the moment, somewhere just above 94% IIRC). The connection speed reported to the AA Radius server is lower than the sync speed , and is the value BT Wholesale have used to set the IP Profile.

What happens on the TalkTalk Business backhaul I don't know. Perhaps they too are told a lower than sync line speed.

I think it's the same with TTB backhaul, as my connection rate reported in the AA console is always a few Mb/s lower than what which my CPE is reporting.

I've just swapped over to the ZyXel CPE provided by AA (VMG3925-B10B) and I can't get it to output stats to DSLStats. It connects and samples but I get a message along the lines of: "No data reported from this sample".
I'm by no means an expert with Telnet but if I telnet it, I can't get any results from using variations of 'xdsl' as a command.

Has some of the telnet functionality been locked down in the FW on this device?

I can't be sure with the DS sync but US sync is reporting to be around 400kb/s lower than with the Billion. However, I think this could be due to differences in how the devices report the value as speed tests give similar results. Bufferbloat is quite a lot more pronounced on the US, with the ZyXel though.

Paul

Yes it's locked down - the same as the VMG1312-B10D with latest firmware. There's been quite a bit of discussion about this on the Kitz forums.