Print Page - Network Latency on FTTC

Recently switched to a new provider for FTTC and when connecting to remote sites using RDP protocol there is terrible performance. Is there a way I can prove it is the ISP?

Have you run trace routes/pathping to the affected IP? Also I'd suggest using a looking glass (http://www.bgp4.net/lg) to see what kind of packet loss or latency you are getting on the return path.

Yes have run tracert and pathping which have sometimes shown issues. Was recommended WinMTR which has show issues I think. I have attached the MTR log file.

Using their looking glass to reverse trace to yourself?

https://www.myqubenet.net/lookingglass/ (https://www.myqubenet.net/lookingglass/)

Just done that now back to the public IP on the router. What's your view on this?

Router: BDR01.LN1
Command: traceroute 82.153.28.134

Tracing the route to 82.153.28.134
VRF info: (vrf in name/id, vrf out name/id)
1 xe-11-3-3.edge3.London2.Level3.net (195.50.91.197) 1 msec 1 msec 0 msec
2 ae-119-3505.edge4.London1.Level3.net (4.69.166.1) [AS 3356] 1 msec
ae-120-3506.edge4.London1.Level3.net (4.69.166.5) [AS 3356] 1 msec
ae-119-3505.edge4.London1.Level3.net (4.69.166.1) [AS 3356] 2 msec
3 195.50.122.126 [AS 3356] 1 msec 12 msec 2 msec
4 62.164.130.151 [AS 8897] 1 msec 1 msec 1 msec
5 82.153.28.134 [AS 12513] 12 msec 11 msec 11 msec

The reverse trace is fine. The WinWRT if I am reading it correctly rather high packet loss beyond hop 3 which would suggest a problem with eclipses network.

Done my own trace/pathping for comparison.

Code: [Select]

Tracing route to 81.91.248.51 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  gateway [192.168.1.254]
  2     8 ms     8 ms     8 ms  lo0.central10.psb-bng02.plus.net [195.166.130.253]
  3     8 ms     8 ms     9 ms  411.be6.psb-ir02.plus.net [84.93.253.111]
  4     9 ms     9 ms     8 ms  195.99.125.142
  5     9 ms     9 ms     9 ms  core4-hu0-2-0-4.faraday.ukcore.bt.net [195.99.127.70]
  6     8 ms     8 ms     8 ms  213.137.183.96
  7    10 ms     9 ms     9 ms  10-1-1.ear2.London2.Level3.net [212.187.139.177]
  8     8 ms     8 ms     8 ms  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170]
  9     8 ms     8 ms     8 ms  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198]
 10     9 ms     9 ms     9 ms  te-2-1.core1.ln1.qubenet.net [81.19.54.177]
 11     9 ms     8 ms     9 ms  81.91.248.51
 12    10 ms     9 ms     9 ms  81.91.248.51

Trace complete.

Code: [Select]

Tracing route to 81.91.248.51 over a maximum of 30 hops

  1  gateway [192.168.1.254]
  2  lo0.central10.psb-bng02.plus.net [195.166.130.253]
  3  411.be6.psb-ir02.plus.net [84.93.253.111]
  4  195.99.125.142
  5  core4-hu0-2-0-4.faraday.ukcore.bt.net [195.99.127.70]
  6  213.137.183.96
  7  10-1-1.ear2.London2.Level3.net [212.187.139.177]
  8  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170]
  9  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198]
 10  te-2-1.core1.ln1.qubenet.net [81.19.54.177]
 11  81.91.248.51
 12  81.91.248.51

Computing statistics for 300 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  gateway [192.168.1.254]
                                0/ 100 =  0%   |
  2    8ms     0/ 100 =  0%     0/ 100 =  0%  lo0.central10.psb-bng02.plus.net [195.166.130.253]
                                0/ 100 =  0%   |
  3    8ms     0/ 100 =  0%     0/ 100 =  0%  411.be6.psb-ir02.plus.net [84.93.253.111]
                                0/ 100 =  0%   |
  4    8ms    99/ 100 = 99%    99/ 100 = 99%  195.99.125.142
                                0/ 100 =  0%   |
  5    9ms    99/ 100 = 99%    99/ 100 = 99%  core4-hu0-2-0-4.faraday.ukcore.bt.net [195.99.127.70]
                                0/ 100 =  0%   |
  6   10ms     0/ 100 =  0%     0/ 100 =  0%  213.137.183.96
                                0/ 100 =  0%   |
  7    9ms     0/ 100 =  0%     0/ 100 =  0%  10-1-1.ear2.London2.Level3.net [212.187.139.177]
                                0/ 100 =  0%   |
  8   12ms     0/ 100 =  0%     0/ 100 =  0%  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170]
                                0/ 100 =  0%   |
  9    9ms     0/ 100 =  0%     0/ 100 =  0%  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198]
                                0/ 100 =  0%   |
 10   10ms     0/ 100 =  0%     0/ 100 =  0%  te-2-1.core1.ln1.qubenet.net [81.19.54.177]
                                0/ 100 =  0%   |
 11   10ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51
                                0/ 100 =  0%   |
 12    9ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51

Trace complete.

Interesting results. When I use tracert and pathping I get very different results.

Code: [Select]

Tracing route to 81.91.248.51 over a maximum of 30 hops

  1    <1 ms     1 ms    <1 ms  192.168.1.1 
  2     2 ms     1 ms     2 ms  192.168.20.1 
  3    14 ms     *       11 ms  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65] 
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11    12 ms    12 ms    12 ms  81.91.248.51 

Trace complete.

Code: [Select]

Tracing route to 81.91.248.51 over a maximum of 30 hops

  0  5259-PC.netgear.com [192.168.1.65] 
  1  192.168.1.1 
  2  192.168.20.1 
  3     *        *        *     
Computing statistics for 50 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           5259-PC.netgear.com [192.168.1.65] 
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1 
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  192.168.20.1 

Trace complete.

Hi elliotchandler

Please could I ask what you have running on 192.168.20.1

I ask because your gateway looks like 192.168.1.1, so I'm thinking your double nat'd

What is your ping result from router

Many thanks

John

Hi Yes, I have a Netgear Firewall FVS336G and then the VMG8324 so yes double NAT. Interesting I have rebooted the PC and the results are different.

Code: [Select]


Tracing route to 81.91.248.51 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  192.168.1.1 
  2     1 ms     1 ms     1 ms  192.168.20.1 
  3    12 ms    11 ms    12 ms  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65] 
  4    12 ms    13 ms    11 ms  86.54.135.72 
  5    12 ms    12 ms    12 ms  195.50.122.125 
  6    12 ms    12 ms    12 ms  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170] 
  7    12 ms    12 ms    12 ms  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198] 
  8    12 ms     *       12 ms  te-2-1.core1.ln1.qubenet.net [81.19.54.177] 
  9    12 ms    12 ms    12 ms  81.91.248.51 
 10    12 ms    13 ms    12 ms  81.91.248.51 

Trace complete.

Code: [Select]


Tracing route to 81.91.248.51 over a maximum of 30 hops

  0  5259-PC.netgear.com [192.168.1.65] 
  1  192.168.1.1 
  2  192.168.20.1 
  3  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65] 
  4  86.54.135.72 
  5  195.50.122.125 
  6  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170] 
  7  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198] 
  8  te-2-1.core1.ln1.qubenet.net [81.19.54.177] 
  9  81.91.248.51 
 10  81.91.248.51 

Computing statistics for 250 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           5259-PC.netgear.com [192.168.1.65] 
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1 
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  192.168.20.1 
                                0/ 100 =  0%   |
  3   11ms     0/ 100 =  0%     0/ 100 =  0%  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65] 
                                0/ 100 =  0%   |
  4   12ms    40/ 100 = 40%    40/ 100 = 40%  86.54.135.72 
                                0/ 100 =  0%   |
  5   12ms    79/ 100 = 79%    79/ 100 = 79%  195.50.122.125 
                                0/ 100 =  0%   |
  6   15ms    77/ 100 = 77%    77/ 100 = 77%  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170] 
                                0/ 100 =  0%   |
  7   12ms    62/ 100 = 62%    62/ 100 = 62%  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198] 
                                0/ 100 =  0%   |
  8   12ms    79/ 100 = 79%    79/ 100 = 79%  te-2-1.core1.ln1.qubenet.net [81.19.54.177] 
                                0/ 100 =  0%   |
  9   12ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51 
                                0/ 100 =  0%   |
 10   12ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51 

Trace complete.

What do you think now? Still looks like some packet loss on the path ping?

Also results from the router

Code: [Select]

PING 81.91.248.51 (81.91.248.51): 56 data bytes
64 bytes from 81.91.248.51: seq=0 ttl=121 time=31.491 ms
64 bytes from 81.91.248.51: seq=1 ttl=121 time=11.839 ms
64 bytes from 81.91.248.51: seq=2 ttl=121 time=11.621 ms
64 bytes from 81.91.248.51: seq=3 ttl=121 time=11.754 ms

--- 81.91.248.51 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 11.621/16.676/31.491 ms

Code: [Select]

traceroute to 81.91.248.51 (81.91.248.51), 30 hops max, 38 byte packets
 1  lo0_ecldsl-bba1.gs1.eclipse.net.uk (82.153.1.65)  14.085 ms  10.883 ms  11.129 ms
 2  86.54.135.72 (86.54.135.72)  11.463 ms  11.383 ms  11.456 ms
 3  195.50.122.125 (195.50.122.125)  11.139 ms  11.687 ms  11.852 ms
 4  ae-11-vl-3101.edge3.London2.Level3.net (4.69.202.170)  11.150 ms  34.453 ms  11.362 ms
 5  te0-1-0.bdr02.ln1.qubenet.net (195.50.91.198)  11.502 ms  11.468 ms  35.122 ms
 6  te-2-1.core1.ln1.qubenet.net (81.19.54.177)  11.207 ms  11.780 ms  11.548 ms
 7  81.91.248.51 (81.91.248.51)  11.513 ms  13.966 ms  11.489 ms
 8 * * *
 9 * * *
10 * * *
11 * * *
12 * * *
----Traceroute end----

Thoughts on this info?

Hi

Many thanks

Yes, there is packet loss, most likely due to contention on the pipe at eclipse, where it starts. Please be aware though, edge systems are designed to drop pings if busy or low priority and usage is above

Here is mine from mobile

I would contact your provider with the pathping results and raise it as an issue

Many thanks

John

--- Trace to 81.91.248.51 ---

1) 192.168.1.1 (192.168.1.1) 44.111 ms, 17/17 ps, 0.0% loss
2) host81-148-160-1.in-addr.btopenworld.com (81.148.160.1) 54.010 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
3) 213.120.182.141 (213.120.182.141) 51.694 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
4) 213.120.161.82 (213.120.161.82) 41.908 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
5) 213.120.182.65 (213.120.182.65) 36.304 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
6) 31.55.164.107 (31.55.164.107) 48.911 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
7) 109.159.248.63 (109.159.248.63) 44.707 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
8) core2-te0-3-0-3.ealing.ukcore.bt.net (109.159.248.150) 30.981 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
9) peer5-te0-9-0-9.telehouse.ukcore.bt.net (62.172.102.5) 31.101 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
10) t2c4-et-8-1-0-0.uk-lon1.eu.bt.net (166.49.211.248) 42.373 ms, 15/16 ps, 6.2% loss [AS 5400] United Kingdom
11) 5-2-1.ear2.london15.level3.net (212.187.173.89) 52.745 ms, 13/16 ps, 18.8% loss [AS 3356] United Kingdom
12) ae-12-vl-3201.edge3.london2.level3.net (4.69.202.178) 66.303 ms, 16/16 ps, 0.0% loss [AS 3356] European Union
13) te0-1-0.bdr02.ln1.qubenet.net (195.50.91.198) 109.393 ms, 16/16 ps, 0.0% loss [AS 3356] United Kingdom
14) te-2-1.core1.ln1.qubenet.net (81.19.54.177) 120.216 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom
15) 81.91.248.51 (81.91.248.51) 93.412 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom
16) 81.91.248.51 (81.91.248.51) 80.957 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom

Hi, I am on Zen and from what I can tell this does seem to be an Eclipse issue. I was with Eclipse about 18 months ago and was very dissatisfied with their service. Here is my tracert on Zen:

Tracing route to 81.91.248.51 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 192.168.0.1
2 19 ms 19 ms 19 ms losubs.subs.bng2.th-lon.zen.net.uk [62.3.80.21]
3 20 ms 21 ms 20 ms ae1-183.cr2.th-lon.zen.net.uk [62.3.86.82]
4 20 ms 20 ms 20 ms ge-3-3-0.mpr1.lhr3.uk.above.net [195.66.236.76]
5 19 ms 19 ms 19 ms ae11.mpr1.lhr1.uk.zip.zayo.com [64.125.27.49]
6 20 ms 19 ms 20 ms te-0-2-0.bdr01.ln2.qubenet.net [94.31.38.114]
7 20 ms 20 ms 20 ms te-0-1-0.core1.th1.qubenet.net [81.19.54.185]
8 21 ms 20 ms 19 ms te-2-5.core2.ln1.qubenet.net [81.19.53.49]
9 19 ms 19 ms 19 ms te-2-8.core1.ln1.qubenet.net [81.19.54.149]
10 21 ms 20 ms 19 ms 81.91.248.51
11 22 ms 20 ms 21 ms 81.91.248.51

Trace complete.

Thanks for the replies. In the pathping it shows a response time much higher than the previous 3 lines.

4 12ms 40/ 100 = 40% 40/ 100 = 40% 86.54.135.72

Is this the eclipse network? Is there were the pipe is being throttled?

Why doesn't the tracert show an issue?

Quote from: d2d4j on February 12, 2017, 03:09:54 PM

Hi

Many thanks

Yes, there is packet loss, most likely due to contention on the pipe at eclipse, where it starts. Please be aware though, edge systems are designed to drop pings if busy or low priority and usage is above

Here is mine from mobile

I would contact your provider with the pathping results and raise it as an issue

Many thanks

John

--- Trace to 81.91.248.51 ---

1) 192.168.1.1 (192.168.1.1) 44.111 ms, 17/17 ps, 0.0% loss
2) host81-148-160-1.in-addr.btopenworld.com (81.148.160.1) 54.010 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
3) 213.120.182.141 (213.120.182.141) 51.694 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
4) 213.120.161.82 (213.120.161.82) 41.908 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
5) 213.120.182.65 (213.120.182.65) 36.304 ms, 17/17 ps, 0.0% loss [AS 2856] United Kingdom
6) 31.55.164.107 (31.55.164.107) 48.911 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
7) 109.159.248.63 (109.159.248.63) 44.707 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
8) core2-te0-3-0-3.ealing.ukcore.bt.net (109.159.248.150) 30.981 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
9) peer5-te0-9-0-9.telehouse.ukcore.bt.net (62.172.102.5) 31.101 ms, 16/16 ps, 0.0% loss [AS 2856] United Kingdom
10) t2c4-et-8-1-0-0.uk-lon1.eu.bt.net (166.49.211.248) 42.373 ms, 15/16 ps, 6.2% loss [AS 5400] United Kingdom
11) 5-2-1.ear2.london15.level3.net (212.187.173.89) 52.745 ms, 13/16 ps, 18.8% loss [AS 3356] United Kingdom
12) ae-12-vl-3201.edge3.london2.level3.net (4.69.202.178) 66.303 ms, 16/16 ps, 0.0% loss [AS 3356] European Union
13) te0-1-0.bdr02.ln1.qubenet.net (195.50.91.198) 109.393 ms, 16/16 ps, 0.0% loss [AS 3356] United Kingdom
14) te-2-1.core1.ln1.qubenet.net (81.19.54.177) 120.216 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom
15) 81.91.248.51 (81.91.248.51) 93.412 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom
16) 81.91.248.51 (81.91.248.51) 80.957 ms, 16/16 ps, 0.0% loss [AS 29668] United Kingdom

How did you carry out the above trace?

Hi elliotchandler

Many thanks and it's a little app for mobile called nice trace

Tracert only routes the path taken

Please be aware that most of the packet loss programs may go funny on results sometimes, so your always best to do 3 or 4, and it depends upon the time of day run, as each should give a slightly different answer

For issues with isp, I would always use pathping over any apps/programs, and best to be run hardwired not wifi

You can lookup a Whois on the IP address to see the AS number, but Whois normally show the provider name

Many thanks

John

Thanks for the update. I have been running tracert, pathping and WinMTR most the weekend on hardwire and pathping continues to show packet loss on hop 4.

Here is one the results but each one appears to be similar. I have looked up the IP on hop 4 and 5 and they both belong to kcom.

Code: [Select]

C:\Users\cwadmin>pathping 81.91.248.51

Tracing route to 81.91.248.51 over a maximum of 30 hops

  0  5259-PC.netgear.com [192.168.1.65]
  1  192.168.1.1
  2  192.168.20.1
  3  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65]
  4  86.54.135.72
  5  195.50.122.125
  6  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170]
  7  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198]
  8  te-2-1.core1.ln1.qubenet.net [81.19.54.177]
  9  81.91.248.51
 10  81.91.248.51

Computing statistics for 250 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           5259-PC.netgear.com [192.168.1.65]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  192.168.20.1
                                0/ 100 =  0%   |
  3   11ms     0/ 100 =  0%     0/ 100 =  0%  lo0_ecldsl-bba1.gs1.eclipse.net.uk [82.153.1.65]
                                0/ 100 =  0%   |
  4   12ms    41/ 100 = 41%    41/ 100 = 41%  86.54.135.72
                                0/ 100 =  0%   |
  5   12ms    77/ 100 = 77%    77/ 100 = 77%  195.50.122.125
                                0/ 100 =  0%   |
  6   20ms    67/ 100 = 67%    67/ 100 = 67%  ae-11-vl-3101.edge3.London2.Level3.net [4.69.202.170]
                                0/ 100 =  0%   |
  7   12ms    75/ 100 = 75%    75/ 100 = 75%  te0-1-0.bdr02.ln1.qubenet.net [195.50.91.198]
                                0/ 100 =  0%   |
  8   16ms    77/ 100 = 77%    77/ 100 = 77%  te-2-1.core1.ln1.qubenet.net [81.19.54.177]
                                0/ 100 =  0%   |
  9   12ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51
                                0/ 100 =  0%   |
 10   12ms     0/ 100 =  0%     0/ 100 =  0%  81.91.248.51

Trace complete.

Does this look like an ISP issue? Anything else I can do to raise it up to Eclipse?

Hi elliotchandler

Many thanks

To be honest, the issue is higher up then your equipment and therefore you can only raise an issue with your isp, who should then be able to confirm on their networks

You should be asked for the pathping results, or supply a few samples when opening the issue, to clearly show where the issue lies

Many thanks

John

pathping has a major flaw, when it hits a router that doesnt repond to pings it stops, since my dslam does that guess what happens when I path ping any internet address? :)

Code: [Select]

C:\Windows\system32>pathping bbc.co.uk

Tracing route to bbc.co.uk [212.58.244.23]
over a maximum of 30 hops:
  0  Chris-PC.HOME [192.168.1.124]
  1  PFSENSE.home [192.168.1.252]
  2     *        *        *
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           Chris-PC.HOME [192.168.1.124]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  PFSENSE.home [192.168.1.252]

Trace complete.

mtr is probably the best diagnostics tool for latency and loss testing.

Thanks to John and Chrysalis, very helpful.
I have been running WinMTR and it is showing 1% loss at the moment as I only just started it again a little while ago after restarting the PC. The loss is still showing at the same hop that pathping is showing. Is this the problem I am facing?

Code: [Select]

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 | 5721 | 5721 |    0 |    0 |    2 |    0 |
|                            192.168.20.1 -    0 | 5725 | 5725 |    1 |    1 |    4 |    1 |
|      lo0_ecldsl-bba1.gs1.eclipse.net.uk -    0 | 5719 | 5719 |   11 |   11 |   51 |   12 |
|                            86.54.135.72 -    1 | 5649 | 5630 |   11 |   12 |  110 |   11 |
|                          195.50.122.125 -    0 | 5720 | 5720 |   11 |   12 |   59 |   11 |
|  ae-11-vl-3101.edge3.London2.Level3.net -    0 | 5720 | 5720 |   11 |   14 |   81 |   11 |
|           te0-1-0.bdr02.ln1.qubenet.net -    0 | 5720 | 5720 |   11 |   11 |   24 |   12 |
|            te-2-1.core1.ln1.qubenet.net -    0 | 5719 | 5719 |   11 |   13 |  215 |   12 |
|                            81.91.248.51 -    0 | 5719 | 5719 |   11 |   12 |   48 |   12 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Quote from: d2d4j on February 12, 2017, 03:09:54 PM

Yes, there is packet loss, most likely due to contention on the pipe at eclipse, where it starts. Please be aware though, edge systems are designed to drop pings if busy or low priority and usage is above

Is there?

9 12ms 0/ 100 = 0% 0/ 100 = 0% 81.91.248.51
0/ 100 = 0% |
10 12ms 0/ 100 = 0% 0/ 100 = 0% 81.91.248.51

Looks clean to me? I would strongly caution against reading too much into the intermediate hops. They don't matter as long as there's no loss to the destination.

Thanks Ignitionnet, based on your understanding where could the issue be with the network latency I am feeling with RDP sessions?

Just wanted to add latest WinMTR log for reference. Could there still be an issue as it does seem to show loss? And also high latency on hope 4 and 8?

Code: [Select]

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 | 9960 | 9960 |    0 |    0 |    3 |    0 |
|                            192.168.20.1 -    0 | 9965 | 9965 |    1 |    1 |    5 |    1 |
|      lo0_ecldsl-bba1.gs1.eclipse.net.uk -   10 | 7233 | 6549 |   11 |   11 |   51 |   12 |
|                            86.54.135.72 -    6 | 8109 | 7642 |   11 |   12 |  242 |   12 |
|                          195.50.122.125 -    6 | 8123 | 7662 |   11 |   12 |   59 |   11 |
|  ae-11-vl-3101.edge3.London2.Level3.net -    9 | 7415 | 6776 |   11 |   14 |   91 |   12 |
|           te0-1-0.bdr02.ln1.qubenet.net -   10 | 7243 | 6561 |   11 |   11 |   24 |   12 |
|            te-2-1.core1.ln1.qubenet.net -    9 | 7524 | 6913 |   11 |   13 |  215 |   14 |
|                            81.91.248.51 -   10 | 7262 | 6585 |   11 |   12 |   48 |   12 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Hi elliotchandler

Many thanks

As ignition has said, your final destination is clear, and the loss is on edge systems, which are designed to drop (usually on loading)

However, my experience where eclipse is concerned has never been favourable, but I'm reticent to say that, as I don't believe in saying bad things.

When you say RDC performance poor, how exactly do you mean (video is definitely do not use, pictures will come in blocks) but general office usage should be excellent (word, excell email etc)

Have you tweaked your RDC and terminal

I guess if general office use is not good, and/or your previous FTTC provider did not portray same experience, then it is likely to be eclipse

Those are my thoughts

Many thanks

John

Thanks John for your comments.

The RDC (or RDP) experience was very good with office usage, word, excel, Outlook and such with previous provider which was BT Business. Haven't made any tweaks to RDC as it was working fine before with previous provider. Just frustrated with heavy lagging when using standard business applications and also when typing sometimes have to wait up to a minute before the input shows on the screen. :(

Kitz Forum

Broadband Related => FTTC and FTTP Issues => Topic started by: elliottchandler on February 11, 2017, 11:10:04 AM