Kitz Forum

Broadband Related => Router Monitoring Software => Topic started by: Bald_Eagle1 on April 17, 2015, 08:32:27 PM

Title: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 17, 2015, 08:32:27 PM
Just a quick note...................


I have recently been tweaking and updating the programs.

These updates will shortly be released for updating via the GUI.

In the meantime, please see the attached G.INP montage in its proposed layout from the latest 30 days of stats from my connection (including the switch over from non-G.INP to G.INP active.

I have attempted to combine all the relevant Bearer 0, Bearer 1 & G.INP related stats into a single montage.

If G.INP is not yet activated, the usual Bearer 0 only data montage will be generated.


Green graph borders = Always present data
Grey graph borders   = Bearer 0 data
Yellow graph borders = Bearer 1 data
Blue graph borders    = non-specific Bearer data.


Comments/feedback regarding the proposed layout would be very much appreciated.

Just for information purposes, I have also attached the montage for a 24 hour period.

Title: Re: HG612 Modem Stats - G.INP GRaphs
Post by: kitz on April 17, 2015, 08:54:22 PM
Well done BE1.  Nice work. :thumbs:


There's quite a lot of data now to show.   
A thought just occured as I stretched the browser window across both dual monitors, that there is a lot of info there and for those of us that read line stats, I wondered about perhaps a cutdown version of the more important graphs that we use most of the time.

Still have the full monty, but say another version that is forum friendly and contains say just the US and DS SNRm graph, the combined output power,  combined DS&Us bitwaps etc etc.   If we suspect a problem with say the DS SNRm we could always ask for the full monty.

Its just a suggestion, no worries if its a PITA to do, but it would be interesting to see what others who read stats think too, and if it would make things easier to just be presented with the vital info first.
Title: Re: HG612 Modem Stats - G.INP GRaphs
Post by: burakkucat on April 17, 2015, 08:57:12 PM
Hmm . . . There is just so much information that it is rather overwhelming to try and take it all in. Also the physical size of the montages have become too large for easy viewing. Not only do I have to vertical scroll but horizontal scrolling is also required.  :-\

The phrase "over-egging the pudding" comes to mind.  :-X

[Edit: I see kitz was faster at her keyboard and a little more tactful than the perpetually grumpy kuro-neko!]
Title: Re: HG612 Modem Stats - G.INP GRaphs
Post by: Bald_Eagle1 on April 17, 2015, 10:26:01 PM
How's about these:-

6 days of VITAL_STATS & FULL_MONTY from a different G.INP active connection.


Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 17, 2015, 10:43:39 PM
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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 17, 2015, 11:16:49 PM
Now, that IS a tough question.

I thought that I had a reasonably good understanding of the differences between good & poor connections before G.INP was implemented & could immediately spot problem areas.

It immediately became much harder to do that as soon as G.INP was introduced, not least due to the masses of new data to consider.

What I have seen though is that G.INP seems to do a pretty good job of stabilising 'problematic' connections that would have previously taken significant speed hits & quite large increases in delay etc.


It seems that there is now a buffer to receive data where a pre-determined number of attempts are made to correct it via rtx_c etc.
Only if that still fails, are errors converted to CRCs etc. that need full retransmission.

The overhead used for G.INP seems to be far lower than the previous method of automatically applying high interleaving depths, delay & reduced sync speeds to deal with reasonably infrequent bursts of interference.


Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 17, 2015, 11:37:14 PM
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).

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 17, 2015, 11:55:14 PM
Here's the Bearer 0 OHFerr/CRC to go with the other graphs
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 17, 2015, 11:59:25 PM
& what about rtx_c & rtx_uc?
I THINK it will be the rtx_uc that causes a CRC, which triggers the ES (but I'm not sure).

Look BE1 you have given us excellent insight into our stats over the years with your program and your knowledge just keep going  ;) the weird part about G.INP is as you have pointed out it helps problematic lines and the goodside of that is we don't need to monitor are broadband lines so often which then has a downside the developers don't feel there is any need to expand on their projects.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 18, 2015, 12:08:07 AM
Another question to mull over..............

How the hell will we now be able to report a genuine fault to our ISPs with any real confidence, especially as 'real' line issues as shown in the other user's 6 day stats don't always result in clobbered sync speeds like they used to?

He & I believe he has been experiencing an intermittent HR/dodgy joint issue.
That would have been really easy to spot & provide hard evidence not too long ago, but now...............???


Title: Re: HG612 Modem Stats - G.INP GRaphs
Post by: Bald_Eagle1 on April 18, 2015, 12:15:02 AM
 :lol:

[Edit: I see kitz was faster at her keyboard and a little more tactful than the perpetually grumpy kuro-neko!]

That's probably because she's a M$ Windows user  ;) :baby:  :lol:

Personally, I open graphical forum attachments directly into my M$ Windows provided Photo Viewer program rather than directly in the forum page.
That way I can very easily use the mouse wheel to zoom in & out & also drag the picture up/down left/right to the area of particular interest.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 18, 2015, 12:58:37 AM
Warning

HG612_modem_stats is having a hissy fit the reason must be a HG612 firmware update

Software version = N/A
Software last change detected at 18/04/2015 at 00:53

Firmware version = N/A
Firmware last change detected at 18/04/2015 at 00:53

CPU version = N/A
CPU last change detected at 18/04/2015 at 00:53

CFE version = N/A
CFE last change detected at 18/04/2015 at 00:53


Software version = V100R001C01B030SP08
Software last change detected at 18/04/2015 at 00:56

Firmware version = A2pv6C038m.d24j
Firmware last change detected at 18/04/2015 at 00:56

CPU version = BCM6368
CPU last change detected at 18/04/2015 at 00:56

CFE version = 1.0.37-102.6
CFE last change detected at 18/04/2015 at 00:56
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 18, 2015, 01:29:48 AM
And this for the logs

24/01/2015 at 01:56 - Firmware version change detected, changed to A2pv6C038m.d24j from N/A
24/01/2015 at 01:56 - Software version change detected, changed to V100R001C01B030SP08 from N/A
24/01/2015 at 01:56 - CPU version change detected, changed to BCM6368 from N/A
24/01/2015 at 01:56 - CFE version change detected, changed to 1.0.37-102.6 from N/A
25/02/2015 at 22:24 - Firmware version change detected, changed to N/A from A2pv6C038m.d24j
25/02/2015 at 22:24 - Software version change detected, changed to N/A from V100R001C01B030SP08
25/02/2015 at 22:24 - CPU version change detected, changed to N/A from BCM6368
25/02/2015 at 22:24 - CFE version change detected, changed to N/A from 1.0.37-102.6
25/02/2015 at 22:24 - Firmware version change detected, changed to A2pv6C038m.d24j from N/A
25/02/2015 at 22:24 - Software version change detected, changed to V100R001C01B030SP08 from N/A
25/02/2015 at 22:24 - CPU version change detected, changed to BCM6368 from N/A
25/02/2015 at 22:24 - CFE version change detected, changed to 1.0.37-102.6 from N/A
03/04/2015 at 00:51 - Firmware version change detected, changed to A2pv6C038m.d24j from N/A
03/04/2015 at 00:51 - Software version change detected, changed to V100R001C01B030SP08 from N/A
03/04/2015 at 00:51 - CPU version change detected, changed to BCM6368 from N/A
03/04/2015 at 00:51 - CFE version change detected, changed to 1.0.37-102.6 from N/A
18/04/2015 at 00:53 - Firmware version change detected, changed to N/A from A2pv6C038m.d24j
18/04/2015 at 00:53 - Software version change detected, changed to N/A from V100R001C01B030SP08
18/04/2015 at 00:53 - CPU version change detected, changed to N/A from BCM6368
18/04/2015 at 00:53 - CFE version change detected, changed to N/A from 1.0.37-102.6
18/04/2015 at 00:56 - Firmware version change detected, changed to A2pv6C038m.d24j from N/A
18/04/2015 at 00:56 - Software version change detected, changed to V100R001C01B030SP08 from N/A
18/04/2015 at 00:56 - CPU version change detected, changed to BCM6368 from N/A
18/04/2015 at 00:56 - CFE version change detected, changed to 1.0.37-102.6 from N/A
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 18, 2015, 01:31:38 AM
HG612_modem_stats has crashed 3 times HELP
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 on April 18, 2015, 07:45:53 AM
HG612_modem_stats has crashed 3 times HELP


If it was HG612_stats.exe itself that crashed, could you post or email me the full details from ONGOING_ERROR.LOG_file_ERROR.TXT.?
Please include a continuous period from a few minutes before it crashed to a few minutes afterward.

If it was only the GUI that crashed, you'd be better asking Ronski in his thread:-

http://forum.kitz.co.uk/index.php/topic,15080.0.html



Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 18, 2015, 10:29:37 AM
the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: kitz 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++ (http://notepad-plus-plus.org/).
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: kitz 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. :/
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar on April 18, 2015, 12:17:58 PM
I use Notepad++ (http://notepad-plus-plus.org/).

Notepad++ says the file is to large to open  :o no wonder the file is 1.2GB  :'(
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 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.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Ronski 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.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: roseway 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 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.

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bowdon 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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...
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: roseway 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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.



Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: Bald_Eagle1 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.



Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: burakkucat 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:
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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.



 
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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.
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: WWWombat 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?
Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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).

Title: Re: HG612 Modem Stats - G.INP Graphs
Post by: NewtronStar 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.