Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: jimmyca69 on October 16, 2020, 07:37:09 PM
-
Evening all,
I have been running DSLstats for the past 24hrs after successfully setting up a VMG8924-B10a as a bridged modem alongside my Sky SR203 router.
Backstory to this is since moving into new house 18 months ago my connection (on Sky Superfast FTTC 80-20 with min speed guarantee of 42mb) went from around 55mb/20mb, steadily down to 44/20 where it has been for last 3-4 months (DLM sync randomly at night would bring a drop and always sync'd at likes of 43999/19999 to show it was banded). I recently attempted to replace the Sky SR203 router with a TP-Link VR2800 - not to fix the line issues but for better Wi-Fi. However after initially sync'ing the same as the sky router, DLM kicked in each of the first 3 nights and dropped it down each night eventually to 34999/19999 which it is now. After this I changed the firmware back a version and it seemed to steady up and remained same for a week with little errors shows in basic router stats.
I tried to get DSLstats working with the TP-Link but failed, TP-Link support was awful and so I decided to return the TP-Link and put the Sky Router back in. As the speed dropped below min guaranteed i was able to do online tests to confirm and the automated system said I need an engineer visit, which is booked for the 28th October.
In the meantime thanks to help on here I identified the best setup was probably to get a dedicated modem and then look at a wireless router. I then realised the SR203 would be ok to use in WANoE mode with a modem so i bought a VMG8924-B10a. I plan to replace the SR203 but only after the engineer visit and hopefully a DLM reset to get me back to better speeds.
So here we are, my stats are below and I am keen to understand if this shows anything that I can raise with the engineer, the banding of the line previously hints at something which would be good to address. So anything that jumps out here would be good to know about.
Thanks
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22875 Kbps, Downstream rate = 62916 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 34999 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): 14.6 7.5
Attn(dB): 17.8 0.0
Pwr(dBm): 12.4 7.4
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 170 237
M: 1 1
T: 0 42
R: 12 16
S: 0.0000 0.3781
L: 9421 5374
D: 16 1
I: 183 127
N: 183 254
Q: 16 0
V: 4 0
RxQueue: 20 0
TxQueue: 10 0
G.INP Framing: 18 0
G.INP lookback: 10 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 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 1251554
OHFErr: 0 64
RS: 2277549152 3586141
RSCorr: 3911 344
RSUnCorr: 0 0
Bearer 1
OHF: 5530147 0
OHFErr: 0 0
RS: 33180514 0
RSCorr: 6 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 479207863 0
rtx_c: 138 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 4 0
minEFTR: 35006 0
errFreeBits: 47391246 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1683658681 0
Data Cells: 547588993 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 53
SES: 0 0
UAS: 34 34
AS: 88854
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 35075.90 20063.54
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 2720/2720 41/41
Total time = 1 days 41 min 28 sec
FEC: 3911 344
CRC: 0 64
ES: 0 53
SES: 0 0
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 28 sec
FEC: 11 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: 93 14
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 = 41 min 28 sec
FEC: 164 14
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 3747 330
CRC: 0 64
ES: 0 53
SES: 0 0
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 40 min 53 sec
FEC: 3911 344
CRC: 0 64
ES: 0 53
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
(https://i.postimg.cc/mkHWPnBP/snr-grpah.png)
(https://i.postimg.cc/3xC7jzpp/dsl-checker.png)
-
The only thing that jumps out is that your line is banded at 35Mbps, that is what needs to be addressed in the first case.
-
I concur that there is nothing obvious jumping out from those stats. Please could you post the Hlog and QLN plots too (you'll need to enable the monitoring of these in the DSLstats configuration).
I note however you are getting some 4000 FEC errors per day, which normally wouldn't be a cause for concern as these are errors which have been corrected, however these errors could be CRCs if the DLM had not applied interleaving to your line which, for this quantity, would result in the DLM taking corrective action. Perhaps someone with a known good VDSL service could post the number of FECs they get per day. On my ADSL2+ service I get around 400 per day.
There are some rumours that the DLM pays attention to the number of FECs on lines that have G.INP enabled (as yours does), so this could explain why the DLM is not relenting.
-
Thanks both
Hopefully these work:
(https://i.postimg.cc/ydR1KbJ8/hlog.png)
(https://i.postimg.cc/sxRVg4S9/qln.png)
Relating to FEC errors i noted this morning a big jump that must have occurred overnight as now at over 30k....
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22929 Kbps, Downstream rate = 61837 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 34999 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): 14.3 7.5
Attn(dB): 17.8 0.0
Pwr(dBm): 12.4 7.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 170 237
M: 1 1
T: 0 42
R: 12 16
S: 0.0000 0.3781
L: 9421 5374
D: 16 1
I: 183 127
N: 183 254
Q: 16 0
V: 4 0
RxQueue: 20 0
TxQueue: 10 0
G.INP Framing: 18 0
G.INP lookback: 10 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 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 455089
OHFErr: 0 94
RS: 3916706592 1422131
RSCorr: 33537 505
RSUnCorr: 0 0
Bearer 1
OHF: 9510163 0
OHFErr: 0 0
RS: 57060607 0
RSCorr: 7 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 479207999 0
rtx_c: 267 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 7 0
minEFTR: 35006 0
errFreeBits: 81498439 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1691472815 0
Data Cells: 1075321048 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 80
SES: 0 0
UAS: 34 34
AS: 152801
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 35075.90 20063.54
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 2720/2720 70/70
Total time = 1 days 18 hours 27 min 15 sec
FEC: 33537 505
CRC: 0 94
ES: 0 80
SES: 0 0
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 15 sec
FEC: 29 2
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: 32 5
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 = 18 hours 27 min 15 sec
FEC: 29790 175
CRC: 0 30
ES: 0 27
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 3747 330
CRC: 0 64
ES: 0 53
SES: 0 0
UAS: 34 34
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 18 hours 26 min 41 sec
FEC: 33537 505
CRC: 0 94
ES: 0 80
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
I'd say your Hlog and QLN look absolutely fine.
Interesting about the bursts of errors though. It might be worth enabling the monitoring of absolutely everything in DSLstats (no real disadvantage to doing this). That will then give you a plot showing the times the FEC bursts occur which you could perhaps start trying to correlate with things like the central heating switching on etc.
Other than that, it will probably just be a matter of seeing what the attending Openreach engineer does. As I said in your other thread, it's likely that the remote tests have identified something amiss so hopefully they will be able to find and repair it.
-
Regarding the Hlog and QLN plots . . . What you have shown is truncated. You will need to adjust the configuration of DSLstats, to allow for the full width of 4096 sub-carriers of a VDSL2 circuit.
-
Thanks both
Show further stats, I changed the hlog and qln for VDSL2, graphs below. I also turned on all the other config settings and have posted up the FEC error to show spikes there overnight. Not sure if other info might show more on these.
Thanks again
(https://i.postimg.cc/CKmRYBz5/hlog.png)
(https://i.postimg.cc/nzrCLFDk/qln.png)
(https://i.postimg.cc/vHr9kmLg/fec.png)
-
Hlog and QLN still look good (thanks for spotting that burakkucat, I'm too used to seeing ADSL2+ ones for me to notice they were truncated) . There seems to just be a general high background of FEC errors for some reason, the spikes don't seem to be too significant. Probably worth seeing if the larger spikes reoccur at similar times each day. Could also try picking up and/or ringing the phone to see if anything changes in the stats.
Other than that, probably just to have wait and see what Openreach say.
-
Hlog and QLN still look good (thanks for spotting that burakkucat, I'm too used to seeing ADSL2+ ones for me to notice they were truncated) . There seems to just be a general high background of FEC errors for some reason, the spikes don't seem to be too significant. Probably worth seeing if the larger spikes reoccur at similar times each day. Could also try picking up and/or ringing the phone to see if anything changes in the stats.
Other than that, probably just to have wait and see what Openreach say.
Thanks again! Yes i'll leave it running and see if anything obvious changes, useful to have the info from it for when the engineer shows up at least. Moving forward it is good to have access to this info after years on the Sky Router.
Thanks again for you help on this and my other thread, much appreciated ;D
-
Hello fellow high FEC experiencer!
I get millions of FECs a day, it's never caused me any issue, I've always just ignored it.
-
That isn't high FEC!
I almost always received 10,000 FEC per min on my VDSL2 line.
For a long time period i received 100,000 FEC per min with zero issues.
Occasionally the DSLAM would go bonkers and FEC would get stuck at 1,000,000+ per min.
If i wasn't monitoring stats i would never have noticed because the line runs perfect even with 1M+ FEC every single minute.
-
Interesting. Do you think perhaps there could be a significant difference between defects which cause FEC errors on an non-interleaved line, and defects that cause FEC errors on an interleaved line that would be CRCs on a non-interleaved line?
If not, then there doesn't seem to be any evidence in the stats for what it was that caused the DLM to apply interleaving and banding to this line. Hopefully following a DLM reset everything will just be fine with no further work needed.
-
I've had 527539 FECs in the last 10 minutes @j0hn, I would call that quite high.
In response to the question above, I thought I had read on here previously that it is possible DLM now looks at FECs. Something for somebody more knowledgable than me to explain, Kitz herself perhaps?
-
I was referring to the graph above, and the mention of millions per my day. Neither is very high.
Half a million in 10 mins is on the higher side but in no way would i call that very high.
I received 100,000+ FEC per minute for months with no negative affect on the line, error rates or throughput.
If i wasn't looking at stats i would never have known
Kitz is (or has previously been) of the opinion FEC isn't involved all at in the DLM.
I'm of the opinion FEC isn't used when taking negative action on a line but that it might be used when taking positive actions.
For example i believe FEC is used when deciding to remove interleaving or Retx High but not when deciding to add them.
FEC are corrected errors and nothing to worry about.
-
Just as a follow up to this, a Sky Engineer attended today. He replaced the external nte and requested a DLM reset on the line. He said the line showed no issues and by replacing the NTE connection it saw some stats improvement also so then requested the DLM reset, he says I should see around 60mb once that takes place.
-
Thanks for the update. Hopefully the DLM will apply G.INP then gradually lower the SNR margin to 3dB, giving you a much faster connection.
-
Thanks for the update. Hopefully the DLM will apply G.INP then gradually lower the SNR margin to 3dB, giving you a much faster connection.
Hopefully, although over 48hrs later and no DLM change yet. Engineer said up to 72hrs so will wait before contacting them.
-
Hopefully, although over 48hrs later and no DLM change yet. Engineer said up to 72hrs so will wait before contacting them.
I find DLM can take up to a week to make any changes, it depends if your line is interleaved and how far interleaved it is. If interleaving is quite low it usually only takes a couple days. Although as the saying goes, every line is different and DLM is weird.
-
Thanks for the update. Hopefully the DLM will apply G.INP then gradually lower the SNR margin to 3dB, giving you a much faster connection.
The last couple recent examples of DLM resets have seen the lines retain G.INP throughout. Hopefully this is a much wider change that will happen on all lines.
-
Regarding the Hlog and QLN plots . . . What you have shown is truncated. You will need to adjust the configuration of DSLstats, to allow for the full width of 4096 sub-carriers of a VDSL2 circuit.
how to change it?
-
how to change it?
By clicking on "Change Tone Range" under an Hlog/QLN graph in dslstats.
Then expanding to show all the tones in use.
-
I find DLM can take up to a week to make any changes, it depends if your line is interleaved and how far interleaved it is. If interleaving is quite low it usually only takes a couple days. Although as the saying goes, every line is different and DLM is weird.
I had thought though that as the engineer requested a DLM reset that when that request went through it would resync without the banding and then DLM would do it's thing over the next few days to settle down.
Had this a good few years ago at another house and the DLM reset was done later that day, resync'd to a higher speed and removed banding.
-
I think sof006 may have missed the part of the thread where you confirmed an Openreach engineer had requested a DLM reset.
Have you had any resyncs since the engineer visit? As you say, I would normally expect an initial resync overnight after the visit. I notice now you said it was a Sky engineer. Do you mean Openreach? Sky do have their own engineers who's remit is little more than 'is it plugged in correctly', but I doubt they are able to carry out DLM resets without involving Openreach.
-
I think sof006 may have missed the part of the thread where you confirmed an Openreach engineer had requested a DLM reset.
Have you had any resyncs since the engineer visit? As you say, I would normally expect an initial resync overnight after the visit. I notice now you said it was a Sky engineer. Do you mean Openreach? Sky do have their own engineers who's remit is little more than 'is it plugged in correctly', but I doubt they are able to carry out DLM resets without involving Openreach.
No resyncs since the visit. It was a Sky BB engineer not OR, he had to ring through to request the DLM reset.
-
Interesting. The lack of resyncs says to me the process hasn't even been started yet. It is possible nowadays for ISPs to request DLM resets on VDSL, but I don't know anything about how this process works or how long it takes. The last paragraph in this article https://www.ispreview.co.uk/index.php/2018/02/ability-reset-openreach-fttc-broadband-dlm-profiles-arrives.html (https://www.ispreview.co.uk/index.php/2018/02/ability-reset-openreach-fttc-broadband-dlm-profiles-arrives.html) suggests it should occur overnight though, so I'm wondering if the request got lost somewhere in the communication chain. Not sure what to suggest other than waiting a little bit longer and then chasing it up with Sky if nothing happens. Perhaps other forum members know what is meant to happen here?
-
I'm fairly sure an OR engineer is meant to do any kind of DLM resets. I'd definitely ring back up and ask them whats going on.
-
I'm fairly sure an OR engineer is meant to do any kind of DLM resets.
They can and do.
They are no longer the only ones who can request this now though.
Sky, Talktalk and possibly BT send their own "non OpenReach" tech staff to customers homes if they think the issue is within the end users premises.
These "engineers" (i use that term loosely) can ask their employers (the ISP) to request a DLM reset.
This will only be actioned if deemed necessary though.
The ISP can of course request a DLM reset without sending anyone to the property.
-
So rang Sky this morning as it had been over 72hrs, spoke to nice support guy however it seems there were no notes about a DLM reset from the sky engineer and so he said the quickest way to resolve is to arrange a OR engineer (not Sky) to attend on Monday.
I asked whether it could be stated in notes the history so a remote DLM reset could be done so as not to waste his time, support guy said he would but I get the impression it will be a new visit and somewhat from scratch. Although if he does come to house I can ask him about FTTP progress here ;D
-
Just to close this off, OR engineer came over this morning and did some quick checks before instigating a profile reset and it has sync'd up at 65/20 now :cool:
Thanks for all the help :)
-
Thought i would post up some stats after a week after the DLM reset. DLM has kicked in again but this time in a positive way! Two resync's in the past week has seen the d/l stats increase and the SNR drop on DL to current 4.5dB.
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22961 Kbps, Downstream rate = 73784 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 71563 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): 4.5 7.4
Attn(dB): 17.6 0.0
Pwr(dBm): 12.4 7.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.0000 0.3781
L: 18716 5374
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 1293688
OHFErr: 0 51
RS: 1433111552 2267997
RSCorr: 43236070 400
RSUnCorr: 0 0
Bearer 1
OHF: 9717229 0
OHFErr: 0 0
RS: 97171673 0
RSCorr: 132 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 479950933 0
rtx_c: 734478 0
rtx_uc: 82664 0
G.INP Counters
LEFTRS: 56 0
minEFTR: 71552 0
errFreeBits: 1425218436 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4278945154 0
Data Cells: 1027118684 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: 22 202
SES: 22 0
UAS: 112 90
AS: 156130
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 71636.76 20063.54
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: 4375/4375 59/59
Total time = 7 days 8 hours 52 min 46 sec
FEC: 69450496 1662
CRC: 1147 231
ES: 22 202
SES: 22 0
UAS: 112 90
LOS: 2 0
LOF: 15 0
LOM: 0 0
Latest 15 minutes time = 7 min 46 sec
FEC: 140428 3
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 250846 1
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 = 8 hours 52 min 46 sec
FEC: 9663061 92
CRC: 0 11
ES: 0 9
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 24948171 189
CRC: 0 23
ES: 0 20
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 19 hours 22 min 9 sec
FEC: 43236070 400
CRC: 0 51
ES: 0 43
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>
-
Thanks for the update, if you are happy with your connection now, and it stays that way, then that is a good result.
However, the DLM has applied interleaving to your connection (you can see this from the interleave depth 'D' for bearer 0 downstream being a value other than 1, in this case 8) despite the fact you have G.INP enabled, pointing to it having detected some instability. I'm not 100% sure what the process the DLM should follow after a DLM reset on a good line now, perhaps someone else can advise, but I believe on Huawei cabinets nowadays you start with G.INP and no interleave and then, subject to no problems, gradually step down in SNRM to 3 dB. I would assume that the reduced SNRM of 4.5 dB is not this however since you have interleave, and is instead the result of the resync taking place at a relatively electrically quiet time, it will probably go back up to 6 dB with a corresponding speed decrease if you resync now.
As to why this has happened, you only have had 22 errored seconds (ES) over the 5.5 days before your last resync which is nowhere near enough to upset the DLM (you can read about the thresholds here https://kitz.co.uk/adsl/DLM.htm (https://kitz.co.uk/adsl/DLM.htm)). You do however have 22 SES, which may result in a DLM response (no idea what the thresholds are for SES). Have you had any resyncs other than the last one? Did you have DSLstats collecting data over the past week? If so, you may be able to see a burst of errors at some point in time.
Edit: Sorry, complete rubbish. See below.
-
Thanks for the update, if you are happy with your connection now, and it stays that way, then that is a good result.
However, the DLM has applied interleaving to your connection (you can see this from the interleave depth 'D' for bearer 0 downstream being a value other than 1, in this case 8) despite the fact you have G.INP enabled, pointing to it having detected some instability. I'm not 100% sure what the process the DLM should follow after a DLM reset on a good line now, perhaps someone else can advise, but I believe on Huawei cabinets nowadays you start with G.INP and no interleave and then, subject to no problems, gradually step down in SNRM to 3 dB. I would assume that the reduced SNRM of 4.5 dB is not this however since you have interleave, and is instead the result of the resync taking place at a relatively electrically quiet time, it will probably go back up to 6 dB with a corresponding speed decrease if you resync now.
As to why this has happened, you only have had 22 errored seconds (ES) over the 5.5 days before your last resync which is nowhere near enough to upset the DLM (you can read about the thresholds here https://kitz.co.uk/adsl/DLM.htm (https://kitz.co.uk/adsl/DLM.htm)). You do however have 22 SES, which may result in a DLM response (no idea what the thresholds are for SES). Have you had any resyncs other than the last one? Did you have DSLstats collecting data over the past week? If so, you may be able to see a burst of errors at some point in time.
Thanks for the info, haven't experienced any drops during the day over the past week so it seems ok. I have set DSL stats to run over the next 24hrs to capture more info. I had noticed a huge increase in FEC errors (as can be seen in stats).
It actually did it again last night with SNR dropping and connection speed increasing again...
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23056 Kbps, Downstream rate = 76002 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 75425 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.3 7.5
Attn(dB): 17.7 0.0
Pwr(dBm): 12.4 7.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.0000 0.3781
L: 19726 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 84 0
TxQueue: 21 0
G.INP Framing: 18 0
G.INP lookback: 21 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 3833994
OHFErr: 1 12
RS: 1237128848 3418545
RSCorr: 25741074 54
RSUnCorr: 0 0
Bearer 1
OHF: 1991283 0
OHFErr: 0 0
RS: 19912218 0
RSCorr: 210 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 481602125 0
rtx_c: 2300909 0
rtx_uc: 125781 0
G.INP Counters
LEFTRS: 77 0
minEFTR: 73985 0
errFreeBits: 2146507717 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 295860731 0
Data Cells: 235025356 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: 33 215
SES: 32 0
UAS: 150 118
AS: 31994
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 75502.61 20063.54
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: 5148/5148 17/17
Total time = 7 days 22 hours 26 min 59 sec
FEC: 100479778 1753
CRC: 1698 249
ES: 33 215
SES: 32 0
UAS: 150 118
LOS: 3 0
LOF: 22 0
LOM: 0 0
Latest 15 minutes time = 11 min 59 sec
FEC: 647483 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: 861850 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 = 22 hours 26 min 59 sec
FEC: 40692343 183
CRC: 551 29
ES: 11 22
SES: 10 0
UAS: 38 28
LOS: 1 0
LOF: 7 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 24948171 189
CRC: 0 23
ES: 0 20
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 8 hours 53 min 13 sec
FEC: 25741074 54
CRC: 1 12
ES: 1 9
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>
I will keep DSLstats running now until tomorrow for further analysis. Is there specific info to pull out of DSLstats to check?
-
Interesting. The SNRM does seem to have dropped to 3 dB now (ignore what I said about the 4.5 dB earlier, evidently this was the 4 dB step in the gradual reduction from 6 dB to 3 dB), as it should do on a stable line. I didn't know this still happens if interleaving has been applied. Perhaps interleaving will be removed later?
Just keep an eye out for any bursts of CRCs.
-
Looking on stats there is no interleaving, 3ms delay is standard for G.inp?
-
I think you're looking at bearer 1 there. Bearer 0 has D = 8 on the downstream which is interleave depth 8 right?
Edit: Bearer 0 also has delay = 0 on the downstream, perhaps that does indeed mean no interleave? Not sure I understand that, on my G.INP enabled connection I have D = 1 and delay = 0. How can there be an interleave depth of 8 but no delay? Is this perhaps ReTx high? I think someone a bit more familiar with VDSL needs to comment. In any case, the delay is what you really care about, so if it really is zero then that is good news.
-
I think you're looking at bearer 1 there. Bearer 0 has D = 8 on the downstream which is interleave depth 8 right?
Edit: Bearer 0 also has delay = 0 on the downstream, perhaps that does indeed mean no interleave? Not sure I understand that, on my G.INP enabled connection I have D = 1 and delay = 0. How can there be an interleave depth of 8 but no delay? Is this perhaps ReTx high? I think someone a bit more familiar with VDSL needs to comment. In any case, the delay is what you really care about, so if it really is zero then that is good news.
That's G.INP.
The interleaving depth (D) would be over 1,000 on such a high sync if it was traditional low interleaving.
INP would be 3 - 3.5
delay would be above 0 (minimum of 8ms delay on OpenReach).
That's all on Bearer 0
Bearer 1 being shown at all tells us G.INP is active.
There's no G.INP framing, no Bearer 1 and no rtx figures if G.INP is off.
There would be no mention of G.INP at all if it wasn't enabled.
-
Thanks j0hn, that clears that up. Sorry for the confusion jimmyca69, looks like all is well with your connection!