50M Think Broadband Ping Monitor Results (POST YOURS) - Page 176

The Installer · 07-11-2012, 17:50

Quote:

Originally Posted by Qtx

Chrysalis, don't feed the tro...

Quote:

Originally Posted by Chrysalis

yeah sorry for the ranting will go back to just discussing graphs.

I find the ignore button works a treat

The bump is back here too.

Gateway

http://www.thinkbroadband.com/news/5...dia-again.html

qasdfdsaq · 07-11-2012, 18:03

Quote:

Originally Posted by roughbeast

I'm not yet convinced by your view on the sharpness of the onset. On my TBB graph there was a normal profile until something like 7.50 pm. By 8.15 pm the blip was at its peak. Admittedly the decline at the other end of the blip was virtually instant, but I would have expected a much more gradual onset if collective human behaviour is the only cause. ie thousands of users caning their connections soon after they get home from work somewhere around 6.00 pm.

I've said so before, and iggi's said it on TBB. That's not how it works. Read this post:

http://forums.thinkbroadband.com/vir...y-tonight.html

For the lazy, this is what "natural" congestion saturating a link normally looks like:

On O2's core network

On VM's core network

On VM's edge/border (the last "Altroto" incident):

This is an example Thinkbroadband posted on their own FAQ page as "A classic example of peak time [congestion] affecting latency, and suggests the provider in question is running its links at very close to capacity"

Another example from Thinkbroadband's own FAQ, this time "what effect a heavily congested link from an exchange to the wider internet can have" (in this case Sky):

In comparison to your graph:
[img]Download Failed (1)[/img]

roughbeast · 07-11-2012, 19:32

OK qasdfdsaq, you have started to convince me. So, if this is a typical congestion profile let me deduce why we have such an acute onset and decline. (Lay person's language only)

As congestion increases systems can, up to a certain threshold, maintain acceptably low latency, but beyond that point things have to give, or are allowed to give, and the flood gates open. Similarly as congestion reduces systems can just as rapidly restore acceptable levels.

Given that congestion inevitably builds up and reduces gradually, this is the only explanation I can think of. Or, is there perhaps some attribute of the TBB connection to VM or of their latency measuring method that makes the profile look so abrupt?

BTW. I am lazy, but I did follow your link.

It's almost blip time, so I'm off check.

Edit.............................................. ..............................................

Here we go. Here comes the blip.

[img]Download Failed (1)[/img]

Tracing route to bbc.co.uk [212.58.241.131]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms REDDWARF [192.168.1.1]
2 7 ms 5 ms 5 ms 10.14.112.1
3 7 ms 9 ms 7 ms brhm-core-2b-ae3-1179.network.virginmedia.net [2
13.106.229.225]
4 8 ms 7 ms 7 ms brhm-bb-1b-ae8-0.network.virginmedia.net [62.253
.174.77]
5 8 ms 7 ms 7 ms brhm-bb-1a-ae0-0.network.virginmedia.net [62.253
.185.153]
6 116 ms 14 ms 13 ms nrth-bb-1b-ae2-0.network.virginmedia.net [62.253
.185.85]
7 15 ms 14 ms 15 ms tele-ic-4-ae0-0.network.virginmedia.net [62.253.
174.18]
8 32 ms 14 ms 15 ms pos6-1.rt0.thdo.bbc.co.uk [212.58.239.237]
9 * * * Request timed out.
10 15 ms 17 ms 17 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
11 17 ms 16 ms 17 ms 132.185.255.60
12 18 ms 15 ms 37 ms 212.58.241.131

Trace complete.

Tracing route to thinkbroadband.com [80.249.99.130]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms REDDWARF [192.168.1.1]
2 6 ms 5 ms 5 ms 10.14.112.1
3 7 ms 8 ms 12 ms brhm-core-2b-ae3-1180.network.virginmedia.net [2
13.106.229.229]
4 8 ms 9 ms 7 ms brhm-bb-1b-ae8-0.network.virginmedia.net [62.253
.174.77]
5 9 ms 11 ms 8 ms nrth-bb-1a-as4-0.network.virginmedia.net [62.253
.185.105]
6 10 ms 11 ms 11 ms nrth-bb-1b-ae0-0.network.virginmedia.net [62.253
.185.118]
7 13 ms 13 ms 13 ms tele-ic-4-ae0-0.network.virginmedia.net [62.253.
174.18]
8 13 ms 13 ms 13 ms linx-gw1.thn.ncuk.net [195.66.224.240]
9 15 ms 13 ms 14 ms gi0-24-10-star1.core-rs2.thdo.ncuk.net [80.249.9
7.9]
10 98 ms 92 ms 95 ms www.thinkbroadband.com [80.249.99.130]

Trace complete.

qasdfdsaq · 07-11-2012, 20:00

Quote:

Originally Posted by roughbeast

As congestion increases systems can, up to a certain threshold, maintain acceptably low latency, but beyond that point things have to give, or are allowed to give, and the flood gates open. Similarly as congestion reduces systems can just as rapidly restore acceptable levels.

Pretty much, yes. As Chrysalis pointed out earlier (though it wasn't entirely relevant at the time), fat pipes tend to not show any increase in latency until they are very close to full, you may gradually get up to 98%-99% utilization without any noticeable increase in latency. Core routers are so fast everything is forwarded at line speed, 999Mbps data comes in, 999Mbps data is immediately forwarded out the other end with no buffering or waiting. Once you hit 1001Mbps incoming traffic but an outgoing interface being a 1000Mbps line, that extra 1Mbps will cause buffering to start, hence the large increase in latency. The buffers are usually no more than a few megabytes so even 0.1% overutilization will fill them up in seconds.

Quote:

Given that congestion inevitably builds up and reduces gradually, this is the only explanation I can think of. Or, is there perhaps some attribute of the TBB connection to VM or of their latency measuring method that makes the profile look so abrupt?

Your explanation is basically right. Congestion builds up gradually, but buffering is basically zero until the link hits 100%.

---------- Post added at 20:00 ---------- Previous post was at 20:00 ----------

Quote:

Originally Posted by roughbeast

O

Here we go. Here comes the blip.

Now traceroute to TBB, as well as everything else under the sun.

roughbeast · 07-11-2012, 20:11

tracerts and everything else- DONE. See above.

thenry · 07-11-2012, 20:15

guess what?! its back...

Blairhoyle · 07-11-2012, 20:24

this my speed test with the bump again.

http://www.thinkbroadband.com/speedt...918215964.html

playing buggers with my youtube, IPlayer etc.

qasdfdsaq · 07-11-2012, 20:30

Quote:

Originally Posted by roughbeast

tracerts and everything else- DONE. See above.

Thanks. When you get a chance, could you also traceroute 141.0.208.1 and 94.143.104.1? P.S. Also

http://www.thinkbroadband.com/tools/traceroute.html

---------- Post added at 20:30 ---------- Previous post was at 20:29 ----------

Quote:

Originally Posted by Blairhoyle

playing buggers with my youtube, IPlayer etc.

No it isn't.

Blairhoyle · 07-11-2012, 20:35

Quote:

Originally Posted by qasdfdsaq

Thanks. When you get a chance, could you also traceroute 141.0.208.1 and 94.143.104.1?

---------- Post added at 20:30 ---------- Previous post was at 20:29 ----------

No it isn't.

can assure it is.

currently trying to watch the football on another site and its buffering and jumping like crazy.

Sirius · 07-11-2012, 20:37

This is getting beyond a joke now. Will someone please pull there finger out and sodding fix this

qasdfdsaq · 07-11-2012, 20:38

Quote:

Originally Posted by Blairhoyle

can assure it is.

currently trying to watch the football on another site and its buffering and jumping like crazy.

Can assure you it isn't. You clearly haven't been paying attention. Your connection problems have nothing to do with this ping spike.

roughbeast has already shown traffic to/from BBC's network is not affected. It doesn't even go over the same network. Many others have already shown VM hosts Youtube inside their own network, nowhere near the location this problem is occurring.

Chrysalis · 07-11-2012, 20:39

1 <1 ms <1 ms <1 ms home.gateway2 [192.168.1.1]
2 21 ms 23 ms 17 ms cpc14-leic14-2-0-gw.8-1.cable.virginmedia.com [8
2.30.112.1]
3 14 ms 73 ms 20 ms leic-core-2a-ae6-649.network.virginmedia.net [82
.3.35.73]
4 26 ms 45 ms 31 ms leed-bb-1c-ae5-0.network.virginmedia.net [62.253
.174.113]
5 17 ms 10 ms 17 ms leed-bb-1a-ae10-0.network.virginmedia.net [62.25
3.174.21]
6 35 ms 23 ms 18 ms brnt-bb-1b-as2-0.network.virginmedia.net [213.10
5.175.26]
7 28 ms 25 ms 24 ms brnt-tmr-1-ae5-0.network.virginmedia.net [213.10
5.159.50]
8 62 ms 27 ms 20 ms telc-ic-1-as0-0.network.virginmedia.net [62.253.
185.74]
9 21 ms 13 ms 24 ms linx-gw2.thdo.ncuk.net [195.66.236.240]
10 20 ms 16 ms 15 ms gi0-0-10-star1.bdr-rt1.rbsov.ncuk.net [80.249.97
.3]
11 112 ms 107 ms 117 ms gw1.dotmailer.com [94.143.104.1]

1 <1 ms <1 ms <1 ms home.gateway2 [192.168.1.1]
2 17 ms 15 ms 13 ms cpc14-leic14-2-0-gw.8-1.cable.virginmedia.com [8
2.30.112.1]
3 19 ms 15 ms 25 ms leic-core-2a-ae6-649.network.virginmedia.net [82
.3.35.73]
4 27 ms 22 ms 14 ms leed-bb-1c-ae5-0.network.virginmedia.net [62.253
.174.113]
5 28 ms 13 ms 47 ms leed-bb-1a-ae10-0.network.virginmedia.net [62.25
3.174.21]
6 26 ms 51 ms 36 ms brnt-bb-1b-as2-0.network.virginmedia.net [213.10
5.175.26]
7 31 ms 26 ms 27 ms brnt-tmr-1-ae5-0.network.virginmedia.net [213.10
5.159.50]
8 45 ms 37 ms 27 ms telc-ic-1-as0-0.network.virginmedia.net [62.253.
185.74]
9 21 ms 18 ms 12 ms linx-gw2.thdo.ncuk.net [195.66.236.240]
10 106 ms 111 ms 120 ms ip208-1.thdo.ncuk.net [141.0.208.1]

here is one to tesco, seems different unrelated issue (site a mess again).

1 <1 ms <1 ms <1 ms home.gateway2 [192.168.1.1]
2 13 ms 15 ms 12 ms cpc14-leic14-2-0-gw.8-1.cable.virginmedia.com [8
2.30.112.1]
3 13 ms 18 ms 18 ms leic-core-2a-ae6-649.network.virginmedia.net [82
.3.35.73]
4 38 ms 35 ms 41 ms leed-bb-1c-ae5-0.network.virginmedia.net [62.253
.174.113]
5 39 ms 34 ms 31 ms nrth-bb-1c-ae9-0.network.virginmedia.net [62.253
.174.122]
6 28 ms 29 ms 34 ms popl-bb-1c-ae7-0.network.virginmedia.net [62.253
.174.138]
7 * * * Request timed out.
8 37 ms * * 195.99.125.113
9 36 ms 44 ms 34 ms core2-te-0-15-0-6.ilford.ukcore.bt.net [109.159.
254.61]
10 * 52 ms * 62.172.103.61
11 49 ms 43 ms 19 ms vhsaccess1-pos8-0.kingston.fixed.bt.net [194.72.
3.238]
12 34 ms * * ftip003172445-ms-lb.vhsaccess1.kingston.fixed-nt
e.bt.net [62.172.57.158]
13 * 38 ms * 212.140.185.12
14 * * * Request timed out.

finally since speedtests are affected I traced namesco.co.uk and it has the spike.

1 <1 ms <1 ms <1 ms home.gateway2 [192.168.1.1]
2 36 ms 24 ms 24 ms cpc14-leic14-2-0-gw.8-1.cable.virginmedia.com [8
2.30.112.1]
3 69 ms 6 ms 16 ms leic-core-2b-ae6-749.network.virginmedia.net [82
.3.35.109]
4 14 ms 20 ms 11 ms nrth-bb-1c-ae5-0.network.virginmedia.net [62.253
.174.117]
5 17 ms 13 ms 37 ms nrth-bb-1b-ae11-0.network.virginmedia.net [62.25
3.174.109]
6 23 ms 24 ms 39 ms tele-ic-4-ae0-0.network.virginmedia.net [62.253.
174.18]
7 21 ms 30 ms 19 ms the-linx.as29550.net [195.66.224.223]
8 128 ms 234 ms 186 ms the3-po1.namesco.net [213.229.105.110]
9 114 ms 115 ms 115 ms lb1.namesco.net [85.233.160.70]

babis3g · 07-11-2012, 20:41

and speeds down to 33mb

Blairhoyle · 07-11-2012, 20:44

Quote:

Originally Posted by qasdfdsaq

Can assure you it isn't. You clearly haven't been paying attention. Your connection problems have nothing to do with this ping spike.

roughbeast has already shown traffic to/from BBC's network is not affected. It doesn't even go over the same network. Many others have already shown VM hosts Youtube inside their own network, nowhere near the location this problem is occurring.

so its the site itself then?

Chrysalis · 07-11-2012, 20:44

see this also report 100+ms latency.

and maidenhead (bont know ip tho so cant trace)

and birmingham

coventry also

tracert to the website of the company who runs the coventry test.

1 <1 ms <1 ms <1 ms home.gateway2 [192.168.1.1]
2 48 ms 13 ms 26 ms cpc14-leic14-2-0-gw.8-1.cable.virginmedia.com [8
2.30.112.1]
3 13 ms 25 ms 10 ms leic-core-2b-ae6-749.network.virginmedia.net [82
.3.35.109]
4 20 ms 24 ms 35 ms nrth-bb-1c-ae5-0.network.virginmedia.net [62.253
.174.117]
5 38 ms 19 ms 7 ms nrth-bb-1b-ae11-0.network.virginmedia.net [62.25
3.174.109]
6 29 ms 33 ms 22 ms tele-ic-4-ae0-0.network.virginmedia.net [62.253.
174.18]
7 15 ms 22 ms 30 ms ge1.the-bgp1.warwick.net.uk [195.66.224.113]
8 17 ms 25 ms 29 ms gi0-283.np-bgp1.warwick.net.uk [94.125.133.174]

9 114 ms 114 ms 161 ms 94.125.135.18

when last hop only shows jump it usually means return path is affected, so the return path is needed to diagnose the issue.