50M : Think Broadband Ping Monitor Results (POST YOURS)

[Chrysalis]

I dont know why the blue is as thick as it is, I suspect its due to how BT have setup their network, as there is multiple gateways used so the route changes a lot meaning a slight variance of latency. Thats my theory anyway. I havent really seen it on other infinity graphs except my own, but its like that regardless of router/modem used, and it is fast path.

In reality tho its nothing noticeable eg. here is 20 pings to the bbc.

C:\windows\system32>ping -n 20 bbc.co.uk

Pinging bbc.co.uk [212.58.241.131] with 32 bytes of data:
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=14ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=14ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241
Reply from 212.58.241.131: bytes=32 time=13ms TTL=241

Ping statistics for 212.58.241.131:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 14ms, Average = 13ms

and the VM connection ouch!! these from the router as pc is routed via infinity now.

root@DD-WRT:~# ping -c 20 bbc.co.uk
PING bbc.co.uk (212.58.241.131): 56 data bytes
64 bytes from 212.58.241.131: seq=0 ttl=243 time=53.757 ms
64 bytes from 212.58.241.131: seq=1 ttl=243 time=47.533 ms
64 bytes from 212.58.241.131: seq=2 ttl=243 time=70.545 ms
64 bytes from 212.58.241.131: seq=3 ttl=243 time=63.817 ms
64 bytes from 212.58.241.131: seq=4 ttl=243 time=46.166 ms
64 bytes from 212.58.241.131: seq=5 ttl=243 time=60.768 ms
64 bytes from 212.58.241.131: seq=6 ttl=243 time=56.487 ms
64 bytes from 212.58.241.131: seq=7 ttl=243 time=51.291 ms
64 bytes from 212.58.241.131: seq=8 ttl=243 time=67.092 ms
64 bytes from 212.58.241.131: seq=9 ttl=243 time=62.213 ms
64 bytes from 212.58.241.131: seq=10 ttl=243 time=62.377 ms
64 bytes from 212.58.241.131: seq=11 ttl=243 time=72.610 ms
64 bytes from 212.58.241.131: seq=12 ttl=243 time=87.686 ms
64 bytes from 212.58.241.131: seq=13 ttl=243 time=44.083 ms
64 bytes from 212.58.241.131: seq=14 ttl=243 time=60.484 ms
64 bytes from 212.58.241.131: seq=15 ttl=243 time=39.236 ms
64 bytes from 212.58.241.131: seq=16 ttl=243 time=50.586 ms
64 bytes from 212.58.241.131: seq=17 ttl=243 time=52.222 ms
64 bytes from 212.58.241.131: seq=18 ttl=243 time=60.116 ms
64 bytes from 212.58.241.131: seq=19 ttl=243 time=51.516 ms

--- bbc.co.uk ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 39.236/58.029/87.686 ms

I honestly believe VM have area's for whatever reason they dont upgrade unless they really have to, clearly the pattern I have seen on websites such as this is some areas getting upgrades semi regurly whilst others once every 5 years or so. The only time I remember a proper upgrade done in my area in almost 8 years of using ntl/VM is when the upstream work was done to make the service 10:1 which was 2 years ago. Also a reseg around the same time period which was probably part of the same work. Other then that in 8 years I cannot remember a single outage followed by a noticeable improvement that lasted more than a month or 2. Ignition has eg. commented in the past also that VM may stick to just customer numbers so if a port doesnt have many customers but a lot of them are heavy torrent users pushing utilisation high, it doesnt get an upgrade. I dont know the exact specifics except in the past a few times I couldnt connect the modem because too many modems were connected and that this utilisation issue has plagued my area for nearly 10 years at 2 different address's. With one good spell of 6 months or so following that one bit of upgrade work I mentioned. I honestly would not be surprised one bit if its like this next year and even worse if they bump the upload speeds back to 10:1 without any upgrade work, wouldnt surprise me one bit. Whats funny is last week my area was supposed to have 2nd set of major upgrades finished with a 3rd set at end of this month, the first 2 sets made no appparent difference and caused no outage, invisible upgrades

---------- Post added at 16:45 ---------- Previous post was at 16:28 ----------

here is a graph to go with those pings.

todays

[BeerCanSandwich]

I don't know, I recon your latency could be a couple lower, I'm in wolverhamptom and get 10-11ms when interleving is off.

Damn, it's something when an idle VM connection is poorer than a FTTC connection which has it's upload saturated. The average is over twice as much on VM.

ping.exe -n 20 bbc.co.uk

Pinging bbc.co.uk [212.58.241.131] with 32 bytes of data:

Reply from 212.58.241.131: bytes=32 time=27ms TTL=241
Reply from 212.58.241.131: bytes=32 time=39ms TTL=241
Reply from 212.58.241.131: bytes=32 time=25ms TTL=241
Reply from 212.58.241.131: bytes=32 time=41ms TTL=241
Reply from 212.58.241.131: bytes=32 time=45ms TTL=241
Reply from 212.58.241.131: bytes=32 time=37ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=45ms TTL=241
Reply from 212.58.241.131: bytes=32 time=25ms TTL=241
Reply from 212.58.241.131: bytes=32 time=29ms TTL=241
Reply from 212.58.241.131: bytes=32 time=35ms TTL=241
Reply from 212.58.241.131: bytes=32 time=32ms TTL=241
Reply from 212.58.241.131: bytes=32 time=32ms TTL=241
Reply from 212.58.241.131: bytes=32 time=43ms TTL=241
Reply from 212.58.241.131: bytes=32 time=24ms TTL=241
Reply from 212.58.241.131: bytes=32 time=31ms TTL=241
Reply from 212.58.241.131: bytes=32 time=35ms TTL=241
Reply from 212.58.241.131: bytes=32 time=32ms TTL=241
Reply from 212.58.241.131: bytes=32 time=35ms TTL=241
Reply from 212.58.241.131: bytes=32 time=35ms TTL=241

Ping statistics for 212.58.241.131:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 45ms, Average = 33ms

Compared to idle

ping.exe -n 20 bbc.co.uk

Pinging bbc.co.uk [212.58.241.131] with 32 bytes of data:

Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=19ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241
Reply from 212.58.241.131: bytes=32 time=18ms TTL=241

Ping statistics for 212.58.241.131:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 19ms, Average = 18ms

Whatever VM's reasons for the prolonged poor performance it's not really acceptable and I feel for those not yet covered by FTTC.

[Sirius]

Glad to see the hump has not come back for a good few weeks

[dwarven]

Typical,

Had a power outage earlier today and now I cannot get back on the Upstream channel I had. Ah well had a couple of days of good service

[qasdfdsaq]

Originally Posted by dwarven

Typical,

Had a power outage earlier today and now I cannot get back on the Upstream channel I had. Ah well had a couple of days of good service

See another advantage of FTTC, all the active equipment has backup power so your connection isn't affected by power outages.

[Chrysalis]

Originally Posted by BeerCanSandwich

I don't know, I recon your latency could be a couple lower, I'm in wolverhamptom and get 10-11ms when interleving is off.

it could be lower if my routing was direct to london, many people dont understand latency is dependent on distance and assume every location has a direct path to london, not the case.

BT's WBC has no node in my city I either go via peterborough (my shortest route) or via birmingham. Both require going north before south.

However 2ms latency isnt going to be a big deal, whats most important is jitter and if latency is not insanely high, I would be unhappy with 30ms but not unhappy with 13ms.

---------- Post added at 02:29 ---------- Previous post was at 02:20 ----------

Originally Posted by BeerCanSandwich

Whatever VM's reasons for the prolonged poor performance it's not really acceptable and I feel for those not yet covered by FTTC.

When you put it like this it shows how bad VM is.

Basically it took BT 11 months to rollout FTTC in my area after the decision made to enable the area, whilst it takes VM longer then that just to upgrade existing services. The former would have required far more physical work.

I have a dedicated 20mbit/sec upstream path on my vdsl2 connection up to the backhaul level at the exchange, my VM connection is shared with 100s of users on its 18mbit upstream path.

I would hazard a guess my area requires the level of work that was required to fix brighton, but there is not the level of fuss been created by media and users on VM's own forums that brighton had so it probably wont get done. Even then in brighton it took them years to fix due to the sheer size of the task having not done proper upgrades for so long.

[qasdfdsaq]

Originally Posted by Chrysalis

Basically it took BT 11 months to rollout FTTC in my area after the decision made to enable the area, whilst it takes VM longer then that just to upgrade existing services. The former would have required far more physical work.

Not neccessarily.

Openreach installing a new FTTC cab would as far as possible blow fibre down existing ducts to the existing cab. VM adding capacity via a new optical node would do the same.

Openreach installing a new FTTC cab would dig up the road to obtain power from the nearest available source. VM adding capacity via a new optical node wouldn't necessarily have to do that, but if they did, the would do the same.

Openreach would then have to install cross-connects from the existing cab to the new cab. VM adding capacity via a new optical node would do the same.

If existing VM infrastructure is at capacity, then they have to go through all the same routine as Openreach do installing a new cab - including planning permissions, civil works, road closures, etc.

Course if there's existing capacity available that's not being used, bringing it online is fairly trivial in comparison.

[Chrysalis]

Originally Posted by qasdfdsaq

Not neccessarily.

Openreach installing a new FTTC cab would as far as possible blow fibre down existing ducts to the existing cab. VM adding capacity via a new optical node would do the same.

Openreach installing a new FTTC cab would dig up the road to obtain power from the nearest available source. VM adding capacity via a new optical node wouldn't necessarily have to do that, but if they did, the would do the same.

Openreach would then have to install cross-connects from the existing cab to the new cab. VM adding capacity via a new optical node would do the same.

If existing VM infrastructure is at capacity, then they have to go through all the same routine as Openreach do installing a new cab - including planning permissions, civil works, road closures, etc.

Course if there's existing capacity available that's not being used, bringing it online is fairly trivial in comparison.

yeah 18 months to add a new US channel must be really physically demanding :p

[buckleb]

Looking good in my part of Crawley, probably the best its ever been.

Another upstream channel was added recently, which seems to have smoothed things out.

The two spikes are, I think, when I was downloading.

[Kymmy]

Can I remind members that there is a thread for non-VM TBB charts and that they should be using it to post such charts. Last 2 posts moved

[Risco]

Originally Posted by Foo Fighter

Any ideas what i can do? im suddenly getting wooped in black ops so check out think bb and its awful.
[img]Download Failed (1)[/img]

[img]Download Failed (1)[/img]

[img]Download Failed (1)[/img]

[img]Download Failed (1)[/img]

Nah, you just suck at Black Ops.

[Wildean]

This is a representative sample of the results I get.

[IMG][/IMG]


The green blocks correspond exactly with the times I've been running uTorrent - not even downloading and upload speeds strictly limited, except between about 0130 and 1000 when I forgot to restart the program.

Without uTorrent, I get the following speeds:




If I restart uTorrent, after only a few minutes, I get:



I'm on the 100Mb service,

Do these results seem reasonable?

[Qtx]

Originally Posted by Wildean

Do these results seem reasonable?

No speed tests or ping results taken while torrents are running would be considered reliable or an indicator of anything useful. If you want more speed for non-torrent stuff then you need to limit connections or speed in your torrent client.

[cnewton2k]

Can someone tell me what this means and if is is bad!!!

[Chrysalis]

it means after 11pm something good happened and you had a huge improvement on your service,