Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Oldjim on September 14, 2017, 12:40:43 PM
-
This question is more specific
Using a Billion 8800NL Router
Occasionally the downstream FEC error rate hits about 100,000 FEC per minute with as reported by Routerstats and sticks there until either I initiate a resync or it happens automatically at which point with virtually no change in speed or noise margin it drops to between 100 -300 FEC per minute
Is there a reason why this happens and is there any way to stop it
Software Version 2.32d.dm12 and the latest version doesn't mention a fix for this
Current Stats
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 13 hours 56 min 55 sec
Resyncs: 0 (since 14 Sep 2017 11:38:44)
Downstream Upstream
Line attenuation (dB): 21.3 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 48720 8917
SNR margin (dB): 3.5 5.2
Power (dBm): 12.8 6.2
Interleave depth: 4 4
INP: 54.00 45.00
G.INP: Enabled Enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.1602 0.1419
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
It sounds kind of similar to what happens occasionally on my line. I can't see you on MDWS to check for further similarities, but this is what happens on mine.
Every day I get a small spike in errors. Every so often after this error spike, the error rate will go crazy causing a large amount of CRCs and err/Secs. It will practically flatline at this high level until I reboot the modem.
By which point DLM will have noticed and will take action the next day. Its a PITA but I havent found out what is causing it. I usually spot it happening because everything slows down to a crawl during this period and even surfing is problematic.
Screen caps below showing about 7 of these events over the past year. A couple of times I've spotted it myself and taken action by rebooting the modem to try and minimise DLM action.
-
After a router reboot the error rate bounced up over night to a constant 1 million per minute so will leave it to see what happens
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 19 hours 8 min 39 sec
Resyncs: 0 (since 16 Sep 2017 10:22:16)
Downstream Upstream
Line attenuation (dB): 21.3 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 49116 8812
SNR margin (dB): 3.3 5.6
Power (dBm): 12.9 6.3
Interleave depth: 4 4
INP: 56.00 46.00
G.INP: Enabled Enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 11.0648 0.0768
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
If it is only FECs then these are effectively errors that didn't happen, as they were corrected.
If there's no linked large rise in ES then I'd be tempted to leave it alone and just monitor the situation.
I think I'm right in saying the DLM isn't interested in FECs.
:)
-
I don't think it is, although other errors should be taken into account such as Err/Secs.
Whilst I am not certain, I suspect that for those on G.INP/Huawei cab, DLM may also monitor some other parameter such as LEFTRS.
-
Router just resynched after major burst
-
Could snadge's link here ( http://forum.kitz.co.uk/index.php?topic=20327.0;topicseen) be anything to do with this ???
-
@BS - doubtful. The link is about Internet traffic, this is more local ie between the modem and DSLAM.
I also had a burst this morning that stayed that way for about half an hour.
It's a daily event for me which causes a brief noise spike.... and sometimes the noise sticks generating hundreds of thousands of errors until the modem is rebooted.
Graph below shows my spike this morning - see how at about 9:10 my line started generating 18k CRC errors every minute. It's never at exactly the same time, but will usually be between 9-11am. The amount of errors also can vary, some days it may just be a few, yesterday it was 12k for only a couple of mins, but it is always there.
Its been doing it for well over a year.. and its damn annoying when it sticks because DLM will take action the next day even if I manually reboot the modem myself to stop it. OJ & I use different modems, so its not that.
-
Are you both using the same modem chipset though?
-
I am using the Broadcom chipset which I think is the BCM 63168 and the cab is Huawei
-
Router just resynched after major burst
I get that when DLM initiates a resync. It gives me a burst of ES/SES/FEC/Retx. It's almost always 10-11 SES. If it was retrain reason 1 then it was possibly DLM resyncing the line.
-
Happened again
Here are the FEC and SES and then it resyched by itself
-
Aye you on MDWS?
-
no
and since I switch between various computers and the most obvious one isn't on most of the time it wouldn't help
-
FEC rate now back to circa 100,000 but G.INP seems happy with rtx_tx and rtx_c at about 60 per minute and RSCorr (Bearer 1) mostly about 2 per minute all the others are reported as zero
Error seconds are virtually nil
-
I just got something similar with my FEC.
Since Retx was applied the FEC/min has been between 1-100
Randomly this morning about 9am it shot up to hundreds of thousands.
For the past few hours it's been just short of a million FEC, every single minute.
Just noticed this, rebooted the modem, and it's back to under 100/min. This had no effect on any the retx figures, only the FEC.
WTH could have caused this?
-
I wish I knew too - Yep the behaviour of yours is also similar.. it shoots up to a high rate and flat lines there until reboot. :-\
-
Is it necessary to reboot the modem, or does a re-sync make the issue go away?
It seems a bit like there's some bit-swapping (or some other form of on-line reconfiguration) not happening for some unknown reason. Or even some bug with the modem maintaining the counters.
-
resync sorts it
-
Resync may have stopped it, but I hadn't rebooted the modem in a while anyway. Bitswapping carried on as normal before/after rebooting.
-
Bitswapping carried on as normal before/after rebooting.
For every single tone? Do you get stats on the number of bitswaps requested, and the number actually done (which may be less)?
-
Is it necessary to reboot the modem, or does a re-sync make the issue go away?
It seems a bit like there's some bit-swapping (or some other form of on-line reconfiguration) not happening for some unknown reason. Or even some bug with the modem maintaining the counters.
I always do a power down using the button on the router as its quicker for me. I can never remember the cmd to do it via the CLI off the top of my head to take dsl down and then restart dsl. Time is usually critical trying to catch it before DLM notices and takes action. I usually only notice it because web browsing grinds to a crawl.
I had at one point considered doing some sort of automatic restart each day, but for the past few months there is no exact time-frame when it will happen other than morning. Some days it will be at 11, then some days it will be at 7am. I suppose the ideal situation would be if there was some way of getting the modem to resync itself once 'x' number of CRC's or Err/Secs occurs.
-
Are you both using the same modem chipset though?
Yes. Not sure what J0hn is using.
OJ has a Billion 8800NL and I have a VMG8324, both use the BCM 63168.
-
Not sure what J0hn is using.
According to his signature block --
Zyxel VMG8924 bridge mode
-
d'oh
-
Signature was needing updated. Using the vmg1312-b10a right now.
-
And it's a D'oh! from me . . . :doh:
-
d'oh
had eyes tested last week at specsavers and picking up my glasses next tuesday, the difference with and without lens was shocking. :)
-
Update
After regular disconnects (about once per day) the DLM has increased the default noise margin from 3dB to 4dB and I lost about 2Mb/s of speed
-
Now 3 days with a 4dB noise margin and the problem hasn't come back
-
So it seems as if a 4 dB target SNRM is the optimum for your circuit.
-
and the stupid system just dropped it back to 3dB
-
As much as I can appreciate the desire to "give the DLM process a good slap", try not to provoke it. You may find that it will revert back to the 4 dB SNRM target without too much drama.
-
Was very dubious to see this XdB on my circuit but let it do it's own thing and watched it very closely apart from larger FECS counts this circuit has behaved it's self I'm more relaxed now :)
-
I've been suffering from high amounts of FEC errors in thousands every 15mins with G.INP and interleave of 4. They seem to build up and up, get worse in time until errored seconds start happening into hundreds in a 15 min period then DLM takes action and increases SNR. At present i'm on a 4dB. Early this morning it was 3dB but proved too much with huge amounts of FEC errors and then ES's
Would going into fastpath on G.INP reduce FEC's?
-
The interleaving depth is largely irrelevant on G.INP. On Huawei cabinets, it's organised so that the interleaving covers one DTU (a DTU being the smallest unit of data that can be retransmitted). On ECI cabinets, it was done with the interleaving depth always set to 1. I think both cabinet types add some FEC when doing G.INP.
So you can't change to "fastpath" on Huawei G.INP, nor would it make any difference to the FEC level anyway.