Ping increase

On the 29 Nov my Sky latency (Samknows box), went from 14-16ms to 29-31ms and has stayed there ever since. I have spoken to Sky on several occasions who have said, there is nothing they can do, as they have no access to systems that can investigate this. It appears to be a widespread problem (going by alternative forum posts) but the Sky "techies" seem to know nothing about it and cannot help. I know it may not sound like much of an increase but being a sad old gamer I like to have a nice low ping.

Ive had Sky fibre since the 3rd week of Oct when they mistakenly put me on the 40/2 package and this took nearly a month to sort out. It turned out the only people who could fix it was BT, who finally sorted it out for me a month after ordering. Any possibility that BT could be responsible for latency increase and Sky have their hands tied in sorting it out?

The link between you and the exchange is Openreach, their GEA product. It is handed over there to Sky via ethernet and it's Sky's baby from then on.

It could be the Openreach DLM in the cabinet that has put interleaving on. Have you also lost any speed? (Probably not if you get over 70Mbps, but if less than that you might have lost about 8%).

It could be crosstalk as more people near you have been conencted to fibre. It could be Sky getting more heavily loaded at that exchnage.

Not a lot to be done I'm afraid.

Thanks for the reply RobertoS.
It does seem a bit strange, that other exchanges all over the country experienced this increase and Sky seem to know nothing about it.
Going back to my 40/2 problem. When Sky could not sort it, it was eventually passed on to a BT person in Leeds who called me and talked through her process of checking my line and changing the profile there and then. What took Sky nearly a month to try and rectify took BT a few minutes to actually fix it.
Just how much influence does BT have on other companies fibre, it seems to go further than just the exchange. If this is the case.
In regards to crosstalk, can that actually be blamed for such a sudden increase in latency, it wasnt a gradual increase it happened immediately.

In reply to a post by RobertoS:

It could be crosstalk as more people near you have been conencted to fibre. It could be Sky getting more heavily loaded at that exchnage.

29th November is a touch early, but it could also be that annual bugbear- interference from cheapo Christmas lights.

In which case the DLM might relent some time into the New Year and take the interleaving off.

I live in a pretty quiet village connected to a cab 350ms away. On the 29th of Nov there were no Christmas lights up in my small street, with no obvious sign of any between my house and the cab, (near to the bus stop I use daily for work). Although now, the place is lit up like the preverbial.

Ah well, it was a thought.

My neighbour put up his usual half-megawatt of lights around then, but so far (crossing everything I've got two of that can cross) it hasn't caused any problems. It has in the past, maybe he's bought new ones.

In reply to a post by HiPing:

When Sky could not sort it, it was eventually passed on to a BT person in Leeds who called me and talked through her process of checking my line and changing the profile there and then. What took Sky nearly a month to try and rectify took BT a few minutes to actually fix it.
Just how much influence does BT have on other companies fibre, it seems to go further than just the exchange.

Being passed on to a BT person in this situation is highly unusual. It should have been possible for Sky support to liaise satisfactorily with the appropriate BT department. Almost certainly someone in Openreach. All I can say about that is I'm glad it got sorted for you.

Regarding the general setup, this slightly out of date page might explain a lot to you. Sky Fibre is not true LLU, (I'm assuming you know what that is, but on the same site is a "What is LLU?" page), as that would need them to cable out to the cabinets in the same way as Openreach have done. Billions of squidoodles.

So whereas on LLU they have almost complete control of the line, relying only on Openreach for the physical maintenance of the copper from the exchange, on fibre they basically only control it from their LLU kit in the exchange back to themselves. Although they can request a few performance settings. The 40/2, 40/10 and 80/20 settings are simple Openreach products that they order on your behalf, and the performance settings are simply stability increases, QOS settings, and suchlike.

Interleaving and underlying latency are set automatically within Openreach systems. There seem to be no systems for any ISP to request alterations to those. Further variable latency can of course arise within the Sky backhaul system.

Similar to you but not as dramatic, 24 November, after 18 months or so on fast path, interleaving was applied to my line, latency rose by about 4ms, and I lost 10Mbps downstream. 19:45 on 14 December the latency dropped back toi the original value, but the interleaving and the speed loss it causes remain. No known reasons . WIth a bit of luck, in a while it will revert to fast path and give me the speed back.

Not even worth pursuing with my ISP. Or any ISP if it happens to one of their customers. I fear it is the consequence of getting the ludicrously high speeds and allowances we now have compared to the past. It would be just impossible Openreach to keep everyone happily on the highest tight-rope seeing as they can provide small performance decreases that stabilise everything.

I hope that helps explain things. I know it doesn't explain why you have had such a big change.

Thank you very much for the in-depth reply, filled in a fair few gaps in my knowledge there.
So swapping to another provider, along with all the hassle this causes, chances are, I would'nt see any change anyway.
Ah well, no real option but to hang on and hope for the best then.

My top three for fibre - BT, Plusnet and Sky. Though I'm beginning to downgrade BT in my estimation.

I expect Zen are OK. I did my first year with IDNet and had no complaints, but from keeping my eyes open here decided I would risk Plusnet for far less money. Ten months into Plusnet I feel I did the right thing, to the point where I'm about to commit to another 18 months from January 13.

In reply to a post by RobertoS:

My top three for fibre - BT, Plusnet and Sky. Though I'm beginning to downgrade BT in my estimation.

Likewise - I've been more impressed with BT (Infinity) than I thought I would be

The interleave I believe was applied to my line on day 2 and has never been lifted. Judging from the fact my lowest ping to a bbc site (on Windows 7) is 18ms and other people report 8ms. :-/

Edited by jchamier (Tue 18-Dec-12 07:49:56)

In reply to a post by jchamier:

The interleave I believe was applied to my line on day 2 and has never been lifted. Judging from the fact my lowest ping to a bbc site (on Windows 7) is 18ms and other people report 8ms. :-/

18ms I remember those days

In reply to a post by HiPing:

Thank you very much for the in-depth reply, filled in a fair few gaps in my knowledge there.
So swapping to another provider, along with all the hassle this causes, chances are, I would'nt see any change anyway.
Ah well, no real option but to hang on and hope for the best then.

Any chance you could perform a tracert to the BBC? It would inform us of where the latency has its highest jump.

Aside from Interleaving, it could be an increase on Sky's backhaul/core network.

In reply to a post by HiPing:

In regards to crosstalk, can that actually be blamed for such a sudden increase in latency, it wasnt a gradual increase it happened immediately.

A large number of lab experiments on crosstalk have been going on for VDSL2, especially as the boffins develop the vectoring concept that will (hopefully) eradicate the effects.

Those experiments tend to show that each line might suffer from umpteen disturbers, but the effect is not equal - and a few of the disturbers have a much more pronounced effect.

So crosstalk might have been gradually being added to the line, or it might just have been a single "heavy" disturber that got turned on. Perhaps they just happen to have the cable next to yours in the run back to the cabinet.

Either way, once sufficient crosstalk is in place, that causes sufficient errors on the line, DLM intervenes to set one of a number of profiles, which set a speed limit and/or a level of interleaving (which reduces speed too).

So yes: gradual increases in crosstalk eventually lead to a step change in latency.

But not usually that large. We had a line problem, and latency went from 13ms to 20ms (then back again a month after the problem was fixed).

I have 2 nodes available to me when connecting to BT.

I believe one is peterborough which gives me 13ms to bbc.co.uk but has spikes every 4 to 5 packets up to 16-17ms. The other which I am using which I believe goes via birmingham is 17ms to the bbc but is much more stable on the jitter.

Here is a tracert on the latter. This is on a fastpath connection.

Tracing route to bbc.co.uk [212.58.241.131]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms unknown [192.168.1.253]
2 5 ms 5 ms 5 ms 217.32.144.166
3 6 ms 6 ms 6 ms 217.32.144.206
4 8 ms 8 ms 8 ms 213.120.181.206
5 8 ms 7 ms 7 ms 217.41.169.221
6 7 ms 7 ms 7 ms 217.41.169.109
7 20 ms 7 ms 7 ms acc2-10GigE-9-3-0.sf.21cn-ipp.bt.net [109.159.25
1.223]
8 15 ms 15 ms 15 ms core1-te0-2-4-0.ilford.ukcore.bt.net [109.159.25
1.141]
9 13 ms 13 ms 13 ms peer2-xe11-0-0.telehouse.ukcore.bt.net [109.159.
254.130]
10 14 ms 14 ms 14 ms 194.74.65.42
11 * * * Request timed out.
12 16 ms 16 ms 35 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
13 17 ms 17 ms 19 ms 132.185.255.60
14 17 ms 17 ms 17 ms 212.58.241.131

Cheers for that, I will post one tonight when I get in from work.

My cab is the ECI 128 , which has more space than we have houses in our part of the village (other cabs further down the village). It turned out when BT installed fibre for me I was the first one in the village to get it (21 Oct 12). Must have been a mad rush for fibre after I joined, i should have kept my mouth shut.

Yeah. On first installation, my modem reported a maximum attainable speed of 83Mbps. Now (a year later) it says 78Mbps.

Luckily, we haven't resynced for the last month, so it is still running at 80/20. It won't next time though...

In reply to a post by Chrysalis:

I have 2 nodes available to me when connecting to BT.

That's a good point... Most MSANs are (or should be) dual-parented, so there are 2 different routes back to the core network. And for some the difference is significant.

IIRC each PPP session ends up routed one way or the other, so a disconnect/connect at *router* level could cause a change.

In reply to a post by WWWombat:

Yeah. On first installation, my modem reported a maximum attainable speed of 83Mbps. Now (a year later) it says 78Mbps.

Luckily, we haven't resynced for the last month, so it is still running at 80/20. It won't next time though...

Count yourself lucky ... mine has dropped about 15Mbps over 20 months and an extra drop due to Christmas!

mine dropped 20 very quickly. given the potential 40% or so drop expected from crosstalk I would say a 83 to 78 drop over that period of time is pretty good.

Edited by Chrysalis (Tue 18-Dec-12 18:23:52)

In reply to a post by WWWombat:

That's a good point... Most MSANs are (or should be) dual-parented, so there are 2 different routes back to the core network. And for some the difference is significant.

Would this also apply to FTTC though?

Here are a couple of examples from tonight, done approx 3 mins apart:
My ping has now increased to 34-35ms, since this morning, the village rush for fibre must still be on.
Sky called back tonight and said that my profile was fine, there were no errors on my line and interleaving was off.

Tracing route to www.bbc.net.uk [212.58.244.70]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms SkyRouter.Home [192.168.0.1]
2 * * * Request timed out.
3 34 ms 32 ms 31 ms ip-84-38-37-16.easynet.co.uk [84.38.37.16]
4 41 ms 39 ms 38 ms 89.200.131.185
5 29 ms 29 ms 29 ms ntl-ge2-9.prt0.rbsov.bbc.co.uk [212.58.238.

6 * * * Request timed out.
7 * * * Request timed out.
8 30 ms 29 ms 29 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
9 31 ms 29 ms 29 ms 132.185.255.148
10 29 ms 29 ms 30 ms bbc-vip115.telhc.bbc.co.uk [212.58.244.70]



Tracing route to www.bbc.net.uk [212.58.246.92]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms SkyRouter.Home [192.168.0.1]
2 * * * Request timed out.
3 35 ms 32 ms 31 ms ip-84-38-37-14.easynet.co.uk [84.38.37.14]
4 36 ms 31 ms 32 ms 89.200.131.187
5 29 ms 29 ms 29 ms ntl-ge2-9.prt0.rbsov.bbc.co.uk [212.58.238.

6 * * * Request timed out.
7 31 ms 30 ms 30 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
8 33 ms 31 ms 30 ms 132.185.255.165
9 29 ms 30 ms 29 ms bbc-vip013.cwwtf.bbc.co.uk [212.58.246.92]


Tracing route to www.bbc.net.uk [212.58.246.92]
over a maximum of 30 hops:

1 2 ms 1 ms 1 ms SkyRouter.Home [192.168.0.1]
2 * * * Request timed out.
3 34 ms 30 ms 31 ms ip-84-38-37-14.easynet.co.uk [84.38.37.14]
4 30 ms 31 ms 30 ms 89.200.131.187
5 31 ms 37 ms 29 ms ntl-ge2-9.prt0.rbsov.bbc.co.uk [212.58.238.

6 * * * Request timed out.
7 31 ms 29 ms 29 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
8 34 ms 33 ms 33 ms 132.185.255.165
9 33 ms 31 ms 33 ms bbc-vip013.cwwtf.bbc.co.uk [212.58.246.92]

Edited by HiPing (Tue 18-Dec-12 20:15:27)

In reply to a post by Ignitionnet:

In reply to a post by WWWombat:

That's a good point... Most MSANs are (or should be) dual-parented, so there are 2 different routes back to the core network. And for some the difference is significant.

Would this also apply to FTTC though?

If the 21CN core has been built anything like it was originally planned to be, then yes - that part certainly is. That means the ISP's using WBC and WBMC should automatically get this.

Whether the FTTC cabinet is dual-parented (eg 2 different exchanges), or the head-end OLT is duplicated, or is dual-parented (multiple cable-links?), I don't know.

In reply to a post by HiPing:

My ping has now increased to 34-35ms, since this morning, the village rush for fibre must still be on.
Sky called back tonight and said that my profile was fine, there were no errors on my line and interleaving was off.

No interleaving means that either (a) Sky support don't know what they're saying about FTTC, or (b) the change in delay is purely down to delays within Sky's network.

How does your ping alter over the course of a day (or night)?

Ordinarily I'd mention a BQM here (see http://www.thinkbroadband.com/ping) but I don't think Sky has static IP, does it?

Just done a quick ping, and tracert to the Beeb from my BT connection, overall 18ms, tracert showing quite a few more hops than the OP's, one even shows 50+ ms.

I don't get the 'missing' 2nd hop he does, anyone else ?

To the OP, my cab has been live for over two years, and there is around 120 connections running from it, so maybe the issue isn't your nieghbours rush for speed ?

Whoops, you mean like these ones ahem!
The last one shows a disconnection, my son being over zealous with pulling plugs out after turning off his xbox.

My Broadband Ping 23 Nov 12

My Broadband Ping 29 Nov12

My Broadband Ping 30 Nov 12

My Broadband Ping 05 Dec 12

My Broadband Ping 18 Dec 12

What I find interesting is that it seems to have increased from just less than 20ms to about 25 (hard to tell exactly from a graph) in the early hours of 30/11, then from there back to 20ms, then jumped to about 30ms.
Assuming you didn't go an unplug/reboot the modem at midnight, 2am and 5am, that looks like something has been changing a few times in about 5 hours.
Where geographically are you? You are now getting higher pings than I get from Scotland on ADSL...

I'm an exiled Scotsman , living in the village of Barlby in North Yorkshire, connected to the Selby exchange. Maybe I reboot routers when I sleep walk, does seem weird though.

Edited by HiPing (Tue 18-Dec-12 21:55:34)

Interesting discussion generally. I've had FTTC through one of the small ISPs - who prides themselves on not "overselling" their network - for well over 12m at a consistent 16ms minimum latency (and average only just minimally higher except during my own heavy downloading) according to TBBQM monitoring. Average results in the same ball park from Trace Route to Google and JDast auto tester's daily tests at various times which uses BBC for ping testing by default. The only noticeable change was a doubling in the latency (to 16ms) after the first month when interleaving was turned on my connection, which was not unexpected. I use a Fritz!Box modem (which shows the latency as 8ms just to the Cab DSLAM) not the OR varieties though, but in fairness it looked stable on my connection anyway.

Interesting though that other FTTC users on the same ISP have recently (over the last month) started to report the same sort of variances as reported here but not to anything like the same extent. Just wondering though as I'm still on 40/10 (as due to distance from the cab as my attainable rate would struggle to get much higher) do these problems particularly afflict those pushing their connections up to 80/20, or whatever? EDIT: just out of interest looked up the JDast monitoring of pings on my fixed wireless connection - which takes the local loop out of the equation but uses Sky's backhaul network via Easynet - and is in the 12-20ms range consistently to bbc.co.uk.

Edited by deleted (Tue 18-Dec-12 22:33:42)

Actually, if you want to see a high ping try 202.80.32.65 - you are unlikely to get less than 800ms to that

In reply to a post by Uilebheist:

What I find interesting is that it seems to have increased from just less than 20ms to about 25 (hard to tell exactly from a graph) in the early hours of 30/11, then from there back to 20ms, then jumped to about 30ms.

Yup - I find the same bits interesting. And the changes early on the 5th.

However, I can tell that they're NOT from a modem resync/reboot. If it were, there would be a visible red spike at each change, rather like the spike at 10:15 on the 30th.

^Edit: For example, this is where DLM added interleaving, while this is where DLM removed interleaving.

The changes are going to be down to some re-arrangement going on in the Sky backhaul, or the Sky core network itself.

Edited by deleted (Tue 18-Dec-12 22:35:29)

your line with interleaving is similiar to mine without it

That does not make me feel any better lol.

In reply to a post by Uilebheist:

you are unlikely to get less than 800ms to that

Reasonably consistent though:

PING 202.80.32.65 (202.80.32.65): 56 data bytes
64 bytes from 202.80.32.65: icmp_seq=0 ttl=46 time=810.573 ms
64 bytes from 202.80.32.65: icmp_seq=1 ttl=46 time=813.398 ms
64 bytes from 202.80.32.65: icmp_seq=2 ttl=46 time=808.377 ms
64 bytes from 202.80.32.65: icmp_seq=3 ttl=46 time=811.529 ms
64 bytes from 202.80.32.65: icmp_seq=4 ttl=46 time=812.772 ms
64 bytes from 202.80.32.65: icmp_seq=5 ttl=46 time=822.898 ms
64 bytes from 202.80.32.65: icmp_seq=6 ttl=46 time=813.799 ms
64 bytes from 202.80.32.65: icmp_seq=7 ttl=46 time=818.046 ms
64 bytes from 202.80.32.65: icmp_seq=8 ttl=46 time=813.779 ms
64 bytes from 202.80.32.65: icmp_seq=9 ttl=46 time=808.370 ms

--- 202.80.32.65 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 808.370/813.354/822.898/4.177 ms

Two satellite hops? The round trip time fits nicely.

An average of 43ms worse than Billford, typical. Do you know a short cut?

Reply from 202.80.32.65: bytes=32 time=854ms TTL=47
Reply from 202.80.32.65: bytes=32 time=853ms TTL=47
Reply from 202.80.32.65: bytes=32 time=865ms TTL=47
Reply from 202.80.32.65: bytes=32 time=850ms TTL=47
Reply from 202.80.32.65: bytes=32 time=860ms TTL=47
Reply from 202.80.32.65: bytes=32 time=852ms TTL=47
Reply from 202.80.32.65: bytes=32 time=866ms TTL=47
Reply from 202.80.32.65: bytes=32 time=854ms TTL=47
Reply from 202.80.32.65: bytes=32 time=857ms TTL=47
Reply from 202.80.32.65: bytes=32 time=858ms TTL=47

Ping statistics for 202.80.32.65:
Packets: Sent = 10, Received = 10, Lost = 0 (0% l
Approximate round trip times in milli-seconds:
Minimum = 850ms, Maximum = 866ms, Average = 856ms

In reply to a post by billford:

Two satellite hops? The round trip time fits nicely.

I think so. Their only link seems to be a satellite link to Australia.
Used to be a popular thing to ask to ping whenever anybody complained about high pings on some of the ISP forums

In reply to a post by HiPing:

Do you know a short cut?

No, I've always had excellent ping times from this address, ever since I first got broadband at 2Mbps.

It drives the gamers up the wall, because I have absolutely zero interest in gaming

In reply to a post by Uilebheist:

Actually, if you want to see a high ping try 202.80.32.65 - you are unlikely to get less than 800ms to that

Yikes

Tracing route to 202.80.32.65 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  192.168.xxx.xxx
  2    24 ms    22 ms    25 ms  lo0-central10.pcl-ag02.plus.net [195.166.128.183]
  3    41 ms    21 ms    21 ms  link8-central10.pcl-gw02.plus.net [84.93.249.46]
  4    21 ms    21 ms    21 ms  xe-0-2-0.pcl-cr02.plus.net [212.159.1.2]
  5    22 ms    21 ms    26 ms  ae1.ptw-cr02.plus.net [195.166.129.2]
  6    23 ms    27 ms    21 ms  lonap.he.net [193.203.5.128]
  7    95 ms    98 ms    99 ms  10gigabitethernet7-4.core1.nyc4.he.net [72.52.92.241]
  8   160 ms   160 ms   160 ms  10gigabitethernet10-1.core1.sjc2.he.net [184.105.213.173]
  9   160 ms   159 ms   160 ms  vocus.10gigabitethernet8-3.core1.sjc2.he.net [184.105.224.246]
 10   316 ms   316 ms   315 ms  ten-0-0-0-1.cor01.sjc02.ca.VOCUS.net [114.31.199.184]
 11   316 ms   315 ms   315 ms  ten-0-2-0-0.cor01.sjc01.ca.VOCUS.net [114.31.199.180]
 12   316 ms   315 ms   315 ms  ten-0-5-0-0.cor01.syd04.nsw.VOCUS.net.au [114.31.199.37]
 13   316 ms   316 ms   316 ms  ten-0-0-0-0.cor03.syd03.nsw.VOCUS.net.au [175.45.72.119]
 14   315 ms   315 ms   315 ms  ten-1-3-0.cor02.syd03.nsw.VOCUS.net.au [175.45.72.121]
 15   316 ms   319 ms   316 ms  as38456.cust.cor02.syd03.nsw.VOCUS.net.au [114.31.193.42]
 16   318 ms   318 ms   317 ms  syd-gsw-122-200-58-91.pacificteleports.net [122.200.58.91]
 17   313 ms   313 ms   313 ms  122-200-62-10.pacificteleports.net [122.200.62.10]
 18   311 ms   311 ms   311 ms  122-200-62-226.pacificteleports.net [122.200.62.226]
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21   819 ms   819 ms   813 ms  202.80.32.197
 22   816 ms   821 ms   822 ms  202.80.32.194
 23   819 ms   827 ms   819 ms  202.80.32.101
 24   826 ms   820 ms   819 ms  202.80.32.65

Trace complete.

Err... Should I be worried?

C:\Users\m>ping 202.80.32.65

Pinging 202.80.32.65 with 32 bytes of data:
Reply from 202.80.32.65: bytes=32 time=2958ms TTL=43
Reply from 202.80.32.65: bytes=32 time=2980ms TTL=43
Reply from 202.80.32.65: bytes=32 time=2969ms TTL=43
Reply from 202.80.32.65: bytes=32 time=3013ms TTL=43

Ping statistics for 202.80.32.65:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2958ms, Maximum = 3013ms, Average = 2980ms

Maybe it's raining over there?

In reply to a post by WWWombat:

Err... Should I be worried?

No. But they probably should.
(A friend used to work there and apparently they've seen 4000+ms pings before)

In reply to a post by RobertoS:

My top three for fibre - BT, Plusnet and Sky. Though I'm beginning to downgrade BT in my estimation.

I expect Zen are OK. I did my first year with IDNet and had no complaints, but from keeping my eyes open here decided I would risk Plusnet for far less money. Ten months into Plusnet I feel I did the right thing, to the point where I'm about to commit to another 18 months from January 13.

I suspect I'll do the same thing. It's been a good service from IDNet but there have been four 'incidents' and getting their support to do anything can be a bit of a trial. I was told for instance that my upstream dropping from 14Mb/s to 11Mb/s was a 'slight' change and hardly worth complaining about. The BT speedtester reported 16Mb/s.

When my line went wobbly (always on the 19th although interestingly this month it seems not to have done) I was mildly chastised for referring to 30Mb/s throughput off a 79Mb/s sync as 'poor'.

If I was with an ISP that doesn't claim to care much it wouldn't be so bad. But IDNet likes to talk a good game and they do employ people who know what they are doing. It's just such hard work getting past the front line 'defenders'.

I know its during peak time but are these speeds still not a bit low.
19/12/12 20:26 13425 Kbps 3532 Kbps 94.12.61.254
19/12/12 20:21 12003 Kbps 3545 Kbps 94.12.61.254
19/12/12 20:19 12789 Kbps 3362 Kbps 94.12.61.254

And now my ping seem to be getting worse (nothing running background):
Pinging www.bbc.net.uk [212.58.244.71] with 32 bytes of data:
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=48ms TTL=56
Reply from 212.58.244.71: bytes=32 time=47ms TTL=56
Reply from 212.58.244.71: bytes=32 time=51ms TTL=56
Reply from 212.58.244.71: bytes=32 time=38ms TTL=56
Reply from 212.58.244.71: bytes=32 time=63ms TTL=56
Reply from 212.58.244.71: bytes=32 time=58ms TTL=56
Reply from 212.58.244.71: bytes=32 time=56ms TTL=56
Reply from 212.58.244.71: bytes=32 time=43ms TTL=56
Reply from 212.58.244.71: bytes=32 time=37ms TTL=56
Reply from 212.58.244.71: bytes=32 time=31ms TTL=56
Reply from 212.58.244.71: bytes=32 time=36ms TTL=56
Reply from 212.58.244.71: bytes=32 time=40ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56
Reply from 212.58.244.71: bytes=32 time=30ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=50ms TTL=56
Reply from 212.58.244.71: bytes=32 time=51ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=40ms TTL=56
Reply from 212.58.244.71: bytes=32 time=30ms TTL=56
Reply from 212.58.244.71: bytes=32 time=31ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=33ms TTL=56
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=38ms TTL=56
Reply from 212.58.244.71: bytes=32 time=41ms TTL=56
Reply from 212.58.244.71: bytes=32 time=37ms TTL=56
Reply from 212.58.244.71: bytes=32 time=53ms TTL=56
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=67ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=58ms TTL=56
Reply from 212.58.244.71: bytes=32 time=63ms TTL=56
Reply from 212.58.244.71: bytes=32 time=68ms TTL=56
Reply from 212.58.244.71: bytes=32 time=68ms TTL=56
Reply from 212.58.244.71: bytes=32 time=63ms TTL=56
Reply from 212.58.244.71: bytes=32 time=67ms TTL=56
Reply from 212.58.244.71: bytes=32 time=54ms TTL=56
Reply from 212.58.244.71: bytes=32 time=58ms TTL=56
Reply from 212.58.244.71: bytes=32 time=41ms TTL=56
Reply from 212.58.244.71: bytes=32 time=47ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=37ms TTL=56
Reply from 212.58.244.71: bytes=32 time=30ms TTL=56
Reply from 212.58.244.71: bytes=32 time=33ms TTL=56
Reply from 212.58.244.71: bytes=32 time=34ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=62ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=33ms TTL=56
Reply from 212.58.244.71: bytes=32 time=34ms TTL=56
Reply from 212.58.244.71: bytes=32 time=37ms TTL=56
Reply from 212.58.244.71: bytes=32 time=43ms TTL=56
Reply from 212.58.244.71: bytes=32 time=53ms TTL=56
Reply from 212.58.244.71: bytes=32 time=41ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=48ms TTL=56
Reply from 212.58.244.71: bytes=32 time=35ms TTL=56
Reply from 212.58.244.71: bytes=32 time=43ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=31ms TTL=56
Reply from 212.58.244.71: bytes=32 time=30ms TTL=56
Reply from 212.58.244.71: bytes=32 time=38ms TTL=56
Reply from 212.58.244.71: bytes=32 time=40ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=48ms TTL=56
Reply from 212.58.244.71: bytes=32 time=47ms TTL=56
Reply from 212.58.244.71: bytes=32 time=54ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=59ms TTL=56
Reply from 212.58.244.71: bytes=32 time=53ms TTL=56
Reply from 212.58.244.71: bytes=32 time=62ms TTL=56
Reply from 212.58.244.71: bytes=32 time=52ms TTL=56
Reply from 212.58.244.71: bytes=32 time=51ms TTL=56
Reply from 212.58.244.71: bytes=32 time=57ms TTL=56
Reply from 212.58.244.71: bytes=32 time=35ms TTL=56
Reply from 212.58.244.71: bytes=32 time=43ms TTL=56
Reply from 212.58.244.71: bytes=32 time=59ms TTL=56
Reply from 212.58.244.71: bytes=32 time=42ms TTL=56
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=50ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56
Reply from 212.58.244.71: bytes=32 time=41ms TTL=56
Reply from 212.58.244.71: bytes=32 time=54ms TTL=56
Reply from 212.58.244.71: bytes=32 time=65ms TTL=56
Reply from 212.58.244.71: bytes=32 time=69ms TTL=56
Reply from 212.58.244.71: bytes=32 time=64ms TTL=56
Reply from 212.58.244.71: bytes=32 time=53ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=58ms TTL=56
Reply from 212.58.244.71: bytes=32 time=64ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=42ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=43ms TTL=56
Reply from 212.58.244.71: bytes=32 time=47ms TTL=56
Reply from 212.58.244.71: bytes=32 time=44ms TTL=56
Reply from 212.58.244.71: bytes=32 time=39ms TTL=56
Reply from 212.58.244.71: bytes=32 time=41ms TTL=56
Reply from 212.58.244.71: bytes=32 time=52ms TTL=56
Reply from 212.58.244.71: bytes=32 time=40ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=35ms TTL=56
Reply from 212.58.244.71: bytes=32 time=48ms TTL=56
Reply from 212.58.244.71: bytes=32 time=49ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=59ms TTL=56
Reply from 212.58.244.71: bytes=32 time=60ms TTL=56
Reply from 212.58.244.71: bytes=32 time=55ms TTL=56
Reply from 212.58.244.71: bytes=32 time=54ms TTL=56
Reply from 212.58.244.71: bytes=32 time=51ms TTL=56
Reply from 212.58.244.71: bytes=32 time=45ms TTL=56
Reply from 212.58.244.71: bytes=32 time=56ms TTL=56
Reply from 212.58.244.71: bytes=32 time=46ms TTL=56

Edited by HiPing (Wed 19-Dec-12 21:00:32)