50M : Think Broadband Ping Monitor Results (POST YOURS)

[Sephiroth]

Originally Posted by roughbeast

Definitely Coventry. It all gets routed through Birmingham after that.


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 7 ms 7 ms 10.14.112.1
3 8 ms 7 ms 7 ms brhm-core-2b-ae3-938.network.virginmedia.net [21
3.106.230.157]
4 39 ms 8 ms 7 ms brhm-bb-1b-ae8-0.network.virginmedia.net [62.253
.174.77]
5 12 ms 132 ms 35 ms nrth-bb-1a-as4-0.network.virginmedia.net [62.253
.185.105]
6 18 ms 13 ms 13 ms nrth-bb-1b-ae0-0.network.virginmedia.net [62.253
.185.118]
7 16 ms 15 ms 15 ms tele-ic-4-ae0-0.network.virginmedia.net [62.253.
174.18]
8 15 ms 15 ms 15 ms pos6-1.rt0.thdo.bbc.co.uk [212.58.239.237]
9 * * * Request timed out.
10 15 ms 14 ms 16 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
11 17 ms 15 ms 15 ms 132.185.255.134
12 14 ms 15 ms 15 ms 212.58.241.131

Trace complete.







All tests done within a 10 minute slot.

Looking at the two humps in the TBB graph and your traceroute - if the traceroute was taken while that was happening, and if there was congestionin the VM network (one of the possible causes), then all of the traces in that traceroute would have shown the same cdelay at and after a certain point in the list.

If the traceroute was not taken during the middle of that, there's nothing we can glean from it.

---------- Post added at 12:08 ---------- Previous post was at 11:57 ----------

Originally Posted by qasdfdsaq

It isn't the core network. It's a few edge nodes. It's been showing up in Scotland since at least Feb 26th.

Both Roughbeast and Maverick's base latency makes it look like they're up north somewhere, in fact pretty much as far north as VM's network goes. Even though RB's profile says he's in Coventry.


And later you posted :

VM seem to have some very slow routes for some reason. Edinburgh to Manchester is a ~250 mile path, and takes only 5ms. Birmingham to London is about 100 miles but taking 8ms for you. Manchester to London, which is about twice as far, only takes 6-7ms for me.

(Incidentally VM also have a very slow route to Amsterdam)

Despite having over four times as far for my data to go, it only takes 15% longer (18ms) to reach London from Edinburgh than it does for you. My TBB monitor actually has the same minimum ping as yours, despite being 4 times further away as well, which is really odd.

.....?

So they're not in the furthest northern regions. I think Qasi is approaching this from the wrong angle. a 15% difference in transit times doesn't account for the minimum latency humps we're seeing.

It's one (or all) of three things:

1. LAN related issues

2. TBB glitching like it did earlier

3. Some issue in the Core as stuiff queues due to routing issues or whatever

Any traceroutes must be done during the peiod of the humps in order for there to be any deduction made, and, as Craigie has suggested, it should be back to the TBB site.

I wish this was Simples, because these are buggers to determine.

[qasdfdsaq]

Originally Posted by Sephiroth

So they're not in the furthest northern regions.

No, but their latency looks like they should be, if it takes longer for data to go from London to Birmingham than London to Edinburgh, something is wrong with the route it's taking. His base ping should be around the 10ms mark, not the 16-18 it's showing on the chart.

I think Qasi is approaching this from the wrong angle. a 15% difference in transit times doesn't account for the minimum latency humps we're seeing.

The 15% was an illustration of my speed vs. theirs, it has nothing to do with the humps RB is seeing.

Their latency (or rather the latency during the traceroute) shows either the route is very slow or alternatively taking a bad route - e.g. going Birmingham => Manchester => London. Route flapping between direct and indirect routes like that could explain the humps, but so could congestion. Or even the latter causing the former.

I think the problem is, well, there's two problems which are impossible to isolate from each other.

It's one (or all) of three things:

1. LAN related issues

Since it affects nodes within VM's carrier network then it can't be purely a LAN issue

2. TBB glitching like it did earlier

If that were the case you'd expect it to affect many/every route/destination along certain paths. It doesn't

3. Some issue in the Core as stuiff queues due to routing issues or whatever

Most likely explanation.

and, as Craigie has suggested, it should be back to the TBB site.

Indeed - pingbox1.thinkbroadband.com

[Sephiroth]

Originally Posted by qasdfdsaq

No, but their latency looks like they should be, if it takes longer for data to go from London to Birmingham than London to Edinburgh, something is wrong with the route it's taking. His base ping should be around the 10ms mark, not the 16-18 it's showing on the chart.

SEPH: I don't know how you get to the "base poing" being 10 ms. What does "base ping" mean?

I traced to Namesco's BBMAX speedtest site:

Tracing route to speedtest.bbmax.co.uk [85.233.160.167] over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 192.168.1.1
2 18 ms 33 ms 24 ms 10.159.48.1
3 9 ms 35 ms 39 ms winn-core-1a-ae1-955.network.virginmedia.net [62.253.121.77]
4 11 ms 27 ms 24 ms winn-bb-1a-so-130-0.network.virginmedia.net [62.253.184.113]
5 18 ms 20 ms 65 ms popl-bb-1b-as5-0.network.virginmedia.net [212.43.162.194]
6 34 ms 10 ms 11 ms tele-ic-5-ae0-0.network.virginmedia.net [213.105.159.117]
7 10 ms 18 ms 27 ms linx-gw2.plus.net [195.66.236.164]
8 43 ms 20 ms 19 ms po4.ptn-gw01.plus.net [212.159.1.138]
9 33 ms 39 ms 15 ms ptw3-gi2-3.namesco.net [212.159.1.66]
10 23 ms 16 ms 16 ms gonzales.namesco.net [85.233.160.167]

No strange routing but the lowest ping time to the destination was 16 ms. The North of the UK stuff was a comlete red herring.


The 15% was an illustration of my speed vs. theirs, it has nothing to do with the humps RB is seeing.
SEPH: Aren't we trying to explain the humps? They were even larger in earlier posts. The context in which I mentioned the Core was the humps and your response was also in that context.


Their latency (or rather the latency during the traceroute) shows either the route is very slow or alternatively taking a bad route - e.g. going Birmingham => Manchester => London. Route flapping between direct and indirect routes like that could explain the humps, but so could congestion. Or even the latter causing the former.
SEPH: So we are considering the humps. Route flapping is a plausible explanation because it builds queues in various places.


I think the problem is, well, there's two problems which are impossible to isolate from each other.

Since it affects nodes within VM's carrier network then it can't be purely a LAN issue

If that were the case you'd expect it to affect many/every route/destination along certain paths. It doesn't

Most likely explanation.

Indeed - pingbox1.thinkbroadband.com

SEPH: In the generic sense, it would have to be one of the three I listed. I too didn't think LAN in the specific case. So now you think it's TBB? You didn't think so earlier. Or have I misunderstood you?

[crazyronnie]

[qasdfdsaq]

Originally Posted by Seph

SEPH: I don't know how you get to the "base poing" being 10 ms. What does "base ping" mean?

Minimum ping. The green line on his chart. London to Birmingham should take around 6ms, then to his cable modem from Birmingham, 4-5ms.

I traced to Namesco's BBMAX speedtest site:

Tracing route to speedtest.bbmax.co.uk [85.233.160.167] over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 192.168.1.1
2 18 ms 33 ms 24 ms 10.159.48.1
3 9 ms 35 ms 39 ms winn-core-1a-ae1-955.network.virginmedia.net [62.253.121.77]
4 11 ms 27 ms 24 ms winn-bb-1a-so-130-0.network.virginmedia.net [62.253.184.113]
5 18 ms 20 ms 65 ms popl-bb-1b-as5-0.network.virginmedia.net [212.43.162.194]
6 34 ms 10 ms 11 ms tele-ic-5-ae0-0.network.virginmedia.net [213.105.159.117]
7 10 ms 18 ms 27 ms linx-gw2.plus.net [195.66.236.164]
8 43 ms 20 ms 19 ms po4.ptn-gw01.plus.net [212.159.1.138]
9 33 ms 39 ms 15 ms ptw3-gi2-3.namesco.net [212.159.1.66]
10 23 ms 16 ms 16 ms gonzales.namesco.net [85.233.160.167]

No strange routing but the lowest ping time to the destination was 16 ms. The North of the UK stuff was a comlete red herring.

Not sure what you mean by that. Too much jitter on your trace to get anything meaningful, and you're tracing to a different server. Looks like your hop to Winnersh core is taking ~9-10ms when it should be taking 4-5, and from Winnersh to London is 1ms which is about right. Birmingham to London should be about 5-6ms, but RB's is taking 8+ and his first hop is 7ms+ when it should be <5

SEPH: Aren't we trying to explain the humps? They were even larger in earlier posts. The context in which I mentioned the Core was the humps and your response was also in that context.

No, I was trying to explain why his base ping was so much higher than it should be. We already know the humps are localized pockets of congestion. That's the only plausible explanation.

SEPH: So we are considering the humps. Route flapping is a plausible explanation because it builds queues in various places.

It's not the queues that matter, it's the fact the data is taking a longer route to avoid a shorter, more congested one. But that would show up on a traceroute when done at the time of the humps.

SEPH: In the generic sense, it would have to be one of the three I listed. I too didn't think LAN in the specific case. So now you think it's TBB? You didn't think so earlier. Or have I misunderstood you?

I think I've said at least 3 times now it's NOT TBB.

[Sephiroth]

You said: "Most likely explanation.

Indeed - pingbox1.thinkbroadband.com"

Anyway, the humps are too large to be accounted for by the few ms you're arguing about.

I think your analysis of my traceroute was a load of mumbo jumbo; unusual for you, Qasi.

[qasdfdsaq]

No, I said " Indeed - pingbox1.thinkbroadband.com" which was in direct response to your statement " and, as Craigie has suggested, [traceroutes] should be back to the TBB site." which was clearly quoted above that line.

The statement "Most likely explanation" was in response to your statement "3. Some issue in the Core as stuiff queues due to routing issues or whatever", which was again, clearly quoted directly above that line.

i.e.:

Originally Posted by seph

3. Some issue in the Core as stuiff queues due to routing issues or whatever

[the above statement is the] Most likely explanation.

END STATEMENT HERE

---------- Post added at 16:46 ---------- Previous post was at 16:43 ----------

Originally Posted by Sephiroth

I think your analysis of my traceroute was a load of mumbo jumbo; unusual for you, Qasi.

Which part did you not understand?

[MaverickJesus]

Looks like it was a kickback from some routing changes - I had another 'step' in my minimum latency around 3pm this afternoon, back down to the original levels. The trace to pingbox now correctly goes straight to London, which would explain it.

Doesn't bode well for the network if its that close to breaking point...

[roughbeast]

I had no latency bumps last night, so was unable to run useful tracert or ping tests.

I wonder why it has all settled down for me. Has everybody else lost the mid-evening bump?

[qasdfdsaq]

I haven't seen it on Edinburgh core since the 16th.

[boroboi]

So... i switched to modem mode a couple of days ago after finally getting sick of the superhub's hardware issues. Modem mode is definately better with jitter, but i'm yet to see any improvement with FIFA, other games seem better.

I've still got my other graph on the TBB monitor, and it seems whoever has claimed my Superhub's IP address since it's been in modem mode is one hell of a bandwidth whore... it wouldn't surprise me if this fella was responsible for quite a lot of the spikes on the line, all he seems to do all day is torrent or upload at full capacity

Superhub



Superhub Modem Mode - You an see the clear reduction in minmum latency and average latency also.



Now this is the guy who has claimed my old IP address when in router mode. What an ********. I'd love to go and rip his box off his wall as he obviously has no respect for other people on his line what so ever... luckily, and wierdly, it doesn't seem to be affecting me since i went into modem mode... but when in router mode, i'd be susceptible to people who do this sort of stuff on a daily basis, most likely this bawbag.

[qasdfdsaq]

The only person on his line is him and if he's paying for a service why is it disrespectful to use it?

You seem to be under the impression the only person who should be using their internet connection is you and anyone else using what they pay for is a bawbag.

[boroboi]

You like to put words in people's mouths quite a bit, don't you?

However, no, i'm under the impression that heavy users can have a detrimental effect on other people's quality of service, and the fact that this guy clearly shows typical torrent use through most hours of daylight up until midnight (which can bee seen days previous too) he clearly has no respect for other people in his area, which is why i referred to him as a bawbag.

I couldn't care less how people use their connection as long as it doesn't have a negative effect on mine.

Either way, the point of the post was to point out the clear differences between router and modem mode. The other guy on my old IP was just an observation, as when his connection isn't in use, his avg. latency seems a lot higher in off peak times especially. Looks like he's having some service issues on the end too... i didn't rip his box off the wall, i promise.

[Sephiroth]

Don't get into an argument with Qasi, Boroboi. He never lets go.

Ask him to interpret the change in minimum latency when you switched to modem mode.

[boroboi]

Originally Posted by Sephiroth

Don't get into an argument with Qasi, Boroboi. He never lets go.

I've noticed

Ask him to interpret the change in minimum latency when you switched to modem mode.

Indeed that one has me stumped... could it be that the Router MAC was registered to a different part of the network to the modem MAC? I'm not sure how VM routes it's customers, the channels are the same though.

In router mode, i'd see maybe 18-19ms min. latency. In modem mode it appears to be around 14-15ms from what i can guess looking at the graph, with a marked improvement in jitter, although it's still there.