It shouldn't be. I'm tenbyboy2 on there mind

Jumps in sync speed of that size are reasonably consistent with interleaving being turned off.

Exactly my thoughts. But there is, by definition, no way a sync speed changes without a re-sync. It just isn't showing up on the BQM.

The weird thing though is everything is consistent with G.INP being activated, bar one thing. That gives the speed jump and defaults to 8/1 interleaving, with a delay of zero. But the latency on the BQM hasn't dropped.

See my stats with G.INP:_

xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16014 Kbps, Downstream rate = 59808 Kbps
Bearer: 0, Upstream rate = 15142 Kbps, Downstream rate = 59997 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): 5.9 6.4
Attn(dB): 19.7 0.0
Pwr(dBm): 13.6 7.4
VDSL2 framing
Bearer 0
MSGc: -6 25
B: 243 237
M: 1 1
T: 0 64
R: 10 16
S: 0.1295 0.5000
L: 15691 4064
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 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 225232
OHFErr: 12 317
RS: 3250970184 456228
RSCorr: 4842544 3229
RSUnCorr: 0 0
Bearer 1
OHF: 136938210 0
OHFErr: 0 0
RS: 1095505182 0
RSCorr: 197 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 123773 0
rtx_c: 177656 0
rtx_uc: 98114 0

G.INP Counters
LEFTRS: 2354 0
minEFTR: 59977 0
errFreeBits: 2638760568 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 378196123 0
Data Cells: 334037878 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: 117 797
SES: 38 1
UAS: 333 311
AS: 2199619

Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.03
OR: 0.01 30.87
AgR: 60058.37 15172.73

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: 1678472/1678472 10339/10356

#

Following a resync (not my doing this time!!) the sync has dropped to 68932Kbps. New stats for your perusal:

Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.2 6.1
Attenuation (dB) 19.1 0.0
Output Power (dBm) 12.7 7.5
Attainable Rate (Kbps) 68920 18228
Rate (Kbps) 68394 18228
B (# of bytes in Mux Data Frame) 243 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 64
R (# of redundancy bytes in the RS codeword) 10 14
S (# of data symbols over which the RS code word spans) 0.1136 0.4190
L (# of bits transmitted in each data symbol) 17887 4850
D (interleaver depth) 8 1
I (interleaver block size in bytes) 254 127
N (RS codeword size) 254 254
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 0 1
RS Words 278133840 2705868
RS Correctable Errors 3111142 10
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 1035040377 0
Data Cells 11069860 0
Bit Errors 0 0
Total ES 0 1
Total SES 0 0
Total UAS 28 28

Really weird .

Yes it is. There's been nobody in the house and the boiler is off now so not a clue what's going on. Seems steadily sync'd at 69947Kbps now.

I'd say 69mbps is pretty good given the attenuation. I

In reply to a post by WelshWArrior:

Yes it is. There's been nobody in the house and the boiler is off now so not a clue what's going on. Seems steadily sync'd at 69947Kbps now.

I have a reasonable explanation. Give me a mo to type it out...

Right, found you on MDWS now - earlier I was looking for speeds of 78M, and there wasn't much choice, so perhaps you'd already dropped back by them

Anyway...

Looking at MDWS for the past 5 days, I can see this kind of event has been seen twice. But let's concentrate on this morning (right now, I'm using the "last 8 hours" graph).

First, by looking at the "SNRM" graph, we see a big rise at 10:04. This stayed in place until 10:50. There are no stats until 11:05, when SNRM has dropped to normal.

Then, looking at the sync speed, we see that it stayed the same until 10:50. No stats until 11:05, when the speed has dropped.

This suggests one of your crosstalking neighbours turned their modem off at 10:04. Your SNRM jumped by 3dB, which would be worth around 10Mbps in speed. A resync happened between 10:50 and 11:05 ... and, hey presto, a sync speed that is 11Mbps higher - alongside an SNRM that matches the standard 6dB target.

As evidence of a resync, check the "uptime" graph, we can see that dropped to zero over the 10:50 - 11:05 timeframe. No idea what causes the resync though - it obviously wasn't immediately triggered by the increase in SNRM back at 10:04.

Eventually, that pesky neighbour turns their modem back on, and re-introduces that crosstalk noise. At 12:23, your modem starts to report an SNRM of only 3dB. It appears to be unsustainable, so an automatic resync occurs (uptime drops to zero again). Speed returns to normal, and SNRM too.

Looking at the "last 3 days" versions of the graph shows the increase in SNRM happened once before. However, whatever caused your subsequent restart on *that* occasion missed the opportunity - SNRM had returned to normal just before the resync would have benefited from it.

G.INP has been active all 5 days, with very little change. I don't think DLM was the cause of anything happening here.

Edit:
Forgot to say this:

a) That the cause of the SNRM change does not look like interference either. There isn't a corresponding peak/trough in the error rates - which we'd see in either the "Errored Seconds" graph of the "G-Retransmit Tx" graph.

b) But there is something funny showing up in the "G-Retransmit Tx" and "G-Retransmit Corr" graphs. Both of these show a lot of activity on a daily basis, from around 11pm through to 3pm or 4pm. No gradual build-up or fade-out either, and a high level of "2,500 per minute". G.INP is retransmitting a lot of data, mostly successfully.

There is also something on the FEC graph, that matches up with the two G.INP graphs.

The pattern shows from the 21st. It isn't present on the 20th ... and I haven't donated anything, so can't see any older data.

*Something* is going on there ... but G.INP is hiding it all from you!

Edited by deleted (Tue 24-Nov-15 17:34:57)

Update:

DLM
@RobertoS pinged me to rethink yesterday's statement, specifically the part about whether DLM had been involved in re-configuring G.INP

I've looked back at the graphs, and my conclusion is that I just can't tell for sure.

Yes, there is a change to the "B0 INP", from 48 to 49. That may indeed have been caused by DLM - which may well have triggered the resync.

On the other hand, I think small changes to this value can happen without necessarily triggering a resync. In the end, I'm just not sure.

Interpreting the graphs
While checking my thinking, I've looked at all the graphs over the 5 day period I have access to. I think the graph that most dramatically highlights the change in the line is the "B0 FEC"; this suggests that something started at 22:41 on the 20th November that has not gone away.

Between approx 1530 and 2200 each day, a low level of FEC exists - presumably caused by a low level of noise. It seems that this interference is enough to cause a constant stream of FECs (corrected errors), but not enough to cause the FEC process to be overloaded.

However, between 2200 and 1530 each day, the interference ramps up. A higher level of FEC's is one result (more errors being corrected), but a high level of G.INP retransmissions occurs (visible on the "G-retransmit TX" graph). For the most part, the retransmissions get through OK (visible on the "G-retransmit Corr" graph).

At times when retransmission occurs, the impact on total throughput is shown by changes in the "Error Free Throughput Rate", EFTR, which is visible as slight drops in the "G-min EFTR" graph. Because the EFTR is reduced, the statistics also mount up in the "G-LEFTRS" graph.

Sometimes, when the interference gets bad enough, for long enough, the retransmission process fails, visible on the "G-retransmit UnCorr" graph. There is something of a pattern to these bursts too - with some happening around 0745-0800.

The same retransmission failures show up in the "B0 CRC errors" graph, and the "Errored Seconds" graph.

It seems that the G-LEFTRS graph is the one that tells us when G.INP retransmission is particularly busy, while the Errored Second graph tells us when G.INP retransmission is being overwhelmed.

Impact on BQM
The large amount of retransmission going on is *bound* to have an impact on latency of some packets, so resulting in jitter.

It seemed to me that this should show on the BQM ... and, lo-and-behold, it does.

Between approx 11pm and 3pm, the yellow "max latency" bar shows a fairly constant 3-4ms. I guess that shows the maximum delay that can be occurred through the retransmission process (and however many retransmits are allowed)

Impact on DLM
For those interested in how DLM works in the presence of G.INP...

Before G.INP was activated, the "Errored Second" values always used to be key at triggering DLM intervention. I suspect they still are, but with a suspicion that the LEFTRS values may also play a part.

But what seems clear, looking at the graphs side-by-side, is that there is very little in either the "Errored Seconds" graph or the "G-LEFTRS" graph that would highlight a reason for DLM intervening at 10:47 on the 24th (changing INP from 48 to 49), and even less reason for de-intervening at 12:21 (reducing INP from 49 to 48 again). Things were going wrong on the days before and afterwards, without any similar intervention.

There is obviously something horrible happening to the line, but I remain unconvinced that DLM has really made any changes in response to this. Broadly, the current G.INP settings are "coping".