Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CerealKiller]

I have a long standing BT VDSL2 line stability issue. Researching in this forum, I have purchased a Vigor Modem and a Netgear router, purely to obtain greater insight to the line stats and become independent of the BT equipment in case it is at issue.
I'm around 85M from the cabinet. Openreach have thus far replaced my BT HH5a Router (replaced to above), Master socket, various interconnects along the line, the fibre-port, but still I get frequent intermittent drops.
The speed is near enough there and not an issue. However, the VDSL disconnects cause havoc to a number of reliant home connected devices. Normally a reboot of the Modem or BT router when it was in place brings back the connection.
Six engineers have come out, they no longer see any local faults, they reset the line and then exclaim that this may never be fixed due to the lack of investment in FTTC technology.

Could someone, help me to understand the significance of anything untoward within my posted stats below.

 ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
   Running Mode            :      17A       State                : SHOWTIME
   DS Actual Rate          : 73999000 bps   US Actual Rate       : 19999000 bps
   DS Attainable Rate      : 84404776 bps   US Attainable Rate   : 27902000 bps
   DS Path Mode            :        Fast    US Path Mode         :        Fast
   DS Interleave Depth     :        1       US Interleave Depth  :        1
   NE Current Attenuation  :        9 dB    Cur SNR Margin       :        8  dB
   DS actual PSD           :    -3.-6 dB    US actual PSD        :    12. 9  dB
   NE CRC Count            :        0       FE CRC Count         :    39492
   NE ES Count             :        0       FE  ES Count         :     8958
   Xdsl Reset Times        :        0       Xdsl Link  Times     :        2
   ITU Version[0]          : fe004452       ITU Version[1]       : 41590000
   VDSL Firmware Version   : 05-07-06-0D-01-07   [with Vectoring support]
   Power Management Mode   : DSL_G997_PMS_L0
   Test Mode               : DISABLE
  -------------------------------- ATU-C Info ---------------------------------
   Far Current Attenuation :       10 dB    Far SNR Margin       :       10  dB
   CO ITU Version[0]       : b5004244       CO ITU Version[1]    : 434da4a1
   DSLAM CHIPSET VENDOR    : < BDCM >
> vdsl status more
vdsl status more
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               0
 ReTxEnable   :      1               1
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      2               0
 LOF          :      0               0
 LPR          :      0               2
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :      0            57066 (seconds)
 ES           :      0            8958 (seconds)
 SES          :      0            1511 (seconds)
 LOSS         :      0               3 (seconds)
 UAS          :     30            97336 (seconds)
 HECError     :      0               0
 CRC          :      0            39492
 RsCorrection :      0               0
 INP          :    230             215 (symbols)
 InterleaveDelay :      0              17 (1/100 ms)
 NFEC         :     32              32
 RFEC         :     16              16
 LSYMB        :     16              16
 INTLVBLOCK   :     32              32
 AELEM        :      0            ----

[burakkucat]

Welcome to the kitz forum. 

I have a long standing BT VDSL2 line stability issue. Researching in this forum, I have purchased a Vigor Modem and a Netgear router, purely to obtain greater insight to the line stats and become independent of the BT equipment in case it is at issue.
I'm around 85M from the cabinet.

 . . .

Could someone, help me to understand the significance of anything untoward within my posted stats below.

I have a problem in trying to understand the statistics produced by the various DrayTek devices, probably because I have never used one, but we do have other members who should be able to help. Let's see what they deduce . . .

[kitz]

FE  ES Count         :     8958

This is what I find the most alarming.   Not sure how long the line has been up for but that is a heck of a lot of Err/Secs. ie 149 mins!

I notice that you are on Fast path, most likely due to the Openreach Enginer DLM reset, but I imagine DLM will notice some time soon and take some action.
Hmm but then I notice FECs.... so that info could well be old hat and not telling me much about the current info.    Same with Interleave delay. So data doesnt tie up with the current FAST mode. 

The Draytek info can be a bit confusing. Near end is your modem {ATU-R}, Far end is the CO (Exchange/DSLAM) {ATUC}.  Stream is supposed to be direction of travel from & to, so FE means upstream & NE is downstream  (I always forget and have to think it through like that).

So in this case it means Upstream is having the problems.    This is unusual in that we normally see most problems with downstream.   Issues with upstream is usually from telephony equip, internal wiring or the master socket.     Which in itself is strange as Openreach will likely have inspected this if they've been out to you several times.

Ideally you need to get a real-time graphing monitor on the line such as DSLstats, but unfortunately its not compatible with DrayTek routers.   John Owens Routerstats might work, but I'm not sure sorry.

[Alex Atkin UK]

That's not high compared to my lines, over 5 days I have:

Plusnet

Code: [Select]

FECS: 0 / 232026
ES: 1 / 20747
SES: 1 / 24
LOSS: 0 / 4
UAS: 34 / 34
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 1
15m FEC Errors: 0 / 5
1d Code Violations: 0 / 3
1d FEC Errors: 0 / 16
Zen

Code: [Select]

FECS: 3809 / 233813
ES: 76 / 25435
SES: 0 / 18
LOSS: 0 / 0
UAS: 36 / 36
HEC: 0 / 0
CRC_P: 0 / 0
CRCP_P: 0 / 0
15m Code Violations: 0 / 0
15m FEC Errors: 1 / 3
1d Code Violations: 0 / 2
1d FEC Errors: 5 / 25
Upstream ES is always like this, the Zen line pretty much NEVER drops sync despite this.  The Plusnet line did, but I think that was the Plusnet Hub failing as it started taking longer and longer to sync until recently it failed completely to get sync at all.  So far it seems more stable now I moved back to the old ECI modem.

[kitz]

DLM considers 144/288  Errored Seconds per day as being the pivot point to take action depending whether the line is on Speed/Standard profile.  Both the upstream and downstream are treated independently.   

There are also 1511 SES (Severely Errored Secs).

I did specifically say I couldn't see any indication of how long that line had been up for, and thus no idea if and when the totals had been reset.  Without any real-time indication of when those happened and when then those figures can be meaningless other than indicate there has been issues in the past.

Bear in mind we usually see BCM based stats and the vast majority of stats are from BCM based modems. There are relatively few (a handful of) people with stats from ECI modems like your are due to custom F/W.  A few modems don't always reset the stats after resync like the BCMs so.

-----

Btw I mentioned last night about FAST mode and FEC.  That line looks like it may still be in open profile mode for it to be using both FAST path channels.  Openreach do use a small amount of interleaving (without delay) on all upstream lines by default.

I thought Openreach was supposed to have gotten rid of the open profile after a reset or just that just apply to resets requested by the ISP and not those done by an OR engineer.   That line is showing a delay of 17ms which isn't possible in FAST path.   It's noted that the OP is on a Huawei cab.... and G.INP should be using the Interleaved path.

[CerealKiller]

!Thank you for all replies. My original stats were from a 10 hour up-time.

I'm now at 23 hours and I have noticed both a real speed drop to 65 Mbps (5Mbps down) which is not an issue, but interestingly the FEC errors are slowing down. Most importantly, the connection has not dropped in that time. Then again, it sometimes does this for a day or so, just to give me hope, then suddenly the failures kicks in with a vengeance. At least now I have the means to inspect the line statistics and from the explanations I know what to look out for.

For info based on 23 hour up-time.
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               0
 ReTxEnable   :      1               1
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      2               0
 LOF          :      0               0
 LPR          :      0               2
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :      0            57079 (seconds)
 ES           :      0            8958 (seconds)
 SES          :      0            1511 (seconds)
 LOSS         :      0               3 (seconds)
 UAS          :     30            97336 (seconds)
 HECError     :      0               0
 CRC          :      0            39492
 RsCorrection :      0               0
 INP          :    230             215 (symbols)
 InterleaveDelay :      0              17 (1/100 ms)
 NFEC         :     32              32
 RFEC         :     16              16
 LSYMB        :     16              16
 INTLVBLOCK   :     32              32
 AELEM        :      0            ----

I will also look into the real-time graphing software. If anyone else has experience running such on a Vigor 130, I would appreciate a heads up.

[j0hn]

This is what I find the most alarming.   Not sure how long the line has been up for but that is a heck of a lot of Err/Secs. ie 149 mins!

I notice that you are on Fast path, most likely due to the Openreach Enginer DLM reset, but I imagine DLM will notice some time soon and take some action.

Draytek shows fastpath when retx is enabled.
The stats show BDCM cabinet with retx enable 1 for both down/up.

Draytek ES error counters on the upstream don't reset either so that could be months and months of ES.

I notice the line is also banded at 74Mb.

[kitz]

Draytek shows fastpath when retx is enabled.
Draytek ES error counters on the upstream don't reset either so that could be months and months of ES.

Thank you J0hn. 
I was beginning to suspect, but with this not being a modem I was personally familiar with, you can understand my alarm at seeing such a high figure.

[Moderator edited to fix a typo.]

[j0hn]

!Thank you for all replies. My original stats were from a 10 hour up-time.

-

For info based on 23 hour up-time.
...

Not a single CRC/ES in that time so it does indeed look like the upstream (far end) error stats are from an extended period of time, possibly months.
For all I know they could be old errors reported by the DSLAM from your previous modem.

As I mentioned above rather than syncing at the full 80Mb down your line has been banded (capped) by the DLM at 74Mb.
This usually happens due to too many resyncs in a short time period.
That could be because of a faulty line resyncing too often (like you describe) or it can sometimes be self inflicted by repeatedly swapping modems, manually resyncing or turning the properties power on/off a lot.
I've even seen engineers causing banding by doing their tests and not resetting the DLM.

How often does the line usually lose sync?
How long have you been using the Draytek?

[peteS]

Hmm, well, you're on a Broadcom cabinet

DSLAM CHIPSET VENDOR    : < BDCM >

My experience was that my Draytek 130 modem and the broadcom cabinet which is only about 100m away really didn't like each other.  I had 80/20 sync speeds, but with multiple - 5 to 10 - resyncs per day.  I don't know if it was relevant, but my lone had vectoring enabled which I don't thnk play nicely between the chipset in the Vigor and the Broadcom chipset.

So, I gave up, sold the Vigor and bought an old Zyxel 8924-B10A for £20 on fleabay, installed lovely custom firmware from here to enable jumbo frames and vectoring, use it in bridge mode, and now have a line which sync at 80/20 and has downsteam SNR of 14db and it hasn't dropped at the moment for 20 days.  I'm monitoring it with dslstats and after a bit of fiddling, even managed to get the 2 VOIP ports working.

So, for what it's worth, I found Lantiq chipset in the vigor, which I believe is also in the HH5, didn't like staying synced at high speeds on my very high quality line.  I'd have been happy if it dropped the sync speed a little to become more stable, but it refused to do that - even if I manually increased the desired SNR.  So long as you don't mind a little firmware installation and a little telnet fiddling around (to discover the supervisor password), then I'd say it was by far the best £20 I've spent in a long time.  I even bought a second one and shoved it in the cupboard in case the first one packs up before fttp comes to my neck of the woods (or I retire, move to the country etc., which I think may well be sooner!).

[CerealKiller]

Last night, it looks like DLM removed G.INP from my line and the backend errors appear to have gone out of the roof. To be fair, the Vigor/Netgear combo appears to have either held on or regained its connection as it was live this morning. This is better than the HH5a was able to achieve.

To answer other questions, the Vigor modem is one week old, is running the latest firmware and, it was factory reset around 6 hours prior to my first posting. The in-place reset, was due to my improved understanding for how to access stats from behind my router. This forum and contributor know hows is gold.

This morning, I was half tempted to adjust my local SNR or disconnect for 30 mins as an attempt to trick DLM to retrain (seen elsewhere in this forum), but I decided it is best for me to give DLM time to find its stable state before I confuse it even further.
I am no longer getting help from BT, the last customer rep asked if I had considered switching to Virgin. For now, I am not letting them off the hook.

 ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               1
 ReTxEnable   :      0               1
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      4               0
 LOF          :      0               0
 LPR          :      0               2
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :      0            4881906 (seconds)
 ES           :      0            9007 (seconds)
 SES          :      0            1511 (seconds)
 LOSS         :      0               3 (seconds)
 UAS          :     30            97372 (seconds)
 HECError     :      0               0
 CRC          :      0            38004
 RsCorrection :      0               0
 INP          :      0             215 (symbols)
 InterleaveDelay :      0              17 (1/100 ms)
 NFEC         :    254              32
 RFEC         :     16              16
 LSYMB        :   5374              16
 INTLVBLOCK   :    127              32
 AELEM        :      0            ----

[j0hn]

G.INP was removed from the upstream only.
It's still active on the downstream.

That's another quirk of Draytek devices. They show many of the stats back to front.
Retx enable is 1 of the stats that gets down/up (near/far) mixed up.

Downstream G.INP always stays on after DLM initially enables it. I've never seen the DLM remove it.

Upstream G.INP is off by default and is only enabled when a line sees high errors.
G.INP lowers the errors, so DLM removes G.INP.
The errors come back, so G.INP is added again
Some lines continuously go through this back and forth of upstream G.INP being turned on/off.

[CerealKiller]

@Kitz !Thanks for sharing your know-how and for your advice. It is now my turn to contribute, rather than consume. Earlier you suggested acquiring a modem graphing software. This was a challenge for the Vigor, but then I found a script method which given my early usage works extremely well. I am sharing the guides here for anyone else that might be interested.

Script ----
https://github.com/poempelfox/vigor130
Munchin Server ---
https://www.digitalocean.com/community/tutorials/how-to-install-the-munin-monitoring-tool-on-ubuntu-14-04

I have this set up in a Ubuntu 16.04 (Linux) LXC Container, but equally it will work well on a native Ubuntu install

Some additional helpful notes ...

* If using telenet, my preferred method, then you need to grab the following telnet file

sudo apt-get install libnet-telnet-perl

* Once the Symlink is set-up for the script, use the following to test the modem output ...
   Note: replace <Symlink_Name> with the actual name you assign

munin-run <Symlink_Name> config

* The graphs took a couple of executions of the below and then some patience, plus don't forget to refresh your browser

sudo service apache2 restart
sudo service munin-node restart

*** Disclaimer ****
I have some computer knowledge, what I achieved I did by the above guides, trial and error and the support of Google to find answers for any issues. That's to say, I am happy to provide the above, but not able to help further in issues related to these softwares.

[SE]

Hi
Many people on the cab im on have had slowdowns, drops and so on
They say its bad cards/ports in the cab

Have O.R looked into this