Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3

Author Topic: Line problem vs Congestion  (Read 12511 times)

g1000

  • Member
  • **
  • Posts: 13
Line problem vs Congestion
« on: February 25, 2015, 09:40:56 AM »

Hi, my ISP insist I have slow speeds in the evening due to line errors and not congestion.

Looking at the results below, does this add up, can anyone advise please?





ISP line report

Upstream DSL Link Information   Downstream DSL Link Information
Loop Loss:   11.1   22.0
SNR Margin:   6.0   6.0
Errored Seconds:   0   8
HEC Errors:   0   
Cell Count:   87980   166738
Speed:   1251   18875
 
Maximum Stable Rate (KBPS):   4544   Fault Threshold Rate (KBPS):   3635
Mean Time Between Retrains (Seconds):   14239   Mean Time Between Errors Upstream (Seconds):   1139
Indicative Line Quality:   A   Mean Time Between Errors Downstream (Seconds):   59



Logged

boost

  • Reg Member
  • ***
  • Posts: 768
Re: Line problem vs Congestion
« Reply #1 on: February 25, 2015, 09:46:57 AM »

Yup.

Mean Time Between Errors Downstream (Seconds):   59

That is very high. I can't comment on whether that would cause 8Mb~ loss of throughput but that figure would ring alarm bells for me. Your upstream MTBE aint too great either.

What is your modem reporting for FEC/CRC/HEC/ES/SES/UAS?
« Last Edit: February 25, 2015, 11:16:53 AM by boost »
Logged

g1000

  • Member
  • **
  • Posts: 13
Re: Line problem vs Congestion
« Reply #2 on: February 25, 2015, 02:47:31 PM »

Yes, I would like the errors fixed and have received an engineer for the MTBE, although he concluded there was nothing wrong with my line. I'll have to post router stats when I get home.

Here's what I don't get though (I am hardly an expert though hence the question). If the 6x speed test is always fine, then how can the reduced throughput be caused by line errors? Shouldn't the 6x speed test be similarly affected if it was due to errors?

Also, after 11pm and all the way up to about 7pm, everything is perfect and the BQM is clean, doesn't this pattern also suggest congestion?



Logged

boost

  • Reg Member
  • ***
  • Posts: 768
Re: Line problem vs Congestion
« Reply #3 on: February 25, 2015, 05:32:02 PM »

I can only offer my best guesses because I only know a tiny amount about the stuff that interests me :)

Perhaps it is congestion. Perhaps it's not.

The MTBE is such a glaring problem, though, it's difficult for me to objectively consider congestion until it's been resolved.

As to why the 6x (multi-segmented?) download always works, I've no idea.

Best guess... lower segment/packet/cell size? Based on your 30ms ping, you are probably using a minimal level of interleaving, perhaps 8? I'm sure someone on here far cleverererer than me can work out the specifics but it seems possible your segmented download might be appropriately dealt with by your current interleave depth but larger segments may have too many errors to correct and get binned as CRC failures, forcing a retransmission?

It's been mentioned on here a few times that interference/noise is amplified at night time, as well as lots more electrical devices being powered up in the home and street after 18:00.

It's a stretch but it all seems plausible in my mind :P
Logged

tickmike

  • Kitizen
  • ****
  • Posts: 3641
  • Yes Another Penguin !. :)
Re: Line problem vs Congestion
« Reply #4 on: February 25, 2015, 08:23:52 PM »

Welcome . :)
Download DSLstats    http://forum.kitz.co.uk/index.php?topic=15049.msg280326#msg280326
and run them for few days and put graphs up on your post to see what's going off.
Logged
I have a set of 6 fixed IP's From  Eclipse  isp.BT ADSL2(G992.3) line>HG612 as a Modem, Bridge, WAN Not Bound to LAN1 or 2 + Also have FTTP (G.984) No One isp Fixed IP >Dual WAN pfSense (Hardware Firewall and routing).> Two WAN's, Ethernet LAN, DMZ LAN, Zyxel GS1100-24 Switch.

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7411
  • VM Gig1 - AAISP CF
Re: Line problem vs Congestion
« Reply #5 on: February 25, 2015, 11:03:30 PM »

MTBE of 59 seconds is fine.

That is the same as 1464 ES a day.

Looking at the pattern of the graph, it looks like congestion to me.

who is the isp?

from my experience if errors affect throughput, it will affect multi threaded equally.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33888
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Line problem vs Congestion
« Reply #6 on: February 26, 2015, 12:02:57 AM »

Hmm  need to see some more line stats re errors and as suggested by mike, an SNRm graph from dslstats or routerstats.

The curve of the higher latency on TBB graph at first glance looks like a bit of congestion..  however those spikes could just be you using your connection to its max.   Theres something also odd about the pulse spikes and their frequency, but that again could be something regularly using your connection on a scheduled timer. 

Its rarer to see the upstream TBB speed test graph waver..  as most networks can easily withstand 1Mb upstream.

MTBE 59 is Amber and therefore acceptable.  Im presuming that because of your normal latency of 30ms you will be interleaved.  It entirely depends on your distance from London but on average I'd expect 16ms = no interleave,  24ms to be Interleave low and 32ms to be Interleave high to TBB.

Im also concerned about your MBTR - which indicates 6 resyncs in the past 24hrs. 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7411
  • VM Gig1 - AAISP CF
Re: Line problem vs Congestion
« Reply #7 on: February 26, 2015, 12:11:33 AM »

yes it can be local congestion or isp congestion, the spikes may be local, but I think the general yellow bit is remote.

really he needs to also do a off peak speedtest to rule out his hardware.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33888
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Line problem vs Congestion
« Reply #8 on: February 26, 2015, 12:32:05 AM »

If he is on Interleave high and getting 1464 ES then that line is possibly quite noisy.  Again if it is interleaved high, then you'd expect the target SNRm to also have been increased, so theoretically ES should be reasonably low.    Its pie in the sky guesswork though until we see some full stats.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

g1000

  • Member
  • **
  • Posts: 13
Re: Line problem vs Congestion
« Reply #9 on: February 26, 2015, 02:34:06 PM »

Thanks guys, to answer some of your Qs:

- The ISP is Plusnet, the problem started around January this year.
- Off-peak download speed tests are always fine. Things dip in the evening and are back up to full speed before midnight.
- Upload speed tests are always wavering, peak or off-peak. I reported it to Plusnet but I don’t think they took much notice of it.

- The BQM is the same when the line is totally idle, I switched off wireless with no devices connected one day to check this. Same packet loss and avg latency hump - starts in evening, resolved by midnight.
- The strange regular spikes on the BQM appear to be a quirk of the Netgear modem-router in use at the time, they are not there with the Technicolor router.
- I swapped routers, cables, filters, phone, am using the test socket and tested wired with diff machines (PC and Mac) - made no difference. The only thing I noticed is when using the Netgear, the upload speed tests are less wavering than with the Technicolor, but they are still wavering.

- Interleaving is off (left to DLM) location is West Yorkshire.
- The pings reported by BQM are under 15ms off-peak which matches a command line ping. (The TBB speed test never gives a reliable figure in my experience).

- From looking manually at the SNR margins, they are always rock-solid e.g. 5.9, 6.0 or 6.1 even at night and problem periods.
- DLM in fact previously always selected 3dB down target SNRM for my line and this was solid too.
- Plusnet reset DLM in January when they saw this, target has since stayed at 6dB (down and up) and interleaving off.

- I don’t know why the MTBR indicates 6 resyncs in a day, this is definitely not accurate.
- The line is very stable and only drops sync if I cause it, or Plusnet test the line.I know this from monitoring the uptime in the router stats, the BQM graphs, and the RADIUS plots which Plusnet attach the same time as the line reports.
- At the time of the line test, it was over 5 days since a resync, which in turn was caused by Plusnet testing the line previously  Before that it was over 5 days again due to the DLM reset.

- I was wondering what do the errored seconds in the line test refer to exactly - over what time period (0 upstream, 8 downstream)?
- In fact, now I look more closely, Plusnet posted complete results for 2 line tests, on 2nd Feb and 8th Feb. They both have absolutely identical “MTBx” figures - surely this can’t be right, especially as MTBR is so wrong, it’s like the MTBx figures are stuck? Other figures are different between the 2 tests, and the max stable and fault threshold rates are totally different.

- Plusnet’s notes to the engineer said “low MTBE causing slow speeds in evening”
- The engineer said his tester picked up “only 4 errors” in 5 minutes, which he said was nothing.
- He then rang some department who could access stats he couldn’t, they told him the line was absolutely fine and to report back to Plusnet slow speeds were probably due to congestion.
- The current state of play is I am waiting for Plusnet’s update after the visit.
Logged

g1000

  • Member
  • **
  • Posts: 13
Re: Line problem vs Congestion
« Reply #10 on: February 26, 2015, 02:39:11 PM »

Router Stats taken in January, couple of weeks after problem first noticed

DSL Connection

Link Information

Uptime:
124 days, 16:24:22

DSL Type:
ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]:
1,251 / 20,555

Data Transferred (Sent/Received) [GB/GB]:
21.18 / 400.74

Output Power (Up/Down) [dBm]:
12.4 / 0.0

Line Attenuation (Up/Down) [dB]:
11.5 / 22.0

SN Margin (Up/Down) [dB]:
5.6 / 3.0

System Vendor ID (Local/Remote):
TMMB / ----

Chipset Vendor ID (Local/Remote):
BDCM / IFTN

Loss of Framing (Local/Remote):
0 / 0

Loss of Signal (Local/Remote):
0 / 0

Loss of Power (Local/Remote):
0 / 0

Loss of Link (Remote):
-

Error Seconds (Local/Remote):
176,810 / 0

FEC Errors (Up/Down):
0 / 0

CRC Errors (Up/Down):
8,601 / 307,778

HEC Errors (Up/Down):
8,690 / 3,930,991
Logged

g1000

  • Member
  • **
  • Posts: 13
Re: Line problem vs Congestion
« Reply #11 on: February 26, 2015, 02:43:01 PM »

Router Stats - Recent

DSL Connection

Link Information

Uptime:
1 days, 4:30:12

DSL Type:
ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]:
1,251 / 18,875

Data Transferred (Sent/Received) [MB/GB]:
278.34 / 4.19

Output Power (Up/Down) [dBm]:
12.6 / 0.0

Line Attenuation (Up/Down) [dB]:
11.2 / 22.0

SN Margin (Up/Down) [dB]:
6.1 / 5.9

System Vendor ID (Local/Remote):
TMMB / ----

Chipset Vendor ID (Local/Remote):
BDCM / IFTN

Loss of Framing (Local/Remote):
0 / 0

Loss of Signal (Local/Remote):
0 / 0

Loss of Power (Local/Remote):
0 / 0

Loss of Link (Remote):
-

Error Seconds (Local/Remote):
2,797 / 0

FEC Errors (Up/Down):
0 / 0

CRC Errors (Up/Down):
19 / 616

HEC Errors (Up/Down):
23 / 9,507
Logged

g1000

  • Member
  • **
  • Posts: 13
Re: Line problem vs Congestion
« Reply #12 on: February 26, 2015, 02:51:39 PM »

2nd Feb Line Test

Radius - Connected for 5 Days, 22:47:50
0 drops in last 24 hours
0 drops in last 72 hours
0 of 0 (0%) User Req Drops in last 7 days

xDSL Status Test Summary

Sync Status:
Circuit In Sync
General Information
NTE Status:

NTE Power Status:
PowerOn
Bypass Status:
 
Upstream DSL Link Information/Downstream DSL Link Information
Loop Loss:11.1/22.0
SNR Margin:6.0/6.0
Errored Seconds:0/8
HEC Errors: 0
 
Cell Count:87980/166738
Speed:1251/18875
 
Maximum Stable Rate (KBPS):4544
Fault Threshold Rate (KBPS):3635
Mean Time Between Retrains (Seconds):14239
Mean Time Between Errors Upstream (Seconds):1139
Indicative Line Quality:A
Mean Time Between Errors Downstream (Seconds):59

8 Feb Line Test

Radius - Connected for 5 Days, 13:22:30
0 drops in last 24 hours
0 drops in last 72 hours
0 of 0 (0%) User Req Drops in last 7 days

xDSL Status Test Summary
Sync Status:
Circuit In Sync
General Information
NTE Status:

NTE Power Status:
PowerOn
Bypass Status:

Upstream DSL Link Information/Downstream DSL Link Information
Loop Loss:11.1/21.5
SNR Margin:6.5/5.8
Errored Seconds:0/6
HEC Errors:0

Cell Count:60473/92432
Speed:1223/18907

Maximum Stable Rate (KBPS):18176
Fault Threshold Rate (KBPS):14541
Mean Time Between Retrains (Seconds):14239
Mean Time Between Errors Upstream (Seconds):1139
Indicative Line Quality:A
Mean Time Between Errors Downstream (Seconds):59
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7411
  • VM Gig1 - AAISP CF
Re: Line problem vs Congestion
« Reply #13 on: February 27, 2015, 01:12:58 AM »

well the MTBE reported is an average, so e.g. there could be a MTBE of say 10 in the evening but only 130 in the day, which would give an average around what you got.

However I am still of the opinion this is not errors on the line.  For errors to consistently delay or drop packets you would need a much worse MTBE than 59.
Logged

tickmike

  • Kitizen
  • ****
  • Posts: 3641
  • Yes Another Penguin !. :)
Re: Line problem vs Congestion
« Reply #14 on: February 27, 2015, 10:44:45 PM »

Some graphs would tell a thousand words. ;)
Logged
I have a set of 6 fixed IP's From  Eclipse  isp.BT ADSL2(G992.3) line>HG612 as a Modem, Bridge, WAN Not Bound to LAN1 or 2 + Also have FTTP (G.984) No One isp Fixed IP >Dual WAN pfSense (Hardware Firewall and routing).> Two WAN's, Ethernet LAN, DMZ LAN, Zyxel GS1100-24 Switch.
Pages: [1] 2 3
 

anything