High pings again

zappaDPJ · Jul 31, 2009, 16:30:33

Quote from: Rik on Jul 31, 2009, 16:08:51
Oh no you haven't.

Indeed, a browser plugin I installed this morning proved to be the weakest link. Sorted

Glenn · Jul 31, 2009, 16:33:25

Quote from: Rik on Jul 31, 2009, 15:59:23
Don't forget the user in this particular instance, Pup.

I olny fix things for a living, it was in my time off

Rik · Jul 31, 2009, 16:34:14

Rik · Jul 31, 2009, 16:34:25

Quote from: zappaDPJ on Jul 31, 2009, 16:30:33
Indeed, a browser plugin I installed this morning proved to be the weakest link. Sorted

Phew.

Ninny · Jul 31, 2009, 16:56:23

I had interleaving turned off a few weeks ago and was pleased with my new 30 ping. However, for the last week it's been back to where it was with interleaving turned on - 60+, but everything is reporting Fastpath/No interleaving as far as I can see. Obviously the system is compromised in some way as so many others are experiencing similar problems, my sync rate has been very low as well - around 2,000 when it was always 3,500, and I thought no interleaving INCREASED sync rate.

Rik · Jul 31, 2009, 16:58:54

Interleaving is only usually visible if you can sync at 8128, in which case it reduces maximum sync to 7160(?). Otherwise, you don't see it in the sync, so if that's dropped, it's usually local noise, either inside the house or on the line to the exchange.

MarkE · Jul 31, 2009, 17:02:16

tried a router reboot,alas things are still the same

1 <1 ms <1 ms <1 ms 192.168.0.1
2 182 ms 78 ms 94 ms telehouse-gw2-lo2.idnet.net [212.69.63.55]
3 84 ms 81 ms 93 ms telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]

4 104 ms 107 ms 113 ms lonap2.enta.net [193.203.5.135]
5 102 ms 93 ms 85 ms te5-3.gs1.core.enta.net [78.33.35.218]
6 108 ms 99 ms 101 ms te1-1.interxion.core.enta.net [87.127.236.86]
7 20 ms 25 ms 22 ms gi4-3.enta-transit.as35028.net [84.45.252.122]
8 22 ms 24 ms 26 ms www1.multiplay.co.uk [85.236.96.22]

Rik · Jul 31, 2009, 17:04:53

End-to-end times are OK though.

MarkE · Jul 31, 2009, 17:06:22

Quote from: Rik on Jul 31, 2009, 17:04:53
End-to-end times are OK though.

Which would suggest what Rik

Rik · Jul 31, 2009, 17:09:42

That router along the path may be busy and giving low priority to ping traffic.

MarkE · Jul 31, 2009, 17:29:21

Quote from: Rik on Jul 31, 2009, 17:09:42
That router along the path may be busy and giving low priority to ping traffic.

ah ok well thanks for that Rik.

Well no phone call back from support as was promised,guess this is the right way to treat customers who have requested a mac code and will be leaving??So well done idnet,if ever a customer would have come back,that is unlikely now.

cannot help but feel customer service and support has taken massive nose dive lately,which is just the reason pages back when I said it was pointless getting in touch with them and someone suggested to "give it a try what do you have to lose" I some how knew this would be the end product.

Given the amount of gamers I recommended idnet to and who have subsequently migrated when we had the last ping debacle,also with the apparent poor customer relations/support of late ,which for me was something I always felt Idnet prided themselves on,I feel rather saddened over all this.

It as if in some ways one of the last bastions of integrity (Idnet) is allowing itself to be eroded,how long now before it becomes just another average isp?

I cannot help but feel in the same boat and a lot of sympathy for the posts made by Dopamine regarding these issues.

Rik · Jul 31, 2009, 17:31:26

Do you know who you spoke to in support. They are short-handed today due to illness.

Rik · Jul 31, 2009, 17:34:42

You'll be getting a call back shortly, Mark...

Simon_idnet · Jul 31, 2009, 17:38:21

Hi Mark

Miriam is still trying to get off the phone to contact you. Sorry for the delay, we're short-staffed today. We're still working at trying to get the traffic balance optimised but this has been exacerbated today but the iPlayer Ashes traffic.

Regards
Simon

MarkE · Jul 31, 2009, 18:02:19

yes I just got off the phone with her.

She has told me she that you have optimized the network traffic some how?

I cannot thank you enough for doing so the difference is just utterly...non existent..

multiplay

Reply from 85.236.96.22: bytes=32 time=164ms TTL=124
Reply from 85.236.96.22: bytes=32 time=139ms TTL=124
Reply from 85.236.96.22: bytes=32 time=153ms TTL=124
Reply from 85.236.96.22: bytes=32 time=110ms TTL=124

Rik · Jul 31, 2009, 18:03:55

It may be that it's your exchange, Mark. Let us know if it improves when you migrate.

Mohux_Jnr · Jul 31, 2009, 18:15:46

Truly abysmal, exactly how long does the high ping thread have to get?.

Pinging www.idnet.net [212.69.36.10] with 32 bytes of data:
Reply from 212.69.36.10: bytes=32 time=139ms TTL=59
Reply from 212.69.36.10: bytes=32 time=185ms TTL=59
Reply from 212.69.36.10: bytes=32 time=163ms TTL=59
Reply from 212.69.36.10: bytes=32 time=167ms TTL=59

Ping statistics for 212.69.36.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 139ms, Maximum = 185ms, Average = 163ms

Rik · Jul 31, 2009, 18:20:48

What can I say, Mo? There's nothing we can do on this issue, except tell you what diagnostics are needed by support.

Mohux_Jnr · Jul 31, 2009, 18:35:41

I know Rik, I just like to vent, I have been in contact with support who have acknowledged it is a balancing issue. Unfortunately I am not technically minded enough to know what that means.

Surely the balancing is an automated process, why do I keep reading the Centrals have to be manually rebalanced?.

If the people that are suffering are having to rely on some poor sod assigning people to a central to rebalance the network its no wonder they have all gone sick

.

Rik · Jul 31, 2009, 18:43:28

It ought to be an automated process, Mo, and was till BT dropped a central a couple or so weeks ago. Everyone immediately re-connected to the other central and that became swamped. Given that most of us leave our routers on 24/7, that's left IDNet having to close off the congested central to new logins, then progressively kick people off the network so that they reconnect to the unoccupied central. The only problem with that is judging which people to move to get the balance just right, and it's that which has taken the time. They've thought they'd got there a few times, only to find that one or more of the people moved has maxed out their connection and thrown an inbalance again. Throw in the delay in BT's implementation of WBC, so that less people have moved to the hostlink than was expected by this time, and it's become a tightrope walk to get things just right again.

Simon_idnet · Jul 31, 2009, 19:35:22

It looks like we're getting back to normal levels now with 40% of network capacity currently not being used.
Simon

Azy · Jul 31, 2009, 20:19:57

on that news i rebooted the router (belkin N1 wireless router)

did a ping test

Ping has started ...

PING www.idnet.net (212.69.36.10): 56 data bytes
64 bytes from 212.69.36.10: icmp_seq=0 ttl=59 time=37.665 ms
64 bytes from 212.69.36.10: icmp_seq=1 ttl=59 time=33.129 ms
64 bytes from 212.69.36.10: icmp_seq=2 ttl=59 time=34.045 ms
64 bytes from 212.69.36.10: icmp_seq=3 ttl=59 time=35.184 ms
64 bytes from 212.69.36.10: icmp_seq=4 ttl=59 time=34.164 ms
64 bytes from 212.69.36.10: icmp_seq=5 ttl=59 time=34.335 ms
64 bytes from 212.69.36.10: icmp_seq=6 ttl=59 time=35.469 ms
64 bytes from 212.69.36.10: icmp_seq=7 ttl=59 time=34.660 ms
64 bytes from 212.69.36.10: icmp_seq=8 ttl=59 time=34.325 ms
64 bytes from 212.69.36.10: icmp_seq=9 ttl=59 time=36.117 ms

--- www.idnet.net ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 33.129/34.909/37.665/1.210 ms

its looking better and my sync is now 3487 instead of around 2800

Azy · Jul 31, 2009, 20:25:01

ment to include this in the last post

ping test at 2pm today

PING www.idnet.net (212.69.36.10): 56 data bytes
64 bytes from 212.69.36.10: icmp_seq=0 ttl=59 time=42.818 ms
64 bytes from 212.69.36.10: icmp_seq=1 ttl=59 time=47.606 ms
64 bytes from 212.69.36.10: icmp_seq=2 ttl=59 time=41.664 ms
64 bytes from 212.69.36.10: icmp_seq=3 ttl=59 time=41.890 ms
64 bytes from 212.69.36.10: icmp_seq=4 ttl=59 time=43.490 ms
64 bytes from 212.69.36.10: icmp_seq=5 ttl=59 time=130.244 ms
64 bytes from 212.69.36.10: icmp_seq=6 ttl=59 time=42.528 ms
64 bytes from 212.69.36.10: icmp_seq=7 ttl=59 time=43.042 ms
64 bytes from 212.69.36.10: icmp_seq=8 ttl=59 time=47.884 ms
64 bytes from 212.69.36.10: icmp_seq=9 ttl=59 time=41.962 ms

--- www.idnet.net ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 41.664/52.313/130.244/26.065 ms

mynnydd · Aug 01, 2009, 01:35:04

Quote from: Simon_idnet on Jul 31, 2009, 17:38:21
Hi Mark

Miriam is still trying to get off the phone to contact you. Sorry for the delay, we're short-staffed today. We're still working at trying to get the traffic balance optimised but this has been exacerbated today but the iPlayer Ashes traffic.
Regards
Simon

Network rail and 'wet leaves on the line' springs to mind.
For a tennis quote 'YOU CAN NOT BE SERIOUS'

Wags · Aug 01, 2009, 08:39:51

Pings are back to normal for me now after a few weeks of erratic behaviour. I hope it stays like this and others see some improvement soon.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Wags>ping multiplay.co.uk

Pinging multiplay.co.uk [85.236.96.22] with 32 bytes of data:

Reply from 85.236.96.22: bytes=32 time=14ms TTL=124
Reply from 85.236.96.22: bytes=32 time=15ms TTL=124
Reply from 85.236.96.22: bytes=32 time=14ms TTL=124
Reply from 85.236.96.22: bytes=32 time=14ms TTL=124

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