Latency spikes on download

[#1]

Hi all,
Something odd has started happening as of Friday evening (persisting so far into Sat morning) - when downloading, latency spikes up hard for the whole connection and cripples pretty much everything.
I noticed this earlier while a youtube video was buffering. Pings went from around 20-30ms to 700-900ms. The web became unresponsive. I started sounding slightly robotic on teamspeak. At the time, I thought it was an ISP fault and just put up with it, as it eventually returned to normal about 25 minutes later.
Turns out that's when the video buffering had finished and i hadn't noticed at the time. Just went to view another video and everything went to hell again. Rebooted both the FTTC modem and router, managed to get 30mbit on the BT wholesale speedtest, but then it tanked again as soon as I went to youtube. Did another BT speedtest and got 3mb down, 4mb up, so something really weird is happening.
Anyone else suffering a massive degradation in service while downloading? Might as well see if this is an isolated incident or not over the weekend to assist in any fault finding with plusnet.

[#2]

I appear to get something similar between 8 & 9.30 PM.

[#3]

update 17:32
Everything just magically resolved itself while I was collecting the BT speedtest data for the plusnet fault checker system! Currently downloading at 35mbit with 30ms pings ..
.. 2 minutes later, it's slowed to 3mbit and latency is jumping around between 50-80ms.
-----
To confirm, this is affecting any device attached to Plusnet - pc, mac, phone - whether wired or wireless.
As soon as I start downloading something, download speed hovers around 2mbit and ping goes through the roof.
Here's what happens if I do a speedtest:

And here's what happens to pings (pinging google DNS) while the speedtest is running. The highest latency is during the download, with the usual slight increase when the upload is being tested.

I've tried rebooting the router + modem twice so far, no joy resolving, so I'll go create a support ticket as I dunno what else to test / try.

[#4]

ouch that's nasty.

a point to note is don't reboot the bt modem to often as it causes your lines's ip profile to get capped at a lower speed until its been stable for a week (god knows why it takes so long)
also as with anything check your routers syslog to see what MTU you are using, and also check your pc's mtu setting, the router and pc should by default be at 1500, sometimes they get messed up, the router will adjust its mtu setting based on the connection and tell the pc to change its mtu to match but if something has caused them to become mismatched it can cause major faults like this (I did it on purpose on one pc as a test, and with google services it hits really hard)

[#5]

thanks for the heads-up about the line profiling possibly changing - I've done two router resets now which didn't appear to fix the issue so I won't plan on doing anymore unless Plusnet need me to, to help with their testing
Check MTU's and its set to 1500 on the localnetwork side of the TG582n, and 1500 on both the PC and mac, so looks good there. The TG582n has an mtu of 1492 on the internet/wan side, not sure if that also needs to be 1500 but I haven't touched the router config in weeks now so I have to assume this is fine.
I remembered  that I had some ping monitoring set up on thinkbroadband so here's two pictures from yesterday and today - not sure why its had a problem pinging me today (I can ping my IP from an external server) but I've restarted the monitor so hopefully it'll work a bit better.
20th Sep:

21st Sep:

[#6]

you could change the mtu on the pc/mac to 1492 then and set it as persistent (and the lan of the router if you can)
make sure to leave the modem alone
reboot the pc/mac and router (dont forget to manually release the ppp conection on the router first)
and try again once its all back up and running.
if your line gets profile capped because of the modem re-syncs a quick conection restart after 24 hours will fix it (on the router connection page drop then connect no restarting)

let us know if the mtu tweak fixes the problem

[#7]

No joy with changing mtu - same issue still persists. Have reset back to 1500 for now.

[#8]

I am having the same issues. It can take about 30 seconds for pages to load. Trace route shows lots of time out and ping show dropped packets. I have connected 2 pc's wired to the router and then directly to the modem and have the same problems so at least I know it is not my equipment.
BT speedtest is showing correct results but any browsing is crippled
My stats are pre in the post titled constipated broadband.

Anyone from PN able to assist.
considering calling support but that'll need to wait. Until later.
podman

[#9]

Quote

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation.  All rights reserved. C:\Users\Main>tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:   1    <1 ms    <1 ms    <1 ms  192.168.1.254   2    23 ms    23 ms    22 ms  lo0-central10.pcl-ag04.plus.net [195.166.128.185 ]   3    22 ms    22 ms    22 ms  link-a-central10.pcl-gw01.plus.net [212.159.2.17 2]   4    22 ms    22 ms    22 ms  204.core.access.plus.net [212.159.0.204]   5    22 ms    22 ms    22 ms  ae2.pcl-cr02.plus.net [195.166.129.7]   6    23 ms    22 ms    23 ms  ae1.ptw-cr02.plus.net [195.166.129.2]   7    22 ms    22 ms    22 ms  72.14.223.32   8    23 ms    22 ms    23 ms  209.85.252.186   9    24 ms    23 ms    23 ms  209.85.253.94 10    42 ms    28 ms    28 ms  209.85.243.33 11    30 ms    30 ms    31 ms  209.85.244.102 12    32 ms    33 ms    32 ms  209.85.252.83 13    *        *        *    Request timed out. 14    32 ms    32 ms    32 ms  google-public-dns-a.google.com [8.8.8.8] Trace complete. C:\Users\Main>ping -t 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=33ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=33ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46 Reply from 8.8.8.8: bytes=32 time=32ms TTL=46

for reference that's the results I get using Google's DNS server which I randomly picked as its the one you used above
however I am not getting t he same problems you seem to be having re webpages

[#10]

deleted .
posted stats under wrong thread.

[#11]

the time out hops can be caused by several things, peers being unable to respond to the number of pings there receiving is one of those, another can be the peer point being configured to not respond to pings.
so whilst they can indicate a faulty switch or peer point they can also just be red herring's....the problem is that as the routing structure changes so quickly it can be impossible to pinpoint a bad node unless it is a common endpoint for everyone trying to access a data centre (like a data centre gateway)
here is a list of my results for comparison to your own

Quote

C:\Users\Main>tracert www.bbc.co.uk Tracing route to www.bbc.net.uk [212.58.244.68] over a maximum of 30 hops:   1    <1 ms    <1 ms    <1 ms  192.168.1.254   2    35 ms    24 ms    22 ms  lo0-central10.pcl-ag04.plus.net [195.166.128.185 ]   3    22 ms    23 ms    22 ms  link-a-central10.pcl-gw01.plus.net [212.159.2.17 2]   4    22 ms    58 ms    22 ms  204.core.access.plus.net [212.159.0.204]   5    23 ms    24 ms    25 ms  ae1.ptw-cr01.plus.net [195.166.129.0]   6    23 ms    22 ms    22 ms  kingston-gw.thdo.bbc.co.uk [212.58.239.6]   7    *        *        *    Request timed out.   8    *        *        *    Request timed out.   9    23 ms    22 ms    23 ms  ae0.er01.telhc.bbc.co.uk [132.185.254.109] 10    25 ms    23 ms    26 ms  132.185.255.149 11    23 ms    22 ms    23 ms  bbc-vip113.telhc.bbc.co.uk [212.58.244.68] Trace complete. C:\Users\Main>ping www.bbc.co.uk Pinging www.bbc.net.uk [212.58.244.68] with 32 bytes of data: Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=24ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Ping statistics for 212.58.244.68:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 23ms, Maximum = 24ms, Average = 23ms C:\Users\Main>ping -t www.bbc.co.uk Pinging www.bbc.net.uk [212.58.244.68] with 32 bytes of data: Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=24ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=22ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54 Reply from 212.58.244.68: bytes=32 time=23ms TTL=54

[#12]

Thanks nanotm.
I guess it's frustrating in that pretty much all my browsing is so slow not just one or two sites.
Came on here hoping to find a common problem to save going through PN support asking me to reboot etc.
Will give it until tomorrow and then phone if problems still persist.
Podman

[#13]

Update, Sunday, 3pm onwards: so far everything seems to be 'back to normal'
Do any of the symptoms look like network congestion? It seems quite terminal if that's the case, losing around 10x total bandwidth. Will post further updates if anything else occurs.

[#14]

it might be indicating a problem with networking but I have no idea what is the route cause, it could be down to so many things, something nefarious like hacking (ddos syn flood etc) or something mundane like a faulty switch or a slow dns server update path.... or something simpler to find and fix
who knows theres a growing number of similar problems being reported on forums across the internet so whatever it is I don't think its limited to plusnet, it might be related to certain area's though and certainly things to appear to fluctuate wildly from one area to another....