PDA

View Full Version : recent drop in performance 1mbit in leicester


Chrysalis
16-04-2004, 22:27
I have recently noticed more lag in ssh sessions and poor traceroutes to locations, jumps on the ntl hops look very worrying, check these examples.

Tracing route to cableforum.co.uk [69.72.137.98]
over a maximum of 30 hops:

1 15 ms 9 ms 8 ms 10.146.151.254
2 17 ms 15 ms 8 ms leic-t2cam1-a-ge96.inet.ntl.com [80.7.30.17]
3 15 ms 10 ms 10 ms nott-t2core-a-ge-wan63.inet.ntl.com [80.1.79.69]

4 13 ms 11 ms 11 ms lee-bb-a-so-200-0.inet.ntl.com [62.253.188.33]
5 18 ms 57 ms 16 ms pop-bb-b-so-100-0.inet.ntl.com [62.253.185.238]

6 22 ms 19 ms 45 ms tele-ic-1-so-000-0.inet.ntl.com [62.253.185.82]

7 20 ms 18 ms 18 ms linx.ge-0-0-0.gbr1.ltn.nac.net [195.66.224.94]
8 86 ms 94 ms 136 ms 0.so-0-3-0.gbr2.nwr.nac.net [209.123.11.209]
9 120 ms 128 ms 87 ms 0.so-0-3-0.gbr1.oct.nac.net [209.123.11.233]
10 119 ms 90 ms 87 ms 209.123.182.243
11 85 ms 93 ms 88 ms 69.57.170.3
rest times out

Tracing route to adslguide.org [80.249.99.125]
over a maximum of 30 hops:

1 12 ms 9 ms 17 ms 10.146.151.254
2 12 ms 8 ms 79 ms leic-t2cam1-b-ge96.inet.ntl.com [80.7.30.145]
3 11 ms 13 ms 11 ms nott-t2core-b-ge-wan63.inet.ntl.com [80.1.79.197
]
4 41 ms 83 ms 13 ms nth-bb-b-so-200-0.inet.ntl.com [62.253.185.37]
5 15 ms 16 ms 16 ms pop-bb-a-so-100-0.inet.ntl.com [213.105.172.14]

6 18 ms 94 ms 97 ms tele-ic-2-so-000-0.inet.ntl.com [62.253.185.86]

7 15 ms 14 ms 15 ms ge-linx1.lon3.as8553.net [195.66.224.126]
8 14 ms 42 ms 15 ms as8553-gw.ncuk.com [195.10.255.6]
9 64 ms 14 ms 25 ms ir1-gw.thdo.ncuk.net [80.249.97.12]
10 16 ms 23 ms 18 ms iota.ncuk.net [80.249.99.125]

Tracing route to www.novatech.co.uk [212.87.86.90]
over a maximum of 30 hops:

1 69 ms 11 ms 9 ms 10.146.151.254
2 53 ms 11 ms 14 ms leic-t2cam1-a-ge96.inet.ntl.com [80.7.30.17]
3 11 ms 62 ms 13 ms nott-t2core-a-ge-wan63.inet.ntl.com [80.1.79.69]

4 13 ms 30 ms 12 ms lee-bb-a-so-200-0.inet.ntl.com [62.253.188.33]
5 42 ms 20 ms 20 ms pop-bb-b-so-100-0.inet.ntl.com [62.253.185.238]

6 21 ms 17 ms 58 ms tele-ic-1-so-000-0.inet.ntl.com [62.253.185.82]

7 33 ms 28 ms 17 ms linx3.th.newnet.co.uk [195.66.224.131]
8 * * * Request timed out.
rest times out

now I know the middle part of traceroutes is not necessairly important but I dont remember seeing such jumps on the ntl hops a few weeks ago, I got no idea if ntl made any recent changes to their network, but has anyone else noticed a recent rop in performance, lag wise (download speeds seem fine) upload seems to have gone down a bit, I am in the leicester area.

Florence
16-04-2004, 22:31
Nothing different there with other areas. Have you spoken to CS?

td444
17-04-2004, 01:41
Try running "ping lifeless.aa.nu -n 100" and post the results.

Sounds like the problem I had - near capacity upstreams causing huge fluctuations in latency due to lack of timeslots, but the downstream and upstream (when sending large items due to concentation) were perfect.

threadbare
17-04-2004, 15:25
those tracroutes look fine to me. you have to remember that ICMP traffic has a low priority and hnce will occasionally show slight jumps

td444
17-04-2004, 16:53
those tracroutes look fine to me. you have to remember that ICMP traffic has a low priority and hnce will occasionally show slight jumps
There isnt any QOS of that sort on lifeless.aa.nu. Its sole job is to perform ICMP hence why I asked. But yeah the fluctuations in the other hops are due to QOS giving ICMP lower priority.

Chrysalis
18-04-2004, 13:41
well I never seen those fluctuations before especially on the 1st hop and along with my recent problems suggests a problem, I am running that test now and will edit my post when its done.

Ping statistics for 217.169.20.26:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 427ms, Average = 23ms

td444
18-04-2004, 16:10
It looks ok, although I take it the line was free of any activity? I get spikes of about 45ms occasionally but not 427ms.

Having said that, its only showing an average and not a standard deviation which are more useful.

You could PM JustAnotherN00b and ask nicely if he can switch your upstream to one that has less utilization. That really helped with me when CV area was buggered due to lack of timeslots.

Chrysalis
18-04-2004, 18:11
yeah I watched it and had a few shoot up to around 70ms, and that 1 big jump, the line was idle barring a irc connection. But before I had pure stable latency I am beggining to really think my ubr has hit over capacity problem :(

Chrysalis
18-04-2004, 18:14
command window still open take a look

Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=22ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=25ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=40ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=21ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=53ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=16ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=53ms TTL=56
Reply from 217.169.20.26: bytes=32 time=70ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=11ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=27ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=36ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=46ms TTL=56
Reply from 217.169.20.26: bytes=32 time=26ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=17ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=47ms TTL=56
Reply from 217.169.20.26: bytes=32 time=427ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=71ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=17ms TTL=56
Reply from 217.169.20.26: bytes=32 time=30ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=44ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=47ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=24ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=40ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=15ms TTL=56
Reply from 217.169.20.26: bytes=32 time=32ms TTL=56
Reply from 217.169.20.26: bytes=32 time=16ms TTL=56
Reply from 217.169.20.26: bytes=32 time=14ms TTL=56
Reply from 217.169.20.26: bytes=32 time=16ms TTL=56
Reply from 217.169.20.26: bytes=32 time=18ms TTL=56
Reply from 217.169.20.26: bytes=32 time=21ms TTL=56
Reply from 217.169.20.26: bytes=32 time=13ms TTL=56
Reply from 217.169.20.26: bytes=32 time=12ms TTL=56
Reply from 217.169.20.26: bytes=32 time=20ms TTL=56
Reply from 217.169.20.26: bytes=32 time=73ms TTL=56

paulyoung666
18-04-2004, 18:27
nowt much wrong there :)

td444
18-04-2004, 18:34
nowt much wrong there :)
True. Can you do traceroutes to the server's your ssh'n to, cutting out the final destination hop?

Chrysalis
18-04-2004, 20:26
jumps to 70ms and 1 400ms jump you see as normal?, A friend of mine in another area near birmingham is also on ntl and he is never getting above 20ms on the first 4 hops.

1 10 ms 11 ms 19 ms 10.146.151.254
2 19 ms 12 ms 65 ms leic-t2cam1-b-ge96.inet.ntl.com [80.7.30.145]
3 13 ms 11 ms 37 ms nott-t2core-b-ge-wan63.inet.ntl.com [80.1.79.197
]
4 38 ms 12 ms 17 ms nth-bb-b-so-300-0.inet.ntl.com [62.253.188.37]
5 16 ms 87 ms 25 ms pop-bb-a-so-100-0.inet.ntl.com [213.105.172.14]

6 26 ms 43 ms 70 ms tele-ic-2-so-000-0.inet.ntl.com [62.253.185.86]

7 24 ms 19 ms 17 ms Gi3-0.lonth-inter-1.interoute.net [195.66.224.53
]
8 48 ms 32 ms 52 ms PO9-0.Lon-Kie-core-2.interoute.net [212.23.41.37
]
9 23 ms 27 ms 42 ms PO9-1.Par-Gar-core-1.interoute.net [212.23.42.21
]
10 25 ms 36 ms 23 ms PO6-0.Par-Gar-access-1.interoute.net [212.23.42.
6]
11 26 ms 53 ms 27 ms 212.23.46.194

this is very inconsistent nearly every ntl hop hasnt got steady figures, when uploading I notice it will be 30kb/sec then a pause for about 1-2 secs where it just stops and then it carries on but bringing the average speed right down, again this is a new problem within the last month or so.

threadbare
18-04-2004, 21:07
that looks fine too

rdhw
19-04-2004, 11:01
this is very inconsistent nearly every ntl hop hasnt got steady figuresIt is characteristic of a public network that you will never get steady ping results from routers, because of dynamic traffic loading variations on the various circuits. Also, NTL operate a routing system whereby ICMP replies might return to you by a different physical route each time, even from the same router.when uploading I notice it will be 30kb/sec then a pause for about 1-2 secs where it just stops and then it carries onThis is probably nothing to do with ping variations or traceroute problems. What you describe sounds like the TCP protocol recovering after a packet loss in one direction or another. If you put a protocol analyser between your PC and the cable modem you might be able to work out what is happening.

You should eliminate the possibility that the packet loss is happening in your own network (e.g. by an ethernet duplex mismatch).

A work-around might be to rate-limit your uploads at source so that they do not saturate your cable modem upload rate cap.