Your spikes are all uBR probs
Can't take any outbound trace you show 100% at face value there's 20+ms variation in the first couple of hops.
The obscene routing looks to be outside of ntl control, they have a transit partner in Manchester advertising that route and that's the best path from Leicester so they take it. Unfortunately it is in London so they'd get there faster via LINX but still, the only way they can fix that is to peer with Savvis who probably aren't interested being a tier 1.
If you say that latency is fine but occasionally speeds are slow no point in me doing traceroutes. Also it's not congestion as congestion means serialisation and serialisation means higher ping times, as you've indicated when showing genuinely congested routes.
I've nothing to indicate that's where the fault is either but if a poster above indicates issues to them from non-ntl people, and you yourself have said that they appear to like to overload switches, well....
6 bcr1-ge-4-3-0.Londonlnx.savvis.net (195.66.224.39) 0.938 ms 0.847 ms 0.861 ms
7 bcs2-so-1-1-0.Londonlnx.savvis.net (204.70.193.122) 1.058 ms 0.929 ms 1.065 ms
8 bcs1-as0-0.Londonlnx.savvis.net (204.70.193.201) 1.192 ms 1.303 ms 1.123 ms
9 bcs2-so-0-0-0.NewYork.savvis.net (204.70.192.121) 80.042 ms 80.321 ms 79.874 ms
10 bcs2-so-4-0-0.Washington.savvis.net (204.70.192.1) 83.409 ms 83.315 ms 83.609 ms
11 dcr2-so-7-2-0.Atlanta.savvis.net (204.70.192.57) 96.786 ms 96.730 ms 96.688 ms
12 bcs2-so-2-0-0.Dallas.savvis.net (204.70.192.70) 114.240 ms 119.220 ms 114.613 ms
13 bcs1-so-6-0-0.Dallas.savvis.net (204.70.192.49) 113.531 ms 113.227 ms 113.710 ms
14 ohr1-pos-4-0.FortWorthda1.savvis.net (208.172.131.82) 114.062 ms 114.631 ms 113.861 ms
15 csr2-ve240.FortWorthda1.savvis.net (216.39.64.35) 112.400 ms 112.386 ms 112.252 ms
16 216.39.79.218 (216.39.79.218) 112.731 ms 112.891 ms 112.200 ms
17 * * *
18 42.25.232.72.reverse.layeredtech.com (72.232.25.42) 115.684 ms 115.693 ms 115.339 ms