Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Chrysalis]

Well it only takes a single poll with high ping to create a yellow spike, a better indicator is the blue which represents the average, if thats quite thick compared to the green, then that will likely indicate consistent jitter.

[Jon21]

I guess my main gripe, is why is an ISP that seems to pride itself on its network, not that bothered about it? If they were a bargain basement ISP, I’d just accept it. Sky didn’t seem to present that issue. That’s why I don’t buy the idea that because the line is in training, that could be what is causing the spikes. I had interleaving on with Sky, no issues there.

[g3uiss]

I guess because it’s probably not a fault, more what @chrys said. It’s very sensitive to network performance, not really an indicator of a fault.

[Alex Atkin UK]

I guess my main gripe, is why is an ISP that seems to pride itself on its network, not that bothered about it? If they were a bargain basement ISP, I’d just accept it. Sky didn’t seem to present that issue. That’s why I don’t buy the idea that because the line is in training, that could be what is causing the spikes. I had interleaving on with Sky, no issues there.

The problem with judging your line based on ping is that Sky could simply prioritise pings different on their core network to give the illusion of lower latency, especially if you're using their router where they could enable QoS to allow ping priority over other traffic.  They could be completely congested and have a flat-line TBB graph if they configured the core routers to do so, thus why its only a rough guide.

As mentioned, the blue is the key as its the average ping time response.  On a network obeying net neutrality, blue should be a good indication of jitter, if its barely visible it means pings are consistently around the same and the yellow as mentioned it just the odd response or two getting delayed for any number of reasons.  Same with red, it just means some responses didn't return in the timeout window which I'd imagine is quite short considering how often you need to ping to generate the graphs, and the graphs scale would be useless if they expanded to show the odd 2-3 second delayed responses.

Notice even my VPS in a data centre is not free from yellow spikes:


My Zen line (remember my router is grossly overpowered so is more likely to respond quicker):


Now compare that to a mobile Internet connection:

[Weaver]

A test would be to get a TBB pingbox to monitor a server at AA located where there’s very high bandwidth from there to the rest of the internet. You could compare the results of the TBB monitoring with ‘manual’ ping timings from elsewhere into that AA central server. With this I’m trying to establish whether or not there are queuing delays at the TBB pingbox or inside TBB’s network.

[Chrysalis]

Might also be worth looking at https://control.aa.net.uk/.

My connection on there latency isnt spiky.

On my main smokeping which checks pings to my VDSL from germany, there is some spikes but they nothing like whats on TBB. 

So it is important to not just rely on one thing as a performance metric, for me as my connection works well day to day for what I use it for its fine, and SSH command line is really sensitive to both jitter and packet loss, so I would notice on that if things were bad.

[craigski]

This is worth a read to help clarify why you are seeing more 'yellow' than you would like:

https://www.iwl.com/idocs/limitations-of-icmp-echo-for-network-measurement

Many people assume that ICMP Echo, more familiar as "ping", is a valid tool for measuring the performance and behavior of the internet.

That assumption is incorrect. Ping is a tool of value mainly for  determining whether connectivity exists or not. Ping is a weak tool for  measuring delay, variation in delay (jitter), and throughput.

[Alex Atkin UK]

I wonder how games usually do it.  If they were sensible, they would use their own method by sending UDP packets over the actual port and protocol the game uses, the only way to get the true latency to the game server.

This seems useful too: https://kb.vander.host/operating-systems/how-to-do-udp-ping-with-linux/

[Jon21]

Might also be worth looking at https://control.aa.net.uk/.

My connection on there latency isnt spiky.

On my main smokeping which checks pings to my VDSL from germany, there is some spikes but they nothing like whats on TBB. 

So it is important to not just rely on one thing as a performance metric, for me as my connection works well day to day for what I use it for its fine, and SSH command line is really sensitive to both jitter and packet loss, so I would notice on that if things were bad.

This is the CQM for today so far. Even that is spiky at times, around 10am to 12pm ish. Yet the connection was mostly idle. Those spikes for max latency are showing as over 400ms. Admittedly, I haven't come across any noticable issues.

[kitz]

Have you tried putting a different modem on the line?

The intermittent yellow spiking on TBB graphs is a known 'feature' for several BCM based modems.   

[Jon21]

Have you tried putting a different modem on the line?

The intermittent yellow spiking on TBB graphs is a known 'feature' for several BCM based modems.

I’ve gone back to using a Draytek Vigor 130, seems to be more stable on my line.

[Weaver]

Here are the AA CQM graphs for the most recent 24 hours for two of my lines (using PPP LCP ‘echo requests’):

[Chrysalis]

Have you tried putting a different modem on the line?

The intermittent yellow spiking on TBB graphs is a known 'feature' for several BCM based modems.   

Wasnt aware of that, interesting Kitz.

[Weaver]

Jon21 wrote:
> That’s why I don’t buy the idea that because the line is in training, that could be what is causing the spikes.

I agree. You were fobbed off there, and I think you should consider complaining about a violation of AA’s stated ‘no bulls***’ policy. That response was not worthy of AA, and maybe the person you spoke to believed what they said in, which case the right answer should have been ‘I don’t know, I’ll ask Stuart’, not making up a load of random nonsense. They are allowed to not know some things. They don’t always get things right and they’ve really screwed up for me in the past at times but have always put things right and had a great attitude. (For example there was a huge amount of trouble once with a switch they sold me because of config problems, and it was out of action for a week, but I appreciated the huge difficulty of the diagnosis task, and was myself no hero in that I couldn’t solve it either, so I was very supportive of their problems.)

As for the problems with the network, I don’t agree. I’m not seeing them. But my network is not the same as yours.

[Chrysalis]

Did AAISP really say it was down to line training? Missed that bit sorry, yeah as Weaver said bounce that back to them.