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 16745 times)

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: HG612 Modem Stats - G.INP Graphs
« Reply #15 on: April 18, 2015, 10:29:37 AM »

the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: HG612 Modem Stats - G.INP Graphs
« Reply #16 on: April 18, 2015, 10:46:52 AM »

the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad

I use Notepad++.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: HG612 Modem Stats - G.INP Graphs
« Reply #17 on: April 18, 2015, 11:19:13 AM »

Quote
Who is going to interpret/explain all those extra graphs to a new member which is having a line issue ?

We will eventually get used to it and find the correct patterns.  Ive been reading adsl stats for >10yrs now.   
I cut my teeth on fixed adsl, because there wasn't too much info back then it was relatively easy.  Then we had rate adaptive dsl and target SNRm and interleaving to learn. 
I was a bit late to the party with fttc because previously until I got vdsl myself I didnt really poke my nose into vdsl stats and prior to hg612modem stats then there wasnt any way nor need for me to do so.  When I did get vdsl, I realised all the basic stuff was the same and the only real new thing for me to learn was hlog and qln and we now had more bands to look at, but all the theory was the same, so the transition for me wasnt too hard.   

I'll hopefully be the same with g.inp.  I havent dabbled into the world of G.INP stats yet.  1)Because I have other stuff on 2)Because I dont have it on my own line.
Until I get chance to sit down and observer data coming from a line Im familiar with (my own) Ive not really taken too much notice stats wise.


BE makes a valid point.  G.INP will mask some of the areas which used to help prove that there was a line fault, but because G.INP is applied (eventually!) to all lines, its designed to give more protection and more lee-way.
Before target SNRm with rate adaptive dsl, a line would either sync or it wouldnt and there became a larger buffer zone and Err/Secs became important. Im hoping that eventually we will spot patterns with g.inp.   But atm my head it too full of other stuff to start looking at the finer details. :/
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: HG612 Modem Stats - G.INP Graphs
« Reply #18 on: April 18, 2015, 12:17:58 PM »

I use Notepad++.

Notepad++ says the file is to large to open  :o no wonder the file is 1.2GB  :'(
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: HG612 Modem Stats - G.INP Graphs
« Reply #19 on: April 18, 2015, 12:30:08 PM »

I use a free program named TextPad.

It seems to be able to cope with huge files.

However, it would be handy to delete that particular file now and then (unless you are experiencing problems with HG612 Modem Stats).



Alternatively, you could turn of the 'extensive' & 'extra' debugging log options until program problems are experienced.

The various logs should then be much, much smaller.



If HG612 Modem Stats is still crashing, delete the huge logs, start again & then post the relevant data.

Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: HG612 Modem Stats - G.INP Graphs
« Reply #20 on: April 18, 2015, 12:45:11 PM »

there as been no issues with HG612_Modem_stats since the odd firmware update came in at 00:52 i say odd as the version numbers just looks the same the only change is the date it was installed on very strange.

ok i'll delete the ongoing log error file.

Logged

Ronski

  • Moderator
  • Kitizen
  • *
  • Posts: 4300
Re: HG612 Modem Stats - G.INP Graphs
« Reply #21 on: April 18, 2015, 08:38:00 PM »

I've also seen that odd firmware behaviour, both at home and at work, although it occurs more often at work with the HG612. I'm not sure if it's my program causing it or BE1s.

Basically the GUI looks in the xlogfile for the version information, if it's there then we get the version info otherwise we get N/A, when the new value differs from the previous value it gets noted as having changed.

If you're getting it happen a lot then I could make a special GUI to save a time stamped copy of the Xlogfile each time it happens, then we'll be able to take a look and see what's in there or not. Or if you are in front of the PC when it changes to N/A make a copy of the xlogfile.

Logged
Formerly restrained by ECI and ali,  now surfing along at 390/36  ;D

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: HG612 Modem Stats - G.INP Graphs
« Reply #22 on: April 19, 2015, 01:37:53 AM »

I'm having problems keeping up here, with trying to sort out my power problems (and some sort of access rights problem I'm going through with HG612 Modem Stats), but I thought I'd add something here...

Who is going to interpret/explain all those extra graphs to a new member which is having a line issue ?

At the moment a rtx_tx per min above 90 will give me 1 errored second on DSLstats.

& what about rtx_c & rtx_uc?

I THINK it will be the rtx_uc that causes one or more CRCs, which trigger the ES (but I'm not sure).

It is pretty tricky to interpret overall. Having seen the effect of a dicky power supply on DLM, and as DLM intervenes more, I can say that some things happen backwards now: The FEC/interleaving settings seem to reduce while the INP setting increases.

However, I think the retransmission counters work like this:

rtx_tx gets incremented, at the sending side, for at each retransmission. If something gets retransmitted more than once, the counter gets incremented multiple times.

rtx_c gets incremented at the receiving side when a retransmission is received correctly.

rtx_uc gets incremented at the receiving side when a transmission is determined to have never been received correctly, i.e. after a timeout with perhaps multiple retransmissions having been attempted but failed.

Therefore rtx_tx >= (rtx_c + rtx_uc).

On my statistics output (Billion 8800NL, Broadcom), I think the rtx_tx value in the first column aligns with the rtx_c and rtx_uc values from the second column, and vice-versa. The columns are probably best labelled as the near-end and far-end, rather than downstream and upstream.

Except ... I think rtx_uc can get incremented a lot in the event of a loss of service - perhaps because of DLM triggering a resync. I have one such counter set to a large value (72,000) which is an order of magnitude more than the other counters, and it hasn't increased in days. I suspect it got set that high when DLM de-intervened, but the power issues mean I haven't tracked the changes well enough to know.

I don't think any of these rtx_* counters impact on the CRC or ES counters.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: HG612 Modem Stats - G.INP Graphs
« Reply #23 on: April 19, 2015, 01:45:43 AM »

I don't think any of these rtx_* counters impact on the CRC or ES counters.

Rethink: I get gradual increases in rtx_tx and rtx_c, nothing in rtx_uc (except the 72,000 I mentioned previously). However, I get nothing in ES or CRC at all.

However, BE's graphs are interesting, and made me rethink. Perhaps proper increments to rtx_uc are indeed designed to impact ES and CRC; I just don't see these events as yet.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: HG612 Modem Stats - G.INP Graphs
« Reply #24 on: April 22, 2015, 11:53:58 PM »

I don't know it's the chicken and egg which come first, 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.

« Last Edit: April 23, 2015, 12:02:41 AM by NewtronStar »
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: HG612 Modem Stats - G.INP Graphs
« Reply #25 on: April 23, 2015, 07:14:24 AM »

I don't know if we have a proper definition of what these counters actually mean, but my interpretation is:

rtx_tx = Number of retransmissions
rtx_c  = Number of retransmissions which successfully corrected errors
rtx_uc = Number of retransmissions which failed to correct errors

So rtx_tx = rtx_c + rtx_uc

On my system rtx_uc is almost always zero, and this is reflected in CRCs and ESs. On a poorer quality connection these values will no doubt be higher. In my opinion, all three give valuable insight into the working of G.INP and the quality of the connection.
Logged
  Eric

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: HG612 Modem Stats - G.INP Graphs
« Reply #26 on: April 23, 2015, 07:32:48 AM »

From what some of us have seen & also from reading some G.INP documentation, it appears this is the case:-

rtx_tx = Number of retransmission attempts
rtx_c = Number of successfully corrected attempts
rtx_uc = Number of failed retransmissions.


rtx_tx will keep trying up to a pre-determined number of attempts until correction is not possible, when it becomes rtx_uc

This means that rtx_tx can be & often is greater than the sum of rtx_c & rtx_uc


EDIT:

From T-REC-G.998.4-201006


12 DTU counters

For trouble-shooting and testing of the retransmission functionality, three DTU counters are defined
to monitor the retransmissions:

– counter of uncorrected DTU (rtx-uc): this is a counter that is incremented each time a DTU
is detected in error and has not been corrected by one or more retransmissions within the
delay_max constraint;

– counter of corrected DTU (rtx-c): this is a counter that is incremented each time a DTU has
been detected in error and has been successfully corrected by a retransmission;

– counter of retransmitted DTU by the transmitter (rtx-tx): this is a counter that is
incremented each time a DTU has been retransmitted by the transmitter.

Multiple retransmission of the same DTU is counted as many times as it has been retransmitted.
Those counters are 32 bit values with wrap-around and shall be maintained by the xTU. They shall
be available upon request over the EOC. The counters shall be reset at power-on.

The counters shall not be reset upon a link state transition and shall not be reset when read.

« Last Edit: April 23, 2015, 07:49:18 AM by Bald_Eagle1 »
Logged

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 2395
Re: HG612 Modem Stats - G.INP Graphs
« Reply #27 on: April 23, 2015, 10:55:54 AM »

the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad

On reading this I looked up my own error log, and its 957mb's big. Also ONGOING.ERROR.LOG file is 336mb big.

Is it possible to change the file names to, for example;

ONGOING_ERROR.LOG_file_ERROR-OLD.TXT
ONGOING.ERROR-OLD.LOG

Will it create another new file when it can't find the original file name?

It would be good if it could somehow cut the files in to chunks. Maybe at 1gb file. Then maybe have an option to delete old logs or something. I know that's probably a lot of programming to add those features in.

I'm just thinking that as we go further in to faster speeds and more to fibre lines, these monitoring programs are going to become more and more popular.
Logged
BT Full Fibre 500 - Smart Hub 2

WWWombat

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

This means that rtx_tx can be & often is greater than the sum of rtx_c & rtx_uc

That is my interpretation too.

Here are the counters on my 8800NL right now...
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: HG612 Modem Stats - G.INP Graphs
« Reply #29 on: April 23, 2015, 03:04:44 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.
Logged
  Eric
Pages: 1 [2] 3