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]

Author Topic: HG612 Modem Stats - G.INP Graphs  (Read 11098 times)

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: HG612 Modem Stats - G.INP Graphs
« Reply #30 on: April 23, 2015, 04:59:44 PM »

the rtx_tx for me shows me during the noisy time (evening) and rtx_c has similar graph rtx_u shows when an error has occured just like CRC or ES and it also shows up as an error on errored seconds but why have a duplicate.

i would go for rtx_tx as it has more usefull info to a specific line.

It is a good question how much the two graphs overlap, and whether it is worth showing just one of them. Remember too that the graphs (right now) have two distinct purposes: the usual one of letting "normal" people see that statistics for their own line, plus the unusual one of the "technical" people (including me) trying to educate ourselves about what is going on ... in order to simplify things when helping others.

Right now that probably means showing more stuff than necessary, so we can work out whether we can ignore it later.

So..

If we consider some scenarios involving the rtx_* counters, perhaps we can see the interplay between them:

1) If rtx_tx is non-zero, while rtx_uc is zero (or close), it shows that retransmission works effectively at getting broken packets through.

2) If rtx_c and rtx_tx counters show roughly the same number, then it shows that after a failure requiring a re-transmission, the very first re-transmission tends to work.

3) However, if rtx_c and rtx_tx start to differ significantly, but rtx_uc stays low, it implies that the initial re-transmissions can fail too, but that subsequent re-transmissions work.

4) If rtx-c and rtx_tx differ significantly, and rtx_c starts to rise, it implies all re-transmissions are not getting through.

For my line (numbers in the previous post), we can see that it shows scenario (1). We can also see that it shows somewhere between scenarios (2) and (3) ... This is a relatively good line, but it shows one direction (the one with the counters in the thousands; I assume this is the upstream direction) where twice as many blocks are re-transmitted as are received correctly ... yet we can also see that nothing has ultimately failed.

Seeing both the rtx_tx and rtx_c numbers tells me that, even on a good line, we should expect rtx_tx to run quite a lot higher than rtx_c. What we don't know is how much higher we should expect it, while still classifying the line as "good".

So it'd be interesting to see, for other lines, how much rtx_tx and rtx_c can differ when rtx_uc does start to increase. And it would be nice to see how these values vary across the time of day.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: HG612 Modem Stats - G.INP Graphs
« Reply #31 on: April 23, 2015, 05:30:24 PM »

I don't disagree with the above, but one extra complication is that the rtx counter values aren't all reset when you change or restart the modem. When I replaced my HG612 with an 8800NL several days ago, I noticed that one (at least) of the counters retained the value it had before the change. So it must be stored in the DSLAM. I failed to note down which counter it was, I'm afraid.

I've certainly seen them survive a resync. But this made me think...

I did a manual power-cycle of the 8800 a few nights ago, and one reason was to specifically clear these counters... but I didn't actually check what had happened. Luckily HMS does a snapshot of the stats when it detects a resync, so I can compare values...

Before Power Cycle (68 hours before)Immediately After Power Cycle66 hours After Power Cycle
                        Counters
                        Bearer 0
OHF:            0               0
OHFErr:         0               0
RS:             2238611408      683709
RSCorr:         4038            1830
RSUnCorr:       0               0
                        Bearer 1
OHF:            15716295        51685
OHFErr:         0               0
RS:             188594802       2991759
RSCorr:         74              54
RSUnCorr:       0               0

                        Retransmit Counters
rtx_tx:         2663            342
rtx_c:          148             1283
rtx_uc:         72663           0

                        G.INP Counters
LEFTRS:         11              83
minEFTR:        80015           19997
errFreeBits:    327450856       528715602

...

ES:             10              0
SES:            10              0
UAS:            68              58
AS:             252486
                        Counters
                        Bearer 0
OHF:            0               0
OHFErr:         0               0
RS:             769216          284735
RSCorr:         0               0
RSUnCorr:       0               0
                        Bearer 1
OHF:            684             691
OHFErr:         0               0
RS:             7471            2765
RSCorr:         0               0
RSUnCorr:       0               0

                        Retransmit Counters
rtx_tx:         2894            0
rtx_c:          0               1445
rtx_uc:         0               0

                        G.INP Counters
LEFTRS:         0               89
minEFTR:        79982           19991
errFreeBits:    13422           601889803

...

ES:             0               0
SES:            0               0
UAS:            27              27
AS:             12
                        Counters
                        Bearer 0
OHF:            0               0
OHFErr:         0               0
RS:             1009927616      1677300
RSCorr:         4033            2108
RSUnCorr:       0               0
                        Bearer 1
OHF:            14721867        101516
OHFErr:         0               0
RS:             176661665       3291745
RSCorr:         94              67
RSUnCorr:       0               0

                        Retransmit Counters
rtx_tx:         3064            209
rtx_c:          168             1654
rtx_uc:         0               0

                        G.INP Counters
LEFTRS:         1               89
minEFTR:        79999           19997
errFreeBits:    288527996       674009735

...

ES:             0               0
SES:            0               0
UAS:            27              27
AS:             236506

I've guessed at the ones that are held in the DSLAM, and survive a power cycle - they're in bold, coloured red.



Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: HG612 Modem Stats - G.INP Graphs
« Reply #32 on: April 23, 2015, 06:24:58 PM »

I am resisting the urge to force a stats reset (xdslcmd info --reset) or force a resync on my own connection, but someone else has fairly recently experimented with his HG612 & comes up with the same sort of results as reported by WWWombat and roseway.

Due to the algorithm used to detect resyncs, a stats 'reset' is (probably spuriously) recorded as a resync via HG612 Modem Stats at the moment.


However, our conclusion was the same. i.e. that some of the stats stats are indeed stored at the DSLAM.



Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27895
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: HG612 Modem Stats - G.INP Graphs
« Reply #33 on: April 23, 2015, 07:10:23 PM »

However, our conclusion was the same. i.e. that some of the stats stats are indeed stored at the DSLAM.

I might just be caterwauling from the top of the pole that carries DP1032 but I will make the suggestion that all DS statistics are collected by the DSLAM (just as all US statistics are collected by the modem) and the devices interchange their "knowledge" with each other.  :-\

Hmm . . . Thinking about it, I am uncertain as to how the information interchange occurs between the devices when the circuit is in medley phase. :hmm:
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.

NewtronStar

  • Kitizen
  • ****
  • Posts: 4844
Re: HG612 Modem Stats - G.INP Graphs
« Reply #34 on: April 24, 2015, 12:03:47 AM »

This g.inp it's hard to find a pattern i know i'll get 3 - 4 errored seconds per day and they hit at 05:00 07:00 and 22:00 yet this spike of rtx_uc at 22:29 with 4 rtx_uc per min is much larger it still gives me 1 crc and 1 errored second.

Then take the FEC into the equation it shows the gradual RFI building up and then down.



 
« Last Edit: April 24, 2015, 12:15:41 AM by NewtronStar »
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4844
Re: HG612 Modem Stats - G.INP Graphs
« Reply #35 on: April 24, 2015, 11:56:33 PM »

well here is is again any spike on the RTX_TX graph that hits 100 it turns in to 1 errored second.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: HG612 Modem Stats - G.INP Graphs
« Reply #36 on: April 25, 2015, 11:46:17 AM »

@NS

Is that matched with a 100 in the rtx_c graph and a 1 in the rtx_uc graph?
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4844
Re: HG612 Modem Stats - G.INP Graphs
« Reply #37 on: May 04, 2015, 06:09:55 PM »

@NS

Is that matched with a 100 in the rtx_c graph and a 1 in the rtx_uc graph?

Yes they do, it's a shine event could be eletrical switch or even the ignition switch of my car as my incoming drop wire is directly above the driveway, but most just come out of the blue and had a few distance T/Storms yesterday (50 miles).

« Last Edit: May 04, 2015, 07:57:45 PM by NewtronStar »
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4844
Re: HG612 Modem Stats - G.INP Graphs
« Reply #38 on: May 11, 2015, 10:18:48 PM »

It seems my G.INP has gone into overdrive since this afternoon 12 hours, the RTX_C has had an almost steady feed 30 to 50 the FEC also has a steady feed of values 200-300 yet have not seen any errored seconds over 25 hours.

EDIT: it seems the G.INP ovrdrive has come to a end as seen from the second graph.

« Last Edit: May 12, 2015, 12:28:02 AM by NewtronStar »
Logged
Pages: 1 2 [3]