TTLatency
Timeline
2017-04-07 - Page created showing examples and giving a brief description of the problem.
2017-10-21 - Added a note about a potential longer term fix (bottom of page)
Introduction
We see latency jumps of about 3-5ms on some TalkTalk connected lines. This typically happens after a re-connection where the circuit is routed to a different LNS (the router at the AAISP side).
This isn't a fault as such, it's more of a phenomenon, and therefore we are wanting to better understand why this happens and to help our customers understand it too.
Purpose of this page
This page will be updated with information about the issue and will show examples, we will also open a Status page to go alongside this page.
Examples
Here are some example graphs from our line monitoring. The latency is shown as the blue line at the base of the graph, and a change is shown as it increasing or decreasing by a few pixels.
- Example graphs showing latency jumps
Jump down at 9am
Jump down at 8pm
Jump up at 10am
Jump down at noon
Jump down at 1am
Jump down at 1am
Jump up at 9pm
Jump up at 3pm
Jump down at 10:30am
Jump up at 1am
Jump down at 6pm
How does this affect customers?
The impact is usually low or zero. A few extra milliseconds is not noticed in practice by most customers, it's not enough to impact the majority of services, VoIP will still work unaffected etc.
It is noticeable on the graphs that we produce and has understandably been questioned by a number of customers.
When does this happen?
This typically happens when a lines is moved between LNSs at our side. The reason this makes a difference is that the circuit will be routed through a different 'tunnel' and this new tunnel is routed the other way through TalkTalk's network.
Why does this happen?
In very simplified terms, TalkTalk run a ring network that goes around the UK, and traffic and can go around this ring one in of two directions. One direction is shorter and the other longer - hence if your circuit is being routed on the longer path, then the latency will be higher.
What can be done?
We don't have any direct control over the route your circuit will take within the TalkTalk network, so in some ways it is pot luck as to which path you are on. However, TalkTalk are looking in to this to see is it's possible for any improvement. We are helping them on this project.
A temporary fix may be to adjust the case of your username befiore the @ part in your router settings. E.g., if your username is customer@a.1, then try cuSTOMer@a.1 or some other variation. If you have multiple lines, then make the username match on all of them. This will mean you will connect to a different LNS ar our side, which in turn will change the routing within the TalkTalk network. You may still get re-routed when you log in again next, but you can try the same trick again if that is the case.
This is an unsupported feature. Usually all usernames would be lower case, and our support team may will advise you to change to all lower case in the event of a problem or fault.
Longer term, early 2018, we expect this problem to go away due to works on the TalkTalk network. This is unconfirmed and un tested though, so we have to wait and see. TalkTalk have told us (unofficially) that they have a project to help with the latency jumps described here. The project involves using optimised (lower latency) routes rather than random routes.