Broadband Related > FTTC and FTTP Issues

Understanding Line Stats ...

(1/2) > >>

madhatter:
Firstly, thank you to all involved with this site for such a fantastic resource of useful information.
Secondly, having been reading the forum for a little while, it makes such a pleasant change to
see people being courteous and helpful.

To that end, I would be grateful for some help in interpreting my Line Statistics and specifically
why they apparently reset for a few days - explanation to follow.

Below is a short list of line stats taken over 21 days, showing my FECS, ES and SES counts.   
Line is VDSL on BT 40/10 package.
All stats were taken from a Netgear DM200 modem running OpenWRT 18.06.1 


Date                    FECS                 ES               SES
                        Near/Far        Near/Far       Near/far
29/12/2018      0/697191       0/55564        0/250 
01/01/2019      0/699973       0/56289        0/260
04/01/2019      0/708576       0/57217        0/261
 
08/01/2019      0/1535           0/115927      0/533
09/01/2019      0/2295           0/116081      0/533
11/01/2019      0/6158           0/116500      0/533
12/01/2019      0/7018           0/116678      0/533

12/01/2019      0/718389       0/58883        0/265
14/01/2019      0/719909       0/59249        0/265
16/01/2019      0/721571       0/59777        0/265
18/01/2019      0/729335       0/60275        0/265 


As you can see, the counts accumulate over time but not apparently within my modem.
I've read varying reports as to what the Near and Far end actually mean but I'm still not
sure. Please can someone confirm what those two fields actually refer to.

The more interesting question is what happened during the week of 8 to 12th January.
My line is very stable and DLM never intervenes. However, during the early hours of
Monday 7th January (about 00:30) my line went down for over two minutes.
OpenWRT re-established the link but as you an see, my line stats, that had been accumulating
were apparently reset in some way. The "new" counts then proceeded to accumulate for the rest
of the week.
Saturday lunchtime, I powered off all my network kit (other activities were to cause potential electrical
interference) and left the line down for about three hours.
When everything was powered on again, I was surprised to find I was apparently back on my "old"
accumulated line statistics. These counts then accumulated normally for the reset of the week.

It almost appears as if when my line went down on Monday 7th I was switched to another "logical"
line (within the exchange ??) - is that possible ?
Then, upon dropping the line again on 12th, I was re-allocated my old logical line.
The counts are obviously accumulated at the line level and I'm assuming that's within the exchange,
does that seem right ?

Thank you for any explanations.

Weaver:
A very warm welcome to the forum. I’m not familiar with this particular Netgear device. I’m thinking about your questions.

j0hn:
It's normal behaviour.
Near end is your modem, far end is the FTTC cabinet (DSLAM).
Basically another way of saying Downstream and Upstream.
Far end can't be reset by you, it only resets when the DSLAM reboots.

Those couple minutes downtime when the far end stats reset was likely the cabinet being rebooted remotely

madhatter:
Thank you j0hn.

What puzzles me is how the line stats reset themselves back to their original
sequence on the 12th January.
The line restart on 7th certainly seemed to reset/change the counters, although the
SES and ES were higher than before but the FECS were lower.
Those figures accumulated normally over the next few days.
However, upon me restating my line on the 12th, I appeared to go back to the original
accumulated figures.
That's what lead to believe the counters were somehow related to a logical port
at the exhange rather that the cabinet, if you see what I mean.

j0hn:
No idea to be honest.
All DrayTek devices with Lantiq chipsets behave in a similar way, with the far end figures never resetting unless something happens at the far end.

They don't swap lines back and forward between ports at 12:30 am, that would need an engineer to physically be at the cabinet at that time.
The line is physically connected to a single tie cable that goes to a single port and to change the port it would need physically connected to a different tie cable, this can't be done remotely.

Engineers don't do things like port swaps at midnight, but they do occasionally work on the cabinets at night.
I would expect changing a line card would take longer than 2 mins so that is also unlikely.

Nothing at the exchange would change any figures presented in the xdsl statistics.

Possibly something was reset, then a backup configuration was restored that made the error counts return to normal.

The honest answer is I have no idea. I still think a DSLAM reboot is the most likely cause.

Navigation

[0] Message Index

[#] Next page