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 a CRC, which triggers the ES (but I'm not sure).
[Edit: I see kitz was faster at her keyboard and a little more tactful than the perpetually grumpy kuro-neko!]
HG612_modem_stats has crashed 3 times HELP
the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad
Who is going to interpret/explain all those extra graphs to a new member which is having a line issue ?
I use Notepad++ (http://notepad-plus-plus.org/).
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).
I don't think any of these rtx_* counters impact on the CRC or ES counters.
the ONGOING_ERROR.LOG_file_ERROR.TXT file is to large to open using note.pad
This means that rtx_tx can be & often is greater than the sum of rtx_c & rtx_uc
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.
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.
Before Power Cycle (68 hours before) | Immediately After Power Cycle | 66 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 |
However, our conclusion was the same. i.e. that some of the stats stats are indeed stored at the DSLAM.
@NS
Is that matched with a 100 in the rtx_c graph and a 1 in the rtx_uc graph?