Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: adslmax on September 21, 2021, 10:02:33 AM
-
Since last night DLM made a change on the line overnight resync at 1am. I did noticed Bearer 0 INP and INPRein has changed from 550/540 0.00/0.00 to 641/607 10.00/2.00. Is that good or bad? I have checked speedtest via thinkbroadband link here: https://www.thinkbroadband.com/speedtest/1632214903751253755
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: G
Status: Showtime
Uptime: 8 hours 49 min 40 sec
Resyncs: 1 (since 21 Sep 2021 01:04:48)
Downstream Upstream
Line attenuation (dB): 38.8 0.0
Signal attenuation (dB): 38.8 0.0
Connection speed (kbps): 215072 34427
SNR margin (dB): 3.1 3.1
Power (dBm): 0.0 4.0
Interleave depth:
INP: 641.00 607.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 34483 Kbps, Downstream rate = 214416 Kbps
Bearer: 0, Upstream rate = 34427 Kbps, Downstream rate = 215072 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.1 3.1
Attn(dB): 38.8 0.0
Pwr(dBm): 0.0 4.0
Bearer 0
INP: 641.00 607.00
INPRein: 10.00 2.00
delay: 0 0
PER: 0.00 488.34
OR: 452.01 166.66
AgR: 22649.43 18693.49
-
Weren't you going to stop looking at stats?
-
The dslstats was running 24/7/365 by Raspberry Pi, so, I only look at the stats once a week
-
That's once a week too often.
Stop running dslstats and only start it again if you observe issues with actual usage of the connection and a speed test shows it is running slow (and that doesn't mean run speed tests all the time instead of dslstats).
-
To answer your question, if the circuit is still working fine then it's not an issue. However, unless there's a noticeable issue that's having a negative impact on your DSL service then it would probably be best to stop looking at the stats altogether. By all means keep logging them though, so you have a history of your line in case something noticeably negative happens in the future which turns out to be an actual fault, just don't keep looking at them regularly if there's no noticeable problem. Enjoy the service, speeds of which most people still dream of being able to get in this country at the moment.
That said, it looks like DLM may have adjusted your connection to be a bit more resistant to errors/interference. Whether that's good or bad is more subjective on whether it has negatively affected your service in a noticeable and somewhat moderate way. I presume it hasn't though.
-
Yes the line kept dropped many times for no reason yesterday - first time happen since G.fast first installed. The Sync kept bouncing up and down 215 to 159/ 34 to 12 plus the SNR jumping crazy 10dB from 2.1dB. But, it now stable at 215/34 with solid snr at 3.1dB no more bouncing or lots of resync.
The issues was only start yesterday morning 6am to 4pm all day. Next door has the same issues as mine when there is no DSL connection for 20 minutes. No dsl at all from the cabinet.
-
That's a lot more relevant than your first post, I guess something was causing a burst of errors in your area at that time.
-
Thing getting worse. Something is going on in my area.
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: G
Status: Showtime
Uptime: 0 hour 5 min 24 sec
Resyncs: 0 (since 21 Sep 2021 20:50:06)
Downstream Upstream
Line attenuation (dB): 41.4 0.0
Signal attenuation (dB): 41.4 0.0
Connection speed (kbps): 118177 12464
SNR margin (dB): 12.1 9.1
Power (dBm): 0.0 4.2
Interleave depth:
INP: 641.00 607.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown
-
Could be a fault developing. Assuming you have a dial tone on the landline that G.fast connects via, are you able to do a quiet line test (preferably with a corded phone) to see if there's potentially any unusual noise?
Failing that if the problem persists or gets worse then it might be worth contacting your ISP and perhaps they can perform some kind of remote test or troubleshoot this?
-
It's not just me. Next door neighbour has the same issues. The dsl light went off for ten minutes now. Don't know what happen. It's like this yesterday and again today. Maybe some work somewhere at the Openreach network
-
Line back on now:
Stats recorded 21 Sep 2021 21:35:58
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: G
Status: Showtime
Uptime: 0 hour 2 min 11 sec
Resyncs: 0 (since 21 Sep 2021 21:35:35)
Downstream Upstream
Line attenuation (dB): 38.7 0.0
Signal attenuation (dB): 38.7 0.0
Connection speed (kbps): 215184 34912
SNR margin (dB): 2.9 2.9
Power (dBm): 0.0 4.1
Interleave depth:
INP: 550.00 540.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown
RSCorr/RS (%): 0.0000 0.0080
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
In a few of the recently posted statistics there are three lines that "jump out at me" as not expected with a G.Fast circuit.
The first --
DSL mode: G
The second --
G.INP: Not enabled Not enabled
The third --
Vectoring status: Unknown
Puzzling. :-\
-
I am not the only one. Same with this person online stats : http://browni.co.uk/dslstats/Webserver/index.htm
-
If g.inp isnt enabled and INP values are still at 641/607 that could affect the sync speed due to error protection overheads. It's weird how vectoring is 'unknown'. Obviously if not enabled that will also affect sync speed.
I notice the line attenuation is also wavering between 38.7 & 41.4. I wouldn't normally pay too much attention to slight changes and only really looked because vectoring will obviously affect background noise levels.
Interesting that its not showing as enabled on Browni's Line either. Is he on same exchange? I wonder if theyve rolled out some new f/w or made changes to the DSLAM config. However his line has been up for 39 days and doesn't appear to have affected his sync speed.
-
Well we know DSL mode is a reporting glitch as he posted stats from the command line before the regrade which said:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29477 Kbps, Downstream rate = 209973 Kbps
Bearer: 0, Upstream rate = 29477 Kbps, Downstream rate = 160000 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.1 3.1
Attn(dB): 38.0 0.0
Pwr(dBm): 0.0 4.0
Bearer 0
INP: 550.00 540.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 241.24
OR: 378.27 140.00
AgR: 16876.78 15526.97
Since Link time = 16 hours 27 min 23 sec
FEC: 109165 349676
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
No mention of Vectoring or G.INP back then either. (in fact we see normal INP active)
-
The isp told me that all g fast must have vectoring as there is no way gfast can't run without it. But they told me possibilities the router isn't slow it but it still enabled on it. Anyway the line is back to INP 640 and 607 but weird as G.INP not enabled either.
Next door of mine has show me their router as they are with EE but it didn't metion any vectoring or G.INP at all but their sync are worse than mine. They now getting 102/14 but ee are sending out engineer today so they will tell me what is going on as ee told them their g fast has a fault.
My isp think could be down to my router fault but I declined it because it not just me also next door affect by it as well. The isp told me you need to put Openreach modem back in and will investigate it further because the engineer might charged you if they think the router are a fault.
-
Updated:
This morning saw openreach engineer went next door, so I just popped over ask the neighbour what the engineer say about our issues last few days they say nothing wrong with it and they did resetted their G.fast to default. They told me the engineer say all houses by us all should easily getting 330/50 because the cabinet not far. They now getting 277/48.
Make me wondering why I was capped at 210/30 when the engineer last checked in May on my line but I remember he saying to me you should getting maximum speed from the cab easy to get 330/50.
Still leaving the router on.
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 33727 Kbps, Downstream rate = 212360 Kbps
Bearer: 0, Upstream rate = 33575 Kbps, Downstream rate = 209039 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.4 3.1
Attn(dB): 38.7 0.0
Pwr(dBm): 0.0 4.1
G.fast framing
Bearer 0
R: 12 14
N: 221 210
Q: 5 4
L: 5848 4912
Lrmc: 0 0
Ldoi: 0 4928
Rrmc: 255 210
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 4973 4088
etru: 203624 33266
ETRminEoc: 5852 0
Counters
Bearer 0
OHF: 7904189 188809
OHFErr: 0 0
RS: 1483816395 554612265
RSCorr: 68266 309057
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 7518 716
rtx_c: 6698 0
rtx_uc: 0 0
G.fast Counters
minEFTR: 197168 34568
errFreeBits: 144900436 25564839
NOI
BSW: 192/192 30854/30854
SRA: 4/4 120/120
FRA: 0/0 0/0
RPA: 0/0 3/3
TIGA: 84/84 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 33554654 96031984
eocPkts: 1241153 338679
eocMsgs: 1241153 338679
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 19629786 8419184
Data Cells: 18388664 8080516
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
AS: 47424
Bearer 0
INP: 640.00 607.00
INPRein: 10.00 2.00
delay: 0 0
PER: 0.00 468.94
OR: 459.59 163.73
AgR: 22035.76 18266.77
Total time = 13 hours 14 min 21 sec
FEC: 68266 309057
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 1
FailedRetr: 1
FailedFastRetr: 0
Latest 15 minutes time = 14 min 21 sec
FEC: 1508 5007
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 230 5563
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FastRetr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 13 hours 14 min 21 sec
FEC: 68266 309057
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 1
FailedRetr: 1
FailedFastRetr: 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
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 13 hours 10 min 23 sec
FEC: 68266 309057
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
ZySH>
-
I tend to agree with the ISP in that the vectoring, G.INP and INP values/states are likely not correct from the router's statistics/info output, at least at times. I wouldn't fully trust the INP, G.INP values and vectoring states as being always correct from your router for now. It's unfortunate the engineer didn't find a fault, but this could be intermittent and if it is then it may likely take some time for an engineer to find (if ever).
-
I have now asked the ISP to request Openreach to do DLM resetted remotely and see what happen.
Updated:
The ISP say no.
No, it's not possible to do remote DLM resets, this is the same for all Openreach based connections I'm afraid regardless of carrier.
We'll continue to monitor the line for you over the next few days.
But, I did told the ISP yes Openreach do this including G.fast see here: https://www.ispreview.co.uk/index.php/2020/10/openreach-give-uk-isps-more-control-of-broadband-dlm-profiles.html
-
I should point out that the vectoring status requires a unique command - xdslctl info --vectoring . Have you run this command to confirm that vectoring is not enabled?
-
I should point out that the vectoring status requires a unique command - xdslctl info --vectoring . Have you run this command to confirm that vectoring is not enabled?
Seems to be specific to VDSL on my Broadcom-based Zyxel:
ZySH> xdslctl info --vectoring
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 54516 Kbps, Downstream rate = 390839 Kbps
Bearer: 0, Upstream rate = 49961 Kbps, Downstream rate = 330053 Kbps
Currently not in VDSL modulation --vectoring is only for VDSL mode
Edit: Not aware of any way to view vectoring on G.fast connections. It is mandatory anyway, that I am aware of.
-
Ah - I found it under Vectoring section on DSLStats
xdslctl info --vectoring
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 33784 Kbps, Downstream rate = 212065 Kbps
Bearer: 0, Upstream rate = 33632 Kbps, Downstream rate = 212360 Kbps
Currently not in VDSL modulation --vectoring is only for VDSL mode
ZySH>
-
I guess it being mandatory means why bother telling you? I mean it "kinda" makes sense, even if its confusing.
-
Good news the ISP has reply just now
Hi,
I can ask but previously been told it's a hard no without an engineer visit, which of course costs money.
The thing is as well, this won't really solve anything, it may temporarily uncap your speed but with increased error rates, then later DLM will simply add the tweaks in again to reduce the error counts.
I'll ask anyway for you and let you know.
Cheers
-
Unrelated, but does xdslctl info --vendor return the actual port number in use in ChipSet SerialNumber? If so, I am port 0. :)
-
In a few of the recently posted statistics there are three lines that "jump out at me" as not expected with a G.Fast circuit.
The first --
The second --
The third --
Puzzling. :-\
That seems to be the case for all Broadcom chipsets with G.Fast lines.
They show G.INP: Not enabled but the stats clearly show Retransmit Counters, rtx_tx, etc, are very much active.
The Vectoring stats on Broadcoms also specifically state they are for VDSL only.
It should be safe to assume that G.INP and Vectoring are both active.
-
I have now asked the ISP to request Openreach to do DLM resetted remotely and see what happen.
Updated:
The ISP say no.
No, it's not possible to do remote DLM resets, this is the same for all Openreach based connections I'm afraid regardless of carrier.
We'll continue to monitor the line for you over the next few days.
But, I did told the ISP yes Openreach do this including G.fast see here: https://www.ispreview.co.uk/index.php/2020/10/openreach-give-uk-isps-more-control-of-broadband-dlm-profiles.html
That appears to be specifically for VDSL2.
Although Mark writes
The current DLM system is used to control the speed and stability of copper based broadband lines (ADSL, VDSL2, G.fast),
He's just lumping all technologies together because they all have a DLM.
The ADSL DLM isn't even run by OpenReach.
Providers need to pay to use that functionality, with the cost being split between all CP's who take up the option.
Your provider UnchainedISP is not a direct OpenReach customer.
They purchase from BT Wholesale or Talktalk Business and not directly from OpenReach.
If their supplier (BTw or TTB) have not taken up the option of paying for the advanced DLM controls then there's nothing they can do. I expect BTw and TTB would have taken up that option though
The briefings related to the above DLM tweaking make no mention of G.Fast. I believe they are only available for the VDSL2 DLM.
You must be a nightmare of a customer. There's no need to contact the ISP every single time your sync drops slightly.
-
Updated from Openreach on my behalf
As part of a fault ticket we can request a remote DLM reset if the
circuit has been stable with no errors or drops for at least ten days.
If you'd like to raise a fault in the panel we can get the request
sent on to TTB.
The isp told me my line need to be stable for ten days then will requested for DLM resetted
-
How much does all this matter to your use of the circuit?
-
Test Result: Fail - Fault located in local network
Description: FAULT - Battery Contact
Fault Ref: *******××*******
Contact Details: 01*********
What is this battery contract fault mean?
-
It means that one (or more) other conductor(s) is (are) making contact with one leg of the pair of your circuit.
As the first line of that test result states: "Fault located in local network".
-
Guess we know why the neighbour is having the same problem? Also might suggest it WILL get fixed when their fault is looked into?
Honestly it seemed from the start there was no point chasing this up until the neighbours fault is looked into.
-
Am I correct here. The DLM banded on the line is only apply to both BTW adsl2 and Openreach FTTC but not sure if it does apply on Openreach G. Fast? Next door neighbour just told me they having issues again as engineer are pointless this morning when they found no fault
The openreach modem seem lots worsen than Zyxel G.fast Router which it rather odd:
177.9 / 24.7 - Openreach G.fast Modem (approved by Openreach SIN 498)
211.5 / 33.8 - My G.fast Router (non-approved by Openreach SIN 498)
The line seem stable for now for 21 hours:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 33955 Kbps, Downstream rate = 211479 Kbps
Bearer: 0, Upstream rate = 33807 Kbps, Downstream rate = 211772 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.1 3.1
Attn(dB): 38.7 0.0
Pwr(dBm): 0.0 4.1
G.fast framing
Bearer 0
R: 10 14
N: 255 210
Q: 4 4
L: 5824 4944
Lrmc: 0 0
Ldoi: 0 4928
Rrmc: 255 210
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 4947 4120
etru: 206287 33495
ETRminEoc: 5852 0
Counters
Bearer 0
OHF: 12894941 310034
OHFErr: 0 0
RS: 539887023 910687039
RSCorr: 171092 513294
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 48930 11624
rtx_c: 37161 0
rtx_uc: 0 0
G.fast Counters
minEFTR: 212721 34807
errFreeBits: 242111612 41448266
NOI
BSW: 348/348 56376/56376
SRA: 7/7 175/175
FRA: 0/0 0/0
RPA: 0/0 3/3
TIGA: 126/126 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 57593785 146859418
eocPkts: 2030902 539486
eocMsgs: 2030902 539486
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 21566188 9483397
Data Cells: 19535317 8943922
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
AS: 77368
Bearer 0
INP: 641.00 607.00
INPRein: 10.00 2.00
delay: 0 0
PER: 0.00 465.91
OR: 481.18 164.80
AgR: 22295.34 18385.78
Total time = 21 hours 33 min 25 sec
FEC: 171092 513294
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 1
FailedRetr: 1
FailedFastRetr: 0
Latest 15 minutes time = 3 min 25 sec
FEC: 90 1221
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 487 5064
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FastRetr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 21 hours 33 min 25 sec
FEC: 171092 513294
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 237 237
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 1
FailedRetr: 1
FailedFastRetr: 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
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 21 hours 29 min 27 sec
FEC: 171092 513294
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
ZySH>
-
Seem like this firmware are better for upstream according to Browni line stat:
Stats recorded 22 Sep 2021 19:36:03 - Browni's Line Stat
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d27b
DSL mode: G
Status: Showtime
Uptime: 40 days 4 hours 14 min 50 sec
Resyncs: 11 (since 10 Jul 2021 12:13:01)
Downstream Upstream
Line attenuation (dB): 35.2 0.0
Signal attenuation (dB): 35.2 0.0
Connection speed (kbps): 215425 42628
SNR margin (dB): 3.3 3.1
Power (dBm): 0.0 4.1
Interleave depth:
INP: 550.00 607.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown
RSCorr/RS (%): 24.0263 4.4944
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
___________________________________________________________________
Stats recorded 22 Sep 2021 19:36:18 - Adslmax's Line Stat
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: G
Status: Showtime
Uptime: 22 hours 2 min 27 sec
Resyncs: 0 (since 22 Sep 2021 16:50:15)
Downstream Upstream
Line attenuation (dB): 38.7 0.0
Signal attenuation (dB): 38.7 0.0
Connection speed (kbps): 215297 33748
SNR margin (dB): 2.7 3.1
Power (dBm): 0.0 4.1
Interleave depth:
INP: 641.00 607.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown
RSCorr/RS (%): 0.0228 0.0564
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
all g fast must have vectoring as there is no way gfast can't run without it.
He is correct. Momentory lapse of concentration - d'oh of course g.fast uses vectoring & g.inp.... and as already pointed out it must be a f/w restriction rather than lack of technology being there.
Regarding a reset:-
As J0hn says, not all ISPs have access for [VDSL] DLM reset. BT and Plusnet were amongst the first ISPs to take up the DLM reset option and some others followed soon after but its tends to be just the larger ISPs + Zen & AAISP who can.
The DLM reset option is only available to direct Openreach customers who signed up for this feature last year. Even so, afaik this is still not an automated feature and it requires manual requests submitting to Openreach via email. With Unchained being a VISP then it is unlikely they can do this without going through their supplier - who may or may not offer the service to their resellers.
Access to certain features (including the DSL checker database) are now restricted and the CP has to pay for access to the various suite of GEA tools and available information. If they are a VISP and not a direct Openreach customer then its unlikely they will have direct access to anything much more than the checker (ven that will be limited to the no of requests they can make per day) - and basic info about customers lines.
What is this battery contract fault mean?
Be aware that this particular check sometimes returns a false positive. It doesn't always mean there is an actual fault.
---------------
You must be a nightmare of a customer. There's no need to contact the ISP every single time your sync drops slightly.
I agree. From what I can see the line rate dropped for a few hours but is now operating within normal and perfectly acceptable range. It's not service affecting and for the life of me I cannot see why a DLM reset would be needed. I've skipped over some posts, but why are you talking about banding? You are syncing at over 210 Mbps so just enjoy the speed you are getting and forget the stats.
-
Updated:
DLM on G.fast has re-apply changed overnight (INPRein removed on downstream 10.00 to 0.00) and re-applied INP 551 from 641 on downstream:
Speed is now back to normal 209/34 throughput ;D ;D
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 35657 Kbps, Downstream rate = 219576 Kbps
Bearer: 0, Upstream rate = 35657 Kbps, Downstream rate = 219768 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.1 3.1
Attn(dB): 38.5 0.0
Pwr(dBm): 0.0 4.0
G.fast framing
Bearer 0
R: 14 14
N: 243 227
Q: 4 4
L: 5968 4896
Lrmc: 0 0
Ldoi: 0 5000
Rrmc: 243 227
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 5086 4064
etru: 212533 33347
ETRminEoc: 5990 0
Counters
Bearer 0
OHF: 5769389 69594
OHFErr: 0 0
RS: 4057280416 373288634
RSCorr: 81933 152572
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 5937 669
rtx_c: 4680 0
rtx_uc: 0 0
G.fast Counters
minEFTR: 213716 34656
errFreeBits: 710223001 18689458
NOI
BSW: 2362/2362 25384/25384
SRA: 0/0 46/46
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 40/40 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 168431368 421579442
eocPkts: 5883966 1555607
eocMsgs: 5883966 1555607
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3139754 1233311
Data Cells: 2234170 1010122
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 0 0
SES: 0 0
UAS: 341 341
AS: 34616
Bearer 0
INP: 551.00 607.00
INPRein: 0.00 2.00
delay: 0 0
PER: 0.00 498.71
OR: 447.21 163.20
AgR: 22409.12 18304.67
Total time = 2 days 14 hours 21 min 17 sec
FEC: 529815 1367319
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 341 341
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 1
HostInitRetr: 0
FastRetr: 2
FailedRetr: 1
FailedFastRetr: 0
Latest 15 minutes time = 6 min 17 sec
FEC: 864 1902
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 3045 4299
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
HostInitRetr: N/A
FastRetr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 14 hours 21 min 17 sec
FEC: 123386 244418
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 104 104
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 1
HostInitRetr: 0
FastRetr: 1
FailedRetr: 0
FailedFastRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 219046 554044
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 9 hours 36 min 55 sec
FEC: 81933 152572
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
ZySH>
-
I wonder if Bearer 0 INPRein 10 is the G.Fast equivalent of Retx High.
Did it affect the throughput as a percentage of sync?
-
I wonder if Bearer 0 INPRein 10 is the G.Fast equivalent of Retx High.
Did it affect the throughput as a percentage of sync?
Yes without INPRein 10 - the speed always 10Meg lower than the sync rate
with INPRein 10 - the speed are 25Meg lower than the sync rate
The upstream are unaffected! Sorry jOhn as BTw IP Profile will not work with TTB as there is no way to find out what the actually ip profile rate from sync rate but it easy to workout from between sync rate and throughput speed
EG:
Bearer: 0, Downstream rate = 211772 Kbps, Upstream rate = 33807 Kbps
Bearer 0
INP: 641.00 607.00
INPRein: 10.00 2.00
delay: 0 0
throughput speed 186/33
Bearer: 0, Downstream rate = 219768 Kbps, Upstream rate = 35657 Kbps
Bearer 0
INP: 551.00 607.00
INPRein: 0.00 2.00
delay: 0 0
throughput speed 209/35