Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3 ... 7

Author Topic: Stat check on my line please  (Read 3028 times)

michty_me

  • Reg Member
  • ***
  • Posts: 425
Stat check on my line please
« on: June 06, 2018, 07:49:51 PM »

Evening all,

I was wondering if I could pester you for a few minutes of your time to check the condition of my line.
A brief history of the issue I've been having:
I had a D7000 fitted to my MK3 faceplate and it was up and running for pretty much two years without a glitch. Infact, My stats kept getting better throughout this time. It was only ever reset after firmware updates.

I was working away around christmas and when I can home my D7000 had frozen but unsure for how long. I reset it and it came back online with around 17/12 which was a fair hit from 74/19. Over the next few days DLM increased my speeds but stopped at 49/15 roughly for possibly 9 weeks or so. I think it was banded going by the sync speeds.
I spoke to Zen who sent out an engineer who said I had a very clean line, Changed to a MK4 faceplate and reset my line. After a week G.inp was back on, I had very few errors and sync was around 69/17 from then on.

Roughly every month my D7000 would lock up but I was home to reboot it until a few weeks ago when I went away for a long weekend. I returned to it locked up and upon rebooting it appears my line is banded again (Stats incoming). I have since downgraded my firmware to when I know I had no issues.

So after that wall of text, Can anyone see any obvious errors as to why my line may not be unbanded in the future. I'm just checking to see if anything requires fixing so I'm not waiting for ages for no improvement.

Stats are here and I'm connected to a Huawei cabinet. To me it looks quite clean with only 1 ES in the 12 days uptime. Not too sure if anything is obvious to the more experienced of users?
Code: [Select]
adslctl info --stats
adslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 17841 Kbps, Downstream rate = 60510 Kbps
Bearer: 0, Upstream rate = 17000 Kbps, Downstream rate = 54999 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):        7.4             5.6
Attn(dB):        17.2            0.0
Pwr(dBm):        13.6            7.5

                        VDSL2 framing
                        Bearer 0
MSGc:           -6              -6
B:              227             163
M:              1               1
T:              0               0
R:              12              12
S:              0.1319          0.3047
L:              14562           4621
D:              4               2
I:              240             176
N:              240             176
Q:              4               2
V:              0               1
RxQueue:                132             114
TxQueue:                22              19
G.INP Framing:          18              18
G.INP lookback:         22              19
RRC bits:               24              24
                        Bearer 1
MSGc:           122             58
B:              0               0
M:              2               2
T:              2               2
R:              16              16
S:              8.0000          16.0000
L:              32              16
D:              1               1
I:              32              32
N:              32              32
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               0
OHFErr:         1               0
RS:             3720368364              4081427
RSCorr:         49270           657590
RSUnCorr:       0               0
                        Bearer 1
OHF:            69602739                667573
OHFErr:         0               0
RS:             556821416               321483
RSCorr:         3               2023
RSUnCorr:       0               0

                        Retransmit Counters
rtx_tx:         9924274         17490
rtx_c:          11957           65043
rtx_uc:         3               356428

                        G.INP Counters
LEFTRS:         3               421
minEFTR:        54974           17000
errFreeBits:    937992906               1731511222

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    2283629181              0
Data Cells:     745809946               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:             1               0
SES:            0               0
UAS:            32              32
AS:             1117978

                        Bearer 0
INP:            57.00           57.00
INPRein:        1.00            1.00
delay:          0               0
PER:            0.00            0.00
OR:             0.01            0.01
AgR:            55120.28        17156.70

                        Bearer 1
INP:            2.00            4.00
INPRein:        2.00            4.00
delay:          0               0
PER:            16.06           16.06
OR:             63.75           31.87
AgR:            63.75   31.87

Bitswap:        36558/39273             33762/33769

Total time = 12 days 22 hours 33 min 30 sec
FEC:            49270           657590
CRC:            1               0
ES:             1               0
SES:            0               0
UAS:            32              32
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Latest 15 minutes time = 3 min 30 sec
FEC:            19              416
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Previous 15 minutes time = 15 min 0 sec
FEC:            43              2160
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           N/A
Latest 1 day time = 22 hours 33 min 30 sec
FEC:            3131            67211
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Previous 1 day time = 24 hours 0 sec
FEC:            2931            60590
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
Since Link time = 12 days 22 hours 32 min 57 sec
FEC:            49270           657590
CRC:            1               0
ES:             1               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
« Last Edit: June 13, 2018, 06:53:30 AM by michty_me »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 23582
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Stat check on my line please
« Reply #1 on: June 06, 2018, 08:29:07 PM »

I've taken a look and, to me, nothing looks particularly bad. However I suggest that you wait for comments from those more experienced than I in "reading the runes".

One thing did catch my eye --

Total time = 12 days 22 hours 33 min 30 sec
FEC:            49270           657590
CRC:            1               0
ES:             1               0
SES:            0               0
UAS:            32              32
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0


You mentioned that there was just one ES recorded but what about those 32 UAS?  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

johnson

  • Reg Member
  • ***
  • Posts: 494
Re: Stat check on my line please
« Reply #2 on: June 06, 2018, 08:35:11 PM »

That would be the 32 seconds the modem took to sync, during which the line was unavailable. No?

Edit: Echoing burakkucat, other people know better than I but:

Line looks clean, one thing of note is that you have upstream G.INP, and the retx high variant. So loosing around 8% of throughput:
Code: [Select]
                        Bearer 0
INP:            57.00           57.00
INPRein:        1.00            1.00

But its working well I guess given your near zero error count even after 12 days of connection.
« Last Edit: June 06, 2018, 08:45:15 PM by johnson »
Logged

michty_me

  • Reg Member
  • ***
  • Posts: 425
Re: Stat check on my line please
« Reply #3 on: June 06, 2018, 08:42:34 PM »

I am unsure what that is but according to this link

https://kitz.co.uk/adsl/linestats_errors.htm

UAS - Unavailable seconds

    Ten consecutive SES's will trigger a UAS event, and will remove the path from use. The path will become usable again after 10 consecutive seconds with no SES.

    A count of UAS events can be triggered by a LOS event and will continue to accrue for each second that the system is up and the path is unavailable.
Logged

spring

  • Reg Member
  • ***
  • Posts: 322
Re: Stat check on my line please
« Reply #4 on: June 06, 2018, 09:05:49 PM »

My VDSL2 AnnexB syncs on ECI have usually, and best seen, 26 UAS, which is like that from sync and doesn't change over months, but it would be 0.001% kind of differences.
I also think some number of UAS [non 0] will 99% be there, or maybe I'm wishful thinking.

Code: [Select]
ES:             0               0
SES:            0               0
UAS:            26              26
AS:             288435

Edit: My previous ADSL2 line synced in around half the time as VDSL and had 10-15 UAS so what Johnson said makes sense in terms of the UAS that is there right after a sync.

Edit2: But I honestly think it's just the unavailable seconds for use by the line, and that it probably synced at 32.

Edit3:
Quote
Unavailable Seconds (UAS)

Unavailable Seconds are calculated by counting the number of seconds that the interface is unavailable. The DS1 interface is said to be unavailable from the onset of ten contiguous SESs, or the onset of the condition leading to a failure (see Failure States). If the condition leading to the failure was immediately preceded by one or more contiguous SESs, then the DS1 interface unavailability starts from the onset of these SESs. Once unavailable, and if no failure is present, the DS1 interface becomes available at the onset of ten contiguous seconds with no SESs. Once unavailable, and if a failure is present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, if the failure clearing time is less than or equal to ten seconds. If the failure clearing time is more than ten seconds, the DS1 interface becomes available at the onset of ten contiguous seconds with no SESs, or the onset period leading to the successful clearing condition, whichever occurs later. With respect to the DS1 error counts, all counters are incremented while the DS1 interface is deemed available. While the interface is deemed unavailable, the only count that is incremented is UASs.

A special case exists when the ten or more second period crosses the 900 second statistics window boundary, as the foregoing description implies that the Severely Errored Second and Unavailable Second counters must be adjusted when the Unavailable Signal State is entered. Successive "gets" of the affected dsx1IntervalSESs and dsx1IntervalUASs objects will return differing values if the first get occurs during the first few seconds of the window. This is viewed as an unavoidable side-effect of selecting the presently-defined managed objects.
« Last Edit: June 06, 2018, 09:28:02 PM by spring »
Logged
No one knows what is the taste of the void.

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 23582
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Stat check on my line please
« Reply #5 on: June 06, 2018, 09:24:28 PM »

That would be the 32 seconds the modem took to sync, during which the line was unavailable. No?

Ah, yes. That would be it.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

spring

  • Reg Member
  • ***
  • Posts: 322
Re: Stat check on my line please
« Reply #6 on: June 06, 2018, 09:39:48 PM »

Other users here have locking up routers and in my country the ISP routers [bad ones] on some "rarer" mishaps, could somehow work fine the first few months and then stop working or aren't what they used to be in whatever way.
So if your power supply is good and anything possibly related is in order, it could be that the router spontaneously [or wearing off from certain factors], started acting up.
In terms of software if this first started after a firmware upgrade that didn't have some months without problems, then maybe you can revert to a firmware you had no problems with, and I recommend regenerating the config by completely resetting it if you did revert firmware.
About what you can improve, I can name just one xD, if your DSL cable is 0.3m or 0.5m that is the best length [ofc if you can do with that length]. You can see a few recommended names & types here: https://forum.kitz.co.uk/index.php/topic,20119.msg353430.html#msg353430
« Last Edit: June 06, 2018, 09:54:43 PM by spring »
Logged
No one knows what is the taste of the void.

sotonsam

  • Member
  • **
  • Posts: 98
Re: Stat check on my line please
« Reply #7 on: June 06, 2018, 09:49:54 PM »

I think your stats in the main look good. Obviously the router issues you were having hit your line hard, I wonder if it kept crashing and restarting prior to the lockup? (hence why DLM took such drastic action on your sync speed).

It seems to have recovered it though. See how it goes over the coming weeks as you may still see slight improvements, there aren't any obvious issues with the line that would be impacting you anymore. Just make sure you either replace the router or get yourself a UPS protection (if it was power surges knocking it on/off)
Logged
AAISP FTTC 80/20. BT Infinity FTTC 80/20. ECI Cab.

michty_me

  • Reg Member
  • ***
  • Posts: 425
Re: Stat check on my line please
« Reply #8 on: June 06, 2018, 09:58:46 PM »

The line has never had rtx high before I don't think. It usually sits happily at a 3dB profile with very minor errors.
Every time the router has locked up, It has just locked up out of the blue. I'm noticing quite a few D7000 users reporting the same thing.
Every time I upgraded the firmware, I always disconnected it from the faceplate, Carried out a firmware upgrade then Restored to factory settings and re-entered all the information manually WITHOUT using a config file.
The firmware I reverted to previously was an early beta I was sent from Netgear engineers to test out a feature they added (Can't remember what) but I remember it being very stable and up for months. Luckily I saved them all  ;D
I do have a Zyxel on order also as a backup for if it hangs up again then I'll start the waiting period.

As long as the line has no noticeable errors then I shall see what happens once I start approaching the time frame it starts tripping over itself.
Logged

re0

  • Reg Member
  • ***
  • Posts: 290
Re: Stat check on my line please
« Reply #9 on: June 07, 2018, 01:24:07 PM »

Seems I am a little bit late to the party in this instance. :-[

As you've said, it looks like you've got some banding going on, or at least certainly for the downstream as your SNRM is above the typical target:
Bearer: 0, Upstream rate = 17000 Kbps, Downstream rate = 54999 Kbps
. . .
                Down            Up
SNR (dB):        7.4             5.6
I wouldn't be too shocked, as I imagine this was down to the modem locking up.

Otherwise, stats seem to be pretty much in check.

As @johnson said, you have a high level of G.INP which will be responsible for a small loss of throughput.

There are some redundant bytes that should also equate to a very small overhead (if the connection was not already banded):
                        VDSL2 framing
                        Bearer 0
. . .
R:              12              12
It seems to be doing its job, though:
                        Counters
                        Bearer 0
. . .
RS:             3720368364              4081427
RSCorr:         49270           657590
RSUnCorr:       0               0

Sorry if I've repeated what you already knew.
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1790
Re: Stat check on my line please
« Reply #10 on: June 07, 2018, 01:27:20 PM »

Quote
The line has never had rtx high before I don't think. It usually sits happily at a 3dB profile with very minor errors.

Almost all lines on a 3dB SNRM target (or any sub 6dB target) are set to retx high, so you probably just didn't notice this.

The way DLM works it's very unlikely your line will ever drop to a lower SNRM target again (unless reset).

Now that you have removed the problem modem I would try contacting your ISP and see if they are able to perform a remote DLM reset. The line would be back at 3dB in just over a week.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

michty_me

  • Reg Member
  • ***
  • Posts: 425
Re: Stat check on my line please
« Reply #11 on: June 07, 2018, 02:00:14 PM »

Thank you both for a little further insight.
I may have been thinking back to before I was dropped down to a 3dB profile. My mistake.

I'm not overly convinced yet that the modem issue is fixed as I'm still using the D7000 as a combi until the Zyxel appears. I want to ensure that it remains stable for some time before contacting Zen (Are they part of the remote DLM reset trial?) so I don't end up in the same situation again in a month or two.
I was partly tempted to leave the D7000 connected for the next 64 days to see how it copes and to see if the lower SNRM is reached on its own assuming it doesn't lock up again with the old firmware, but that doesn't sound hopeful now.

One thing I did recall whilst out for my lunchtime stroll was that for a while recently DLM was coming in every week and slightly adjusting my line either up or down in speeds. Maybe by only a few hundred kbps sometimes. I did wonder if the D7000 would hang sometimes on one of these re-sync. This appeared to have calmed down over the past few months though.

Edit: Just logged into my Zen account and checked the line data. It shows as having a Sync at 23:45 on the 4th of June but as per my stats yesterday, That does not show and also doesn'y show on DSLStats this happened. Unless that is for something else?
« Last Edit: June 07, 2018, 02:18:10 PM by michty_me »
Logged

michty_me

  • Reg Member
  • ***
  • Posts: 425
Re: Stat check on my line please
« Reply #12 on: June 08, 2018, 07:14:11 AM »

Looks like DLM has made a slight adjustment and adjusted the INP level on the Upstream from 57.00 down to 47.00

Small changes, Slowly but surely hopefully.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6064
  • Retd sw dev; A&A; 4 7km ADSL2; IPv6; Firebrick
Re: Stat check on my line please
« Reply #13 on: June 08, 2018, 01:18:29 PM »

@michty_me  Would you be interested in posting up your QLN and bits-per-bin aka bits-per-tone aka bit-loading too? I forget what the magic runes are in the Broadcom-oriented CLI but I am sure someone will remind us if necessary.

I have to say, it looks very good, apart from what johnson said about the upstream, clearly it is needing some help there as it must be getting a good amount of noise in that band, perhaps regular spikes closely spaced in time to cause the high ReTX setting?

(Does high retx mean short DTNs? So that there is a significant overhead from per-DTN headers eg seq number, crc any other fields? I do need to go off and read the standards doc again as it all has gone out of my head.)
Logged

michty_me

  • Reg Member
  • ***
  • Posts: 425
Re: Stat check on my line please
« Reply #14 on: June 08, 2018, 03:25:11 PM »

Yeah I have no problem doing that. It will have to be later/tomorrow as I'm away out with a friend shortly for some beers in the sun  ;D

Edit: Is this what you require?



« Last Edit: June 08, 2018, 04:16:55 PM by michty_me »
Logged
Pages: [1] 2 3 ... 7