Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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 ----------

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.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.

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.

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

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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

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


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.

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.

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

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.:

[the above statement is the] Most likely explanation.

END STATEMENT HERE

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

Which part did you not understand?

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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...

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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?

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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

http://www.thinkbroadband.com/ping/s...19-03-2012.png

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

https://www.cableforum.co.uk/images/local/2012/03/6.png

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.

http://www.thinkbroadband.com/ping/s...23-03-2012.png

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

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.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

I've noticed :D

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.