Very poor and erratic ping times

[#1]

Hi dompedro,
I think the only option we have moving forward is to press on with the faults team and refer this back to BT again for further diagnostics. Intermittent latency issues such as this can be notoriously difficult to diagnose once the usual hiding places have been checked.
Given how far along the faults process is now I would expect that there would be few places left for the supplier to investigate and we should hopefully see the cause of the issue identified.

[#2]

Adam, do you have any way to find out if you have any other PN customers using the same exchange as me?
On the TBB ping graphs page (http://community.plus.net/ping-graphs/) there is one other graph that looks similar to mine.  Is there anyway for you to contact that user or find out more about their symptoms?

[#3]

my viewpoint is I dont think its the line, the error rates look reasonably low, so it looks like either the router or some congestion somewhere.  I would be surprised if its the line.  If there was retransmits causing that kind of latency your error rate would be extremely high and I would expect packet loss from errors rather than high latency.
There is also the chance of course someone is maxing out the connection as well.

[#4]

Chroluk,
Given that latency is a measure of round trip transmission, packet loss due to errors would inflate latency figures.
Something maxing out uploads (file sharing etc) might indeed cause these results, as typically pings which are used to measure latency are considered low priority and can be dropped on a busy link.
Martyn,
I had thought of doing some more fiddling with router stats but thought you had enough on your hands... however, given where we are...
If you scan through the RouterStats settings, there is a tick box for "show ping tab" - can you please find it and enable it, then save the settings.  Then on the Ping tab can you put plus.net in there.
We then need to examine that along side the TBB graph and see if there is latency both ways round.
Kevin

[#5]

Hi Kevin,
I think the ping tests and trace routes I've run suggest that the problem is there both ways around and I'm running the ping tests from Router Stats right now and they are all over the place.  The majority are 20 to 30ms, but there are spikes over 200 and 300ms which seems consistent with the tracert testing that I do (there are a few lost packets but not that many really).
There is nothing running file sharing on my LAN.  I don't have any torrent clients installed on any of the local machines.
Martyn.

[#6]

Martyn,
As much as possible has been done to profile this issue now.  Please keep RS running, keep an eye on SNRM variations to see if there is any evidence of REIN.
It is now as Adam suggests back to BTw / BTOR to investigate their back end systems.
Sorry I can do no more to help here.
Kevin

[#7]

Thanks for all your help anyway Kevin (and thanks to anyone trying to help).  Wifi was disabled overnight with no ethernet connections and the ping graph this morning should rule out any kind of file sharing or anything else on my LAN.

[#8]

Martyn,
Can you please provide a snapshot link to the current (not live) TBB graph please?

[#9]

Sure, this is the last 24 hours graph (not live): TBBPing from 20141002
The wifi was disabled at midnight and re-enabled at 7am.

[#10]

That really is the pits!

[#11]

Quote from: Townman

Chroluk, Given that latency is a measure of round trip transmission, packet loss due to errors would inflate latency figures. Something maxing out uploads (file sharing etc) might indeed cause these results, as typically pings which are used to measure latency are considered low priority and can be dropped on a busy link. Martyn, I had thought of doing some more fiddling with router stats but thought you had enough on your hands... however, given where we are... If you scan through the RouterStats settings, there is a tick box for "show ping tab" - can you please find it and enable it, then save the settings.  Then on the Ping tab can you put plus.net in there. We then need to examine that along side the TBB graph and see if there is latency both ways round. Kevin

Maybe, but his error rates are nowhere near high enough.

[#12]

@dompedro - I can't remember from memory, but have we ever tried getting you a Lift and Shift to try and resolve this problem?
I can't imagine this being caused by anything on our side of the network but it has to be something quite obscure, perhaps the port you even line card you're connected to?

[#13]

Hi Chris, no there hasn't been a lift and shift suggested yet?  What does that involve and how long might it take?  It sounds a lot more positive than the current direction of the support ticket where the engineers seem to be focusing on a "too low" SNRM even though it's only been that low since the last BTO engineers visit last week.
A techie on another forum has asked if PN have an option to put my broadband on a different pipe/virtual path back to the exchange.  Is that an option?  This is a recent tracert:
03/10/2014 -  7:57:19.97
Tracing route to uwsp-webdev1.warwicknet.com [94.125.132.15] over a maximum of 30 hops:
  1    1 ms    <1 ms    1 ms  home.gateway.home.gateway [192.168.1.254]
  2  324 ms  102 ms    20 ms  lo0.10.central10.pcl-bng02.plus.net [195.166.130.151]
  3  450 ms  204 ms  204 ms  irb.10.pcl-cr01.plus.net [84.93.249.81]
  4    25 ms    17 ms    25 ms  ae1.ptw-cr01.plus.net [195.166.129.0]
  5  267 ms    25 ms    25 ms  gi3-5.the-scr1.warwick.net.uk [195.66.224.113]
  6  148 ms    26 ms    28 ms  gi2-1-252.uwsp-scr1.warwick.net.uk [94.125.133.209]
  7    34 ms  117 ms  252 ms  uwsp-webdev1.warwicknet.com [94.125.132.15]

[#14]

That is an option, to put you on a different VLAN, but a Lift and Shift is BT OR removing your connection from the port it's connected to and reconnecting it again, it resolves a high number of issues, or potentially, even putting your connection into a different port entirely.
It makes sense to me that we look at this as a possibility. Feel free to add this to your ticket.

[#15]

Martyn,
A VP switch would only be of use if the exchange was showing congestion on your VP.  Based on information examined by Adam, there is no congestion at your exchange or a "parent" exchange.
If the line has a high level of errors a SNRM up shift might help - I've not seen evidence of high errors.

Chris,
Lift n shift sounds like a possible way forward, though that would imply errors on the line card.
Kevin