cancel
Showing results for 
Search instead for 
Did you mean: 

ADSL Dropping and poor stats

chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

Ok, have attached some graphs showing greater resolution of what is going on. Generally it is pretty stable most of the time, occasionally misbehaving at certain times.
From these, it looks like quite often the router stops responding but the sync doesnt drop, with much less frequent drops. Any ideas why the router would stop responding and what would you suggest for investigating the drops?
Thanks
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: ADSL Dropping and poor stats

Hi Chris,
Sorry for the delay in responding - I've been off the forums for a couple of weeks, but I would have hoped CRT had picked this up.  The SNRM plots are not pretty, there are a number of synch drops due to noise.
Can you please set the Rx synch axis maximum to 18000k, that will make the synch speed plot visible.
RS does have a bug which causes it to screw-up the internal messaging system so that garbage is plotted.  The clear symptom of this is that the summary tab does not display the router status xDSL data.  Clicking the stop / start buttons fixes that, though there is no indication here that you are suffering that issue.
The vertical red lines are likely to be non-response from the router telnet interface.  What is strange is that they are at very regular intervals.  I have seen TG routers go non-responsive on the admin interfaces when busy processing massive rates of FEC.  What version of firmware are you on?  Sight of the router stats would be useful please.
Given the very regular pattern, do you have any scheduled / periodic activity on the network which correlates with the red lines?  A TBB BQM plot would be useful.
I suspect that you have more than one problem here.
Kevin.

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

No problems at all, thank you for your help! Its been a bit better recently but still very unreliable when on phone calls through the suresignal.
The most recent graphs were set to 15k which I thought was fine as my sync speed is only ~13mbit but now at 18.
Not getting many/any FEC errors, but a fair few others. I had an old router which did the same thing (non responsive and gave red lines so Plusnet tech decided to replace it about 6 months ago). Stats below:
xdsl info expand=enabled
Physical Layer Statistics:       
  Modem state:                  up
  Up time (Days hh:mm:ss):      8 days, 0:21:09
  xDSL Standard:                ITU-T G.992.5
  xDSL Annex:                  Annex A
  Channel Mode:                      Interleaved
  Number of reset:              3
  Chipset Vendor info (G.994.1):  Local Remote
    Country code:                  B500  B500
    ID:                            BDCM  IFTN
    Specific:                      0000  71C8
  System Vendor info (showtime): Local Remote
    Country code:                0F00  0000
    ID:                          TMMB  ----
    Specific:                    3C61  0000
  Bearers generic info          DS        US     
    Payload rate [Kbps]: 13107    991 
    Attenuation [dB]:    33.0          17.8         
    Margins [dB]:        6.3            6.1           
    Output power [dBm]:  0.0            12.6         
    Number of bearers:          1
    Bearer 0                    DS        US     
      INP [DMT symbols]:    0.00          0.00         
      Delay [ms]:          0.14          0.24         
      Depth []:          1              0.00
      R:                  0        0     
G.997.1 Statistics (Current):       
  Failures:
    Line failures              Near end
      Loss of signal (LOS):  3     
      Loss of frame (LOF):    27     
      Loss of power (LPR):  0     
  Performance monitoring:
    Line PM:          Near end
      Error second (ES):    47940 
    Channel PM:        Near end Far end
      Bearer 0:
        Code Violation (CV):    37471    542   
        FEC:                    0        0     
    ATM data path PM:            Near end Far end
      Bearer 0:
        HEC violation count (HEC):      133374  N/A
G.997.1 Statistics (last 15 minutes):       
  Failures:
    Line failures              Near end
      Loss of signal (LOS):  0     
      Loss of frame (LOF):    0     
      Loss of power (LPR):  0     
  Performance monitoring:
    Line PM:          Near end
      Error second (ES):    3     
    Channel PM:        Near end Far end
      Bearer 0:
        Code Violation (CV):    37471    542   
        FEC:                    0        0     
    ATM data path PM:            Near end Far end
      Bearer 0:
        HEC violation count (HEC):      133374  N/A
G.997.1 Statistics (last 24 hours):       
  Failures:
    Line failures              Near end
      Loss of signal (LOS):  0     
      Loss of frame (LOF):    0     
      Loss of power (LPR):  0     
  Performance monitoring:
    Line PM:          Near end
      Error second (ES):    86     
    Channel PM:        Near end Far end
      Bearer 0:
        Code Violation (CV):    37471    542   
        FEC:                    0        0     
    ATM data path PM:            Near end Far end
      Bearer 0:
        HEC violation count (HEC):      133374  N/A

Uptime: 8 days, 0:23:06    DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 991 / 13,107
Data Transferred (Sent/Received) [GB/GB]: 22.06 / 100.64
Output Power (Up/Down) [dBm]: 12.6 / 0.0
Line Attenuation (Up/Down) [dB]: 17.8 / 33.0
SN Margin (Up/Down) [dB]: 6.0 / 6.3
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 27 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 47,943 / 13
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 542 / 37,473
HEC Errors (Up/Down): 1,318 / 133,375
Dont have any scheduled activity and the only things that serve stuff to the web get very minimal use when Im in the house (e.g. Im the main user of ftp/webcam/energy monitor servers). The TBB TQM chart in my first post is a live one, so that is actually dynamic.
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: ADSL Dropping and poor stats

Hi Chris,
The BQM rather suggests a lot of activity 23:00 to circa 07:30 with coincides with the period where the red bars appear.
You make reference to SureSignal - that's a mobile over IP service?  One wonders what that might get up to over night.  You'd have no idea what that is up to during dark hours.  There was a red bar seen during the day in the RS plots - does that coincide with a call over SureSignal?
Watch out for correlations between poor performance / variable SNRM / RS red bars and SureSignal use.
Kevin

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: ADSL Dropping and poor stats

The RS SNRM plots mostly did look pretty reasonable to me apart from what was probably RS polling issues on the 23rd (RS not being able to get data normally because your CPU is busy doing other things resulting in all the red vertical lines). Two "losses of sync" on the 24th might have been Line Tests, latest stats suggest there's been only one further loss of sync 9 days ago now.
However there is one thing on the Tx SNRM plot on the 24th I'll come back to.
I'm not sure that I'd interpret the BQM as "a lot of activity" 2300-0730, there is obviously some small changes in the maximum latency (which could be due to other users on the same SVLAN at the exchange if not any usage on Chris's connection) and it's certainly a fraction of what can be seen with the daytime usage. I'm baffled by the reference to "red bars". I've mentioned about the polling issues - these are normally CPU related, nothing to do with the connection. The only other "red" around was the packet loss on the historical BQM where the connection was probably saturated by Upload as remarked by Matthew. The current (live) BQM in post #1 looks OK for what I assume is a fair bit of heavyish usage.
It would seem there've been 3 losses of sync since the 20th, 2 of which may have been line tests, and the 3rd, 9days ago now. (either that or there's been a reboot and 3 losses of sync the last of which was still 9 days ago - that scenario is unlikely from doing a touch of extrapolation with the errors - that supports the initial probability of only 3 sync losses since the 20th April).
You are not seeing any FEC errors, because there is no Interleaving (reply #14). This usually gives a higher level of CRC errors compared to when there is Interleaving, but the current rate appears to be within acceptable limits.
Now, back to the US SNRM graph on the 24th also the stats from the 16th to the 23rd/poss 24th.
Not only did the SNRM go up by about 1.3dB after what may have been a line test (0822), when the US speed had been 1219 on the 23rd, but then there's a glitch at 0833 and another at 0908 which may have been phone calls, but after the latter, the SNRM has dropped about 0.5dB.
This does tend to suggest the possibility of a poor connection (noise) somewhere which could be intermittent and not showing very often.
Not only that, but current stats show the US speed only 991 with the SNRM at 6dB. The DS speed has hardly changed, remaining in the 13000 ball park. This suggests any noise/poor connection is affecting the US more than DS.
So it's worth doing a few basic checks -
Can you hear/have you heard any crackling or other noises on the line when using the phone? Have you had any problems with incoming or outgoing calls? Try the Quiet Line Test 17070 option 2 if need be.
Do you have a Master Socket similar to the one on the left? Do you have any extension phone sockets, and what is normally plugged in where?
Are you using any extension phone leads between sockets and filters, or filter and the modem/router?
Do all your Microfilters look similar to this?
chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

Sorry, I didnt see these messages due to evidently not being logged in to the forums last time I visited.
Yes SureSignal is a Vodafone mobile signal over IP femtocell booster box. I cant see any link between mobile calls and dropouts.  Ive just enabled all of the router based traffic monitoring since I put Merlin's firmware on the AC68U and can see traffic levels and protocols across the day but cant see a trend.
Yesterday there were no red bars but sync speed is still down at 990 so not sure what happened to my 150kbps - I know if I restarted the Speedtouch modem it would go back up again. Im not sure whether the red bars are connected to this?
As for the master socket, I have only got a single phone socket in the house, which was recently (8 months ago) rewired using HQ shielded CAT6 from the BT junction box outside (only one pair used). Three is a single filter which looks like the one in your link and I rarely, if ever, have a phone connected to the socket since the only people who have the number are related to people who used to live here. I will do the quiet test and see how that goes.
Thanks again for all of your help
chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

So the quiet test doesnt seem to report any problems, but yet my line is still pretty rubbish. After some tweaks and investigation, I have found transfers run a bit quicker, and that one of my housemates had crashplan running with no limits (now added limits and added Asus AC68U QoS). However my upload keeps trailing off to 500kbps (even though I have an SNR of 9db) and ping performance is poor.
Uptime: 11 days, 19:59:31
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 483 / 12,015
Data Transferred (Sent/Received) [GB/GB]: 21.73 / 93.36
Output Power (Up/Down) [dBm]: 12.7 / 0.0
Line Attenuation (Up/Down) [dB]: 17.8 / 33.0
SN Margin (Up/Down) [dB]: 8.9 / 8.1
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 9 / 0
Loss of Signal (Local/Remote): 1 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 22,655 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 22 / 21,627
HEC Errors (Up/Down): 5 / 114,540
This is the TBB Ping test, with no transfers running at all (saved image so will not update) - unused connection except for a small bit of web browsing (1.5gb across the whole day)

Is there anything visible on the Plusnet end I can look out for? Or anywhere else to turn for more info?

EDIT:
After a restart of the router, my stats go back to something I would expect:
Uptime: 0 days, 0:03:44
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,215 / 13,115
Data Transferred (Sent/Received) [MB/MB]: 1.18 / 1.51
Output Power (Up/Down) [dBm]: 12.6 / 0.0
Line Attenuation (Up/Down) [dB]: 17.8 / 33.0
SN Margin (Up/Down) [dB]: 6.7 / 6.1
JayG
Pro
Posts: 1,145
Thanks: 143
Fixes: 6
Registered: ‎30-10-2011

Re: ADSL Dropping and poor stats

Looking good, especially the upstream synch rate, and interleaving still 'off'.
Inevitably there is less spare SNRM to play with now, so you will probably find the errors increase, especially after dark  - hopefully not by enough to get the DLM 'interested' though.
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: ADSL Dropping and poor stats

Hi Chis,
Quote
This is the TBB Ping test, with no transfers running at all (saved image so will not update) - unused connection except for a small bit of web browsing (1.5gb across the whole day)

1.5Gb is a substantial volume of transfer for an "unused" connection.  The TBB BQM rather suggests constant heavy hammering of the link.
Are you sure there are no hidden P2P / file share tools in your network?  Personally I'd shut down all of the connected kit apart from one PC and keep a watch on the BQM for an hour.  Something / Somebody is making use of that connection unbeknown to you.
Kevin

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

Most of that seems to have been Itunes and Apple updates at the start of the day (according to AC68U - though its only an iphone I use for testing and sits in my bag most of the time so seems a bit bizarre). On an average hour there was 40mb, which Im not convinced is that much - I think a fair bit of that is coming from my energy tracking device from OVO. Havent worked out how to use all the logging features properly yet. There are a few P2P style apps but with no transfers running for sure (most of the PCs were off that day). Will try unplugging things this evening.
Thanks
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: ADSL Dropping and poor stats

Remember that P2P apps can "re-serve" their content

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

chrischarles
Dabbler
Posts: 17
Registered: ‎29-04-2014

Re: ADSL Dropping and poor stats

Definitely nothing is running in the apps (not even stopped transfers, but no files open). Though perhaps it still talks to the cloud for some rason so will stop it from running completely.
Thanks
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: ADSL Dropping and poor stats

Apple updates etc seem to have a reputation for doing all sorts of things in the background and gobbling up large amounts of data, but I'mnot an expert on this issue.