Ping problems on gw5/adsl max location poll

[Lance]

Lets hope they stay like that, Gary!

[Gary]

Lets hope they stay like that, Gary!

Agreed Lance, that's how they SHOULD be, time will tell if a pipe gets congested again pretty quickly. I think the thing that annoys me is I was told all this was my exchange and BT when it was actually IDNET and its balancing, saying that what's done is done, but I wish there had been more transparency and less bull, if you know what I mean!

[Lance]

Gary,

It still could be / have been your exchange as well. I know support can get very specific exchange congestion figures depending on the make of the equipment in the exchange.

[DarkStar]

Another one experiencing wildly fluctuating pings but before I post any PingGraphs am I correct in assuming that if my IDNet Logon Username is:   phone number @idnet.gw5 I am in fact on gw5?
Probably an obvious answer but I have come across seemingly obvious answers being wrong before, to my acute embarrassment   

[Lance]

That isn't the case now. The central you conect to is down to a round robin system so it could vary every time you connect.

[Gary]

Gary,

It still could be / have been your exchange as well. I know support can get very specific exchange congestion figures depending on the make of the equipment in the exchange.

I spoke with support yesterday Lance, I was told that the minimal level of exchange congestion would not have caused the throughput issues but it was in fact the congested IDNET pipe  lets just hope now

[Gary]

That isn't the case now. The central you conect to is down to a round robin system so it could vary every time you connect.

I think IDNET are limiting the number of users that log onto a pipe now to stop congestion, it seems more like balancing the network by hand is what has to be done.

[DarkStar]

That isn't the case now. The central you conect to is down to a round robin system so it could vary every time you connect.

How do I tell/know which central I am connected to at any given time ?

[Rik]

You can't, Ian.

[tomharrison]

Things seem to be looking more stable for me this morning :

Tracing route to www.idnet.net [212.69.36.10]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.0.1
  2    24 ms    24 ms    24 ms  telehouse-gw2-lo2.idnet.net [212.69.63.55]
  3    25 ms    24 ms    26 ms  telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]

  4    26 ms    25 ms    25 ms  redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
  5    26 ms    25 ms    25 ms  redbus-gw1-fa2-0-300.idnet.net [212.69.63.225]
  6    27 ms    25 ms    25 ms  www.idnet.net [212.69.36.10]

Trace complete.

Hopefully the pings will remain as things are now .

[Rik]

That's what we're hoping, Tom.

[Simon_idnet]

I still have the same problem, and support have been next to useless at dealing with it - my ongoing fault and their efforts to deal with it apparently relegated to the bottom of the pile and forgotten about. In 4 years with Pipex (hardly a gold standard ISP), I needed to contact their support a handful of times. A year and a half with IDNet and I've lost count of the number of times I've needed to chase up ongoing problems. Yet is there actually a better ISP around? I'm not convinced, which is why I haven't asked for my MAC yet. What a shoddy industry the whole ISP business is.

It's such a shame to see an ISP go to pot like this. Whilst I sympathise that some of the problem might be outside of IDNet's network, I have no sympathy whatsoever for an ISP that allows its customer services department to ignore customer problems, either through uselessness or overwork. Expansion of their business should have been met with an adequate expansion of CS, as in today's market, especially at the expensive end of it, CS is the difference between retaining customers and losing them.

I can see from our records that James mailed you the following on 6th July:

"
Initial investigations indicate that this 'problem' is due to the upstream capacity being saturated, when an upload is initiated, which causes delays to the control packets that are regulating the flow of the download stream. i.e. if the speed of the upload could be limited to, say, 80% of the upstream capacity then that would leave enough bandwidth available for the download FTP process to signal back to the server that the data being downloaded has been correctly received in a timely manner. We are currently checking this hypothesis.
"

If you search the topic on Google you will find many references, such as:

http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm

I think the two threads below pretty much sum it up:

http://www.dslreports.com/forum/r22469770-Saturated-Uploads-affect-on-Download-Vice-versa
http://www.dslreports.com/forum/r21780890-Re-northeast-Concurrent-uploaddownload-transfer-slows-down-b

The ACKs for the download data flows are delayed because they get queued in the upload data stream. Almost by definition this only applies to circuits with asymmetric upload/download speeds. Some operating systems may perform better or worse, depending on how the TCP/IP stack is tuned.

I am sorry that you regard our service as shoddy. I do not know of any other industry that delivers limitless expert assistance free of charge for a highly complex service that costs so little to subscribe to.

Regards
Simon

[tomharrison]

That's what we're hoping, Tom.

Hmm... just had to force a reboot of the router to get the UPnP working properly and on the resync my ping baseline has jumped 3ms Don't get me wrong, pings are still good but just seems a bit peculiar. Take a look:

Tracing route to www.idnet.net [212.69.36.10]
over a maximum of 30 hops:

  1     1 ms     1 ms     2 ms  192.168.0.1
  2    38 ms    33 ms    30 ms  telehouse-gw2-lo2.idnet.net [212.69.63.55]
  3    30 ms    27 ms    27 ms  telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]

  4    29 ms    31 ms    28 ms  redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
  5    29 ms    28 ms    28 ms  redbus-gw1-fa2-0-300.idnet.net [212.69.63.225]
  6    30 ms    28 ms    29 ms  www.idnet.net [212.69.36.10]

Trace complete.

Would this mean I'm connected to a different GW at IDNet or would it be some peculiarity in BT's network I wonder?

[Rik]

Either, Tom. As the newsfader suggests, IDNet are requesting people not to re-boot routers atm...

[tomharrison]

Either, Tom. As the newsfader suggests, IDNet are requesting people not to re-boot routers atm...

I know - it was an error on my part. Should have realised that making that change causes a reboot

[Rik]

Check with support, they will be able to see where you're connected (though it shouldn't be on the congested pipe).

[Dopamine]

I can see from our records that James mailed you the following on 6th July:

"
Initial investigations indicate that this 'problem' is due to the upstream capacity being saturated, when an upload is initiated, which causes delays to the control packets that are regulating the flow of the download stream. i.e. if the speed of the upload could be limited to, say, 80% of the upstream capacity then that would leave enough bandwidth available for the download FTP process to signal back to the server that the data being downloaded has been correctly received in a timely manner. We are currently checking this hypothesis.
"

If you search the topic on Google you will find many references, such as:

http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm

I think the two threads below pretty much sum it up:

http://www.dslreports.com/forum/r22469770-Saturated-Uploads-affect-on-Download-Vice-versa
http://www.dslreports.com/forum/r21780890-Re-northeast-Concurrent-uploaddownload-transfer-slows-down-b

The ACKs for the download data flows are delayed because they get queued in the upload data stream. Almost by definition this only applies to circuits with asymmetric upload/download speeds. Some operating systems may perform better or worse, depending on how the TCP/IP stack is tuned.

I am sorry that you regard our service as shoddy. I do not know of any other industry that delivers limitless expert assistance free of charge for a highly complex service that costs so little to subscribe to.

Regards
Simon

It doesn't say much for the service that the only way to get a further response to my problem is for me to post on this forum. Maybe the promised phone call, or an email to me, would have saved a lot of problems...

... oh wait. Haven't I already had a phone call from a member of your staff apologising profusely for your support department's failure to deal with another, separate, query of mine?

Whoops, silly me. It's not just one phoned apology, but a forum message too regarding a different forgotten issue....

... and yet another phone call with another apology for an error by your support staff.

I acknowledge that a service that is prepared to apologise so frequently for the errors it makes is great, but as a consumer I'd be a lot happier if you ditched the repeated apologies and sorted the bloody problems out, without me needing to keep chasing you up. Either that, or keep me informed of what's going on. The 6th of July was three weeks ago.

Welcome to the world of customer service in a competitive industry, where nothing much seems to have changed since August 2008:

Thanks very much for the information and your feedback, most appreciated. I understand your frustration and sincerely apologise that we failed to get back to you on two occasions - which is most unsual for us - I will investigate what happened and will keep you posted.

Needless to say, nobody got back to me.