How is latency tonight?

Looking at BQM's it looks better, the pattern is much more like localised congestion with some VM areas actually looking pretty good now.

The general problem people had seems to be gone tonight, unless its just late. Everyone is waiting until just after 9pm before they say its ok now

My problems are just as bad, but probably a local problem:

S:\>tracert pingbox1.thinkbroadband.com

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

1 26 ms 10 ms 28 ms 10.89.184.1
2 25 ms 26 ms 10 ms croy-core-1a-ge339.network.virginmedia.net [81.96.224.213]
3 13 ms 14 ms 17 ms croy-core-2a-ae2-0.network.virginmedia.net [195.182.178.82]
4 22 ms 9 ms 13 ms brnt-bb-1a-ae9-0.network.virginmedia.net [81.96.226.1]
5 7 ms 7 ms 8 ms brnt-bb-1b-ae0-0.network.virginmedia.net [213.105.174.226]
6 * 23 ms 12 ms brnt-tmr-1-ae5-0.network.virginmedia.net [213.105.159.50]
7 14 ms 15 ms 14 ms telc-ic-1-as0-0.network.virginmedia.net [62.253.185.74]
8 18 ms 26 ms 23 ms linx-gw2.thdo.ncuk.net [195.66.236.240]
9 19 ms 26 ms 18 ms gi0-24-10-star1.core-rs2.thdo.ncuk.net [80.249.97.9]
10 16 ms 17 ms 14 ms pingbox1.thinkbroadband.com [80.249.99.164]

Trace complete.

S:\>tracert bbc.co.uk

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

1 8 ms 10 ms 8 ms 10.89.184.1
2 14 ms 23 ms 17 ms croy-core-1a-ge339.network.virginmedia.net [81.96.224.213]
3 12 ms 23 ms 22 ms croy-core-2a-ae2-0.network.virginmedia.net [195.182.178.82]
4 14 ms 11 ms 13 ms brnt-bb-1a-ae9-0.network.virginmedia.net [81.96.226.1]
5 14 ms 14 ms 17 ms glfd-bb-1b-as1-0.network.virginmedia.net [212.43.163.105]
6 17 ms 33 ms 17 ms glfd-tmr-1-ae5-0.network.virginmedia.net [213.105.159.46] 7 * 29 ms 13 ms tcl5-ic-1-as0-0.network.virginmedia.net [62.253.185.78]
8 15 ms 20 ms 16 ms 212.58.239.249
9 * * * Request timed out.
10 16 ms 17 ms 17 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
11 27 ms 24 ms 30 ms 132.185.255.60
12 22 ms 15 ms 23 ms 212.58.241.131

Trace complete.

Edited by deleted (Mon 15-Oct-12 20:59:18)

VM posted this up on their board...
http://community.virginmedia.com/t5/Up-to-100Mb-Spee...

F002199132 - Hi we've identified an issue with our peering links to a company called Atrato who we publically peer with in Amsterdam and London. They were pushing abnormal amounts of traffic through our public peering links at LINX, overloading them. So we've shut down both of our peering links to Atrato at LINX which should resolve this issue. Meanwhile we're going to continue to investigate the root cause of this problem. Could you please continue to give us feedback on this so we can be sure the issue is resolved.

Considering this issue has been happening for at least a week and probably more it seems that VM's network monotoring must be pretty much non-existent.

In reply to a post by kwikbreaks:

Considering this issue has been happening for at least a week and probably more it seems that VM's network monotoring must be pretty much non-existent.

On the up side at least not some misfiring traffic management as you were convinced earlier

In reply to a post by MrSaffron:

Looking at BQM's it looks better, the pattern is much more like localised congestion with some VM areas actually looking pretty good now.

Something that is perhaps concerning more globally is that according to the LINX public lists BT have 24 x 10Gb and 1 x 100Gb interfaces to the London LINX LANs, VM have a total of 11 x 10Gb into them.

Speaking with a couple of different content providers they've more private peering to BT than VM, so it's debatable whether or not VM have lots of private peering taking the slack.

Maybe VM have tons of transit or loads of peering points elsewhere. Seems an anomaly that they've 50% less peering capacity than Talk Talk, 1/3rd the capacity of BT and just over 1/2 the capacity of Sky though.

My connection is back to 'remarkably good for VM' now.

They say they've cut a peering link to Atrato to resolve the issue, is this likely to cause other, different problems?

In reply to a post by Ignitionnet:

On the up side at least not some misfiring traffic management as you were convinced earlier

I'm not sure that's an upside as VM certainly need some traffic management that actually works if they intend to persist with their "unlimited" myth - of course more resource would help too.

I'm still surprised at how the sudden onset and cutoff could be caused by simple congestion on a peering link. Of course as we know VM do like to run their links hot so possibly just a little extra loading was enough.

Simply shutting the link down can't be a solution though as it will just cause their other peering links to run even hotter.

In reply to a post by Daemon66:

My connection is back to 'remarkably good for VM' now.

They say they've cut a peering link to Atrato to resolve the issue, is this likely to cause other, different problems?

Yes - extra traffic on the remaining links.

In reply to a post by kwikbreaks:

I'm still surprised at how the sudden onset and cutoff could be caused by simple congestion on a peering link. Of course as we know VM do like to run their links hot so possibly just a little extra loading was enough.

Simply shutting the link down can't be a solution though as it will just cause their other peering links to run even hotter.

That's exactly what congestion on Ethernet looks like. The link that was shut down was logical and will not affect VM's overall capacity. Traffic from this ISP will go via Amsterdam and the peering there if it was just London shut down else it'll go via IP transit.

In reply to a post by kwikbreaks:

In reply to a post by Daemon66:

My connection is back to 'remarkably good for VM' now.

They say they've cut a peering link to Atrato to resolve the issue, is this likely to cause other, different problems?

Yes - extra traffic on the remaining links.

No - overall capacity remains the same, traffic will have been moved to other links with capacity and won't affect the network as a whole.

No actual capacity was taken down.