Very slow accessing a particular remote system.

Started by jm_paulin, Apr 27, 2011, 08:37:49

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jm_paulin

Hi,

I have this problem when I am using a Remote WebClient to access a PC (like a remote desktop, but over the www). It is definitely a lot slower now than I am on FTTC than it was with my previous internet provider. To give you an idea, the user experience now is as bad as when I plug my cellphone in the laptop and connect using 3G.

How can we go at figuring out what is going wrong ?

Thanks.

JM

Steve

Is everything else ok on FTTC? i.e latency and speeds. Do you need ports to be forwarded for the remote desktop if so are they correct?
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin

Everything else is fine. Speed is 37.5/8 Mb, Ping 10ms via speedtest. iPlayer, Sky Anytime or other: no issues.
Same router as before, same rules.. so no changes there. Cannot blame NAT...
I did change the MTU on the PC to 1492 in case, but no significant changes...

It is really like if a particular route to a specific corporate site is really really slow... We are currently using the 3G phone as it is slightly faster...



Rik

Sorry, but I can't think of anything to explain it. I'd suggest you have a word with support.
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

Glenn

Are you able to try another remote client, eg, Logmein, there is a free version that you could test with?
Glenn
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

Steve

If it is an MTU issue using the (trying to remember windows )ping [IP] -f -l [MTU] and look for fragmentation
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin

I did change the MTU to 1492. But that had no effect.

I also contacted support, but did not have much luck there either. "IDNet gives me the best speed possible, the rest is up to the internet and IDNet has no control over it." I can somewhat understand that statement, but I did not have that issue last week when I was using Be to connect to that same site. So there must be something somewhere between IDNet and the www that has changed when I moved from Be.

Could contention ratio be part of it?

I saw that you can have `Traffic Priority` with some of the other more expensive packages. Would this change anything?


Rik

It would give you priority at the exchange - most commonly it shows up as lower ping times.
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin

ok. So technically, I moved from LLU to BT back at the exchange...

I guess I can give it a try, but I definitely do not want to be locked for 1 year if that does not help...

Otherwise, my options probably are:
- switch back to Be (what a laugh that would be)
- resign and get another job that only involve remote working to a location that can be reached with a suitable speed

Mind you: resigning is tempting.... got any open position going?


Rik

Yes, but you probably wouldn't like the pay here as we're all volunteers. ;)
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin

Ok, so I got my traceroute back from folks on Be.

So Be gets to the network in 10 hops,
Be goes straight to telefonica-wholesale.net (2 hops), & alter.net (5 hops). Rest being not identified.
time to alter.net is around 27ms

IDNet gets to the network in 15 hops
IDNet goes via cogentco.net (7 hops) & alter.net (5 hops). rest being IDNet
time to alter.net is around 160ms ???

Can that help anyone to understand ?

Glenn

JM, do you have an IP, I can run a tracert from my folks TT connection for you to compare.
Glenn
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin


Rik

I'm timing out:

tracert 199.67.203.80

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  192.168.1.254
  2    13 ms    11 ms    11 ms  212.69.63.51
  3    15 ms    11 ms    11 ms  212.69.63.245
  4    13 ms    13 ms    11 ms  149.6.148.205
  5    14 ms    13 ms    13 ms  130.117.50.117
  6    14 ms    11 ms    11 ms  130.117.0.61
  7    89 ms    90 ms    90 ms  154.54.5.122
  8    92 ms    90 ms    92 ms  154.54.44.37
  9    95 ms    95 ms    96 ms  154.54.1.233
10    96 ms    96 ms    98 ms  154.54.41.226
11    97 ms   128 ms    96 ms  154.54.10.226
12    97 ms    96 ms    96 ms  152.63.33.118
13    98 ms    98 ms    98 ms  152.63.43.69
14    99 ms    98 ms   102 ms  152.63.43.78
15   171 ms   177 ms   173 ms  146.188.14.162
16   172 ms   171 ms   171 ms  158.43.233.105
17   177 ms   171 ms   171 ms  158.43.47.174
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.
26     *        *        *     Request timed out.
27     *        *        *     Request timed out.
28     *        *        *     Request timed out.
29     *        *        *     Request timed out.
30     *        *        *     Request timed out.

Trace complete.

ping 199.67.203.80

Pinging 199.67.203.80 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 199.67.203.80:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

Lance

This is what I get over my work connection:

P:\>tracert 199.67.203.80

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.133.100.1
  2    <1 ms    <1 ms    <1 ms  10.132.1.13
  3     1 ms     2 ms     1 ms  10.132.1.94
  4    <1 ms    <1 ms    <1 ms  10.132.44.68
  5     1 ms    <1 ms     2 ms  94.101.168.2
  6     7 ms     5 ms     2 ms  94.101.168.249
  7     4 ms     5 ms     2 ms  ge-5-1-670.ipcolo2.London1.Level3.net [212.113.1
0.221]
  8     2 ms     2 ms     7 ms  ae-24-52.car3.London1.Level3.net [4.69.139.100]

  9     2 ms     2 ms     2 ms  mci-level3-ge.london1.Level3.net [4.68.63.154]
10     2 ms     2 ms     2 ms  so-3-2-0.XT1.LND2.ALTER.NET [146.188.3.249]
11     2 ms     2 ms     2 ms  POS6-0.GW3.LND2.ALTER.NET [158.43.233.105]
12     3 ms     3 ms     3 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]

13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.
Lance
_____

This post reflects my own views, opinions and experience, not those of IDNet.

jm_paulin

I do expect the timeout at the end because the end route is heavily firewalled. However, the visible part of the route is quite different...

I am not saying one is wrong, but there is obviously room for better routing once we leave the IDNet network. right?

JM


pctech

Just for comparison from a different ISP connection here is a traceroute from me too (connection is ADSL Max on Zen Internet)

Tracing route to 199.67.203.80 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  (first address removed because it is fixed routable IP)
  2    23 ms    23 ms    22 ms  losubs.subs.dsl2.th-lon.zen.net.uk [62.3.84.21]

  3    23 ms    22 ms    22 ms  ae0-114.cr1.th-lon.zen.net.net [62.3.84.185]
  4    22 ms    23 ms    23 ms  sl-gw10-lon-12-019.sprintlink.net [82.195.189.65
]
  5    22 ms    23 ms    22 ms  sl-bb22-lon-9-0-0.sprintlink.net [213.206.128.60
]
  6    23 ms    22 ms    22 ms  sl-bb20-lon-12-0-0.sprintlink.net [213.206.128.5
2]
  7    23 ms    22 ms    23 ms  so-1-2-1.BR2.LND9.ALTER.NET [146.188.35.137]
  8    24 ms    23 ms    23 ms  so-3-2-0.XT2.LND9.ALTER.NET [146.188.5.201]
  9    29 ms    30 ms    30 ms  ge-0-1-0.XT1.LND2.ALTER.NET [146.188.14.161]
10    30 ms    30 ms    29 ms  POS6-0.GW3.LND2.ALTER.NET [158.43.233.105]
11    31 ms    30 ms    30 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]

12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.


jameshurrell

Something very odd going on. I am assuming that IP address is physically located in the UK? When I tracert this from my IDNet connection, it appears to cross the pond to the US (hops 7 - 14) and then come back to London (hops 15 and 16). That would be a reason for the delay on remote desktop  ;D :

Tracing route to 199.67.203.80 over a maximum of 30 hops

 1    <1 ms    <1 ms    <1 ms  office.router [192.168.0.1]
 2    26 ms    27 ms    25 ms  telehouse-gw4-lo2.idnet.net [212.69.63.99]
 3    26 ms    27 ms    25 ms  telehouse-gw5-e4-400.idnet.net [212.69.63.245]
 4    27 ms    25 ms    27 ms  gi8-27.mpd01.lon02.atlas.cogentco.com [149.6.148.205]
 5    26 ms    27 ms    27 ms  te1-2.ccr02.lon02.atlas.cogentco.com [130.117.50.117]
 6    25 ms    28 ms    29 ms  te8-3.ccr01.lon01.atlas.cogentco.com [130.117.0.61]
 7   104 ms   103 ms   103 ms  te0-3-0-4.ccr22.bos01.atlas.cogentco.com [154.54.5.122]
 8   103 ms   102 ms   103 ms  te0-3-0-2.ccr21.jfk02.atlas.cogentco.com [154.54.44.45]
 9   111 ms   109 ms   110 ms  te0-1-0-7.ccr21.dca01.atlas.cogentco.com [154.54.26.6]
10   110 ms   111 ms   110 ms  te0-2-0-1.ccr21.iad02.atlas.cogentco.com [154.54.1.78]
11   108 ms   110 ms   109 ms  verizon.iad01.atlas.cogentco.com [154.54.12.46]
12   110 ms   111 ms   109 ms  0.ae2.XL4.IAD8.ALTER.NET [152.63.41.234]
13   113 ms   143 ms   139 ms  0.xe-3-2-0.IL2.DCA6.ALTER.NET [152.63.43.81]
14   113 ms   114 ms   123 ms  0.ge-1-2-0.IL2.DCA4.ALTER.NET [152.63.43.90]
15   190 ms   192 ms   189 ms  so-1-0-0.XT1.LND2.ALTER.NET [146.188.14.217]
16   186 ms   187 ms   188 ms  POS0-0.GW3.LND2.ALTER.NET [158.43.233.109]
17   189 ms   189 ms   187 ms  homepage01-gw.customer.uk.uu.net [158.43.47.174]
18     *        *        *     Request timed out.
19     *        *    

From a BT retail connection, it remains in the UK.

Something amiss somewhere, but it looks like a problem between Cogent and Alter.net...

Steve

Sounds like a good question to ask to support. ;)
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

pctech

Does appear to take a rather long way round but to be fair to IDNet this is due to Cogent's routing policy for that particular network/IP

jameshurrell

Quote from: pctech on Apr 27, 2011, 14:50:01
Does appear to take a rather long way round but to be fair to IDNet this is due to Cogent's routing policy for that particular network/IP

Agreed.

Lance

IDNet should be able to get the routing changed if you ask them and show them the tracert.
Lance
_____

This post reflects my own views, opinions and experience, not those of IDNet.

sof2er

From my experience with previous ISP's and IDNet if I had a ping problem it always ended up with a hop involving cogentco...

jm_paulin

Just called IDNet support.

Looks like they will take a copy of the traceroute in this thread and send that to Cogent. I guess we can only wait to see if cogent can act on it....

Thanks to all the traceroute from the various Internet provider in this thread.

JM

Rik

Glad we could help. Let us know how it goes.
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.