Crystal Web ADSL performance feedback thread Part 3...

Status
Not open for further replies.
Turns out he had your first names mixed up in his head. Profusely apologised for the mix-up there, biometrics.
 
Zenbaas said:
Ok I'm a 10MB premium uncapped user here. How does the xtreme tth compare price wise and what is on offer in equivalent pricing terms? (if anything) Also staying in an apartment block so need to know if it's worthwhile bothering the neighbours with this :)
Click to expand...
Bumpity bump.
 
requiem said:
Not actually sure. Sorry for such a vague request.

Can you dazzle me with the performance?
Click to expand...

D:\Users\micro>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router [10.0.0.1]
2 <1 ms <1 ms <1 ms 196-212-61-1.dynamic.ftth.broadband.is [196.212.61.1]
3 <1 ms 1 ms <1 ms cdsl1-rba-vl151.ip.isnet.net [196.38.73.18]
4 1 ms 1 ms <1 ms cdsl1-rba-vl150.ip.isnet.net [196.38.73.17]
5 1 ms 4 ms 2 ms core1b-pkl-te0-0-0-0.ip.isnet.net [196.26.0.62]
6 1 ms 1 ms <1 ms pr2-pkl-xe-2-2-0.ip.isnet.net [168.209.1.179]
7 1 ms 1 ms 1 ms 72.14.205.16
8 1 ms 2 ms 1 ms 72.14.239.53
9 1 ms 1 ms 1 ms google-public-dns-a.google.com [8.8.8.8]

D:\Users\micro>tracert www.google.co.uk

Tracing route to www.google.co.uk [172.217.3.195]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router [10.0.0.1]
2 <1 ms <1 ms <1 ms 196-212-61-1.dynamic.ftth.broadband.is [196.212.61.1]
3 1 ms 1 ms <1 ms cdsl1-rba-vl151.ip.isnet.net [196.38.73.18]
4 <1 ms 1 ms <1 ms cdsl1-rba-vl150.ip.isnet.net [196.38.73.17]
5 3 ms 3 ms 2 ms core1-pkl-tg0-7-0-0.ip.isnet.net [168.209.1.162]
6 1 ms 1 ms <1 ms 196.26.0.130
7 1 ms 1 ms 1 ms 72.14.205.16
8 183 ms 179 ms 179 ms 66.249.95.8
9 160 ms 160 ms 160 ms 209.85.143.67
10 238 ms 238 ms 237 ms 216.239.42.223
11 262 ms 263 ms 263 ms 108.170.237.44
12 304 ms 307 ms 303 ms 72.14.233.183
13 304 ms 306 ms 304 ms 209.85.248.158
14 291 ms 291 ms 291 ms 209.85.245.207
15 305 ms 304 ms 304 ms 108.170.233.155
16 290 ms 290 ms 290 ms sea15s12-in-f3.1e100.net [172.217.3.195]




 
Sinbad said:
Tracing route to www.google.co.uk [172.217.3.195]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router [10.0.0.1]
2 <1 ms <1 ms <1 ms 196-212-61-1.dynamic.ftth.broadband.is [196.212.61.1]
3 1 ms 1 ms <1 ms cdsl1-rba-vl151.ip.isnet.net [196.38.73.18]
4 <1 ms 1 ms <1 ms cdsl1-rba-vl150.ip.isnet.net [196.38.73.17]
5 3 ms 3 ms 2 ms core1-pkl-tg0-7-0-0.ip.isnet.net [168.209.1.162]
6 1 ms 1 ms <1 ms 196.26.0.130
7 1 ms 1 ms 1 ms 72.14.205.16
8 183 ms 179 ms 179 ms 66.249.95.8
9 160 ms 160 ms 160 ms 209.85.143.67
10 238 ms 238 ms 237 ms 216.239.42.223
11 262 ms 263 ms 263 ms 108.170.237.44
12 304 ms 307 ms 303 ms 72.14.233.183
13 304 ms 306 ms 304 ms 209.85.248.158
14 291 ms 291 ms 291 ms 209.85.245.207
15 305 ms 304 ms 304 ms 108.170.233.155
16 290 ms 290 ms 290 ms sea15s12-in-f3.1e100.net [172.217.3.195]
Click to expand...

This one is a bit weird. Google ICMP to .co.uk should still peer off into the local servers. What DNS are you using because it looks like it is hopping the pond twice.
 
Crystal Web Management said:
This one is a bit weird. Google ICMP to .co.uk should still peer off into the local servers. What DNS are you using because it looks like it is hopping the pond twice.
Click to expand...

Using borderlessinternet.

Quite likely that it's going to a canadian google...

International speed tests aren't looking awesome tonight btw.
 
Crystal Web Management said:
This one is a bit weird. Google ICMP to .co.uk should still peer off into the local servers. What DNS are you using because it looks like it is hopping the pond twice.
Click to expand...

That's actually interesting. I should write a rule in the mikrotik that redirects google domains to a local dns...
 
Sinbad said:
Using borderlessinternet.

Quite likely that it's going to a canadian google...

International speed tests aren't looking awesome tonight btw.
Click to expand...

Your local speed test is wow.

Would you mind posting one to Europe (Amsterdam) and one to the US?
 
Sinbad said:
Using borderlessinternet.

Quite likely that it's going to a canadian google...

International speed tests aren't looking awesome tonight btw.
Click to expand...

OK borderless have had issues with their bandwidth so makes sense.

On international speedtests they grate me as they often don't reflect proper performance and we refuse to prioritise them like others do.

Check this speed http://releases.ubuntu.com/16.04.1/...torrent?_ga=1.163409084.1600833308.1472503839 as it will test UDP and if you watch the swarm will only serve from international sources. If there's discrepancy between this speed and your TCP connections then it could be a receive window limiting things which you can check here: https://www.measurementlab.net/tools/ndt/ (their tool is not right for speed and the rate limits on the connection are tiny but it will show tcp state). Anything other than 0% on receive window buffer is a problem and it will tell you if the machine Operating System is limiting TCP throughput as well. It also tries to point out if there is network congestion on the WAN side. Most of the time international throughput issues are a result of BDP WAN issues on TCP throughput which is often just an operating system hiccup. Windows recently tried to optimise their TCP stack in the latest releases but they aim for stability over speed so you may need to tweak TCP settings to get it right at all times.

And when in doubt, test over UDP with the Ubuntu which you can see swarms in from international sources. Then you can identify if it is network congestion on our end on of the pipe or somewhere closer to home.
 
Crystal Web Management said:
OK borderless have had issues with their bandwidth so makes sense.

On international speedtests they grate me as they often don't reflect proper performance and we refuse to prioritise them like others do.

Check this speed http://releases.ubuntu.com/16.04.1/...torrent?_ga=1.163409084.1600833308.1472503839 as it will test UDP and if you watch the swarm will only serve from international sources. If there's discrepancy between this speed and your TCP connections then it could be a receive window limiting things which you can check here: https://www.measurementlab.net/tools/ndt/ (their tool is not right for speed and the rate limits on the connection are tiny but it will show tcp state). Anything other than 0% on receive window buffer is a problem and it will tell you if the machine Operating System is limiting TCP throughput as well. It also tries to point out if there is network congestion on the WAN side. Most of the time international throughput issues are a result of BDP WAN issues on TCP throughput which is often just an operating system hiccup. Windows recently tried to optimise their TCP stack in the latest releases but they aim for stability over speed so you may need to tweak TCP settings to get it right at all times.

And when in doubt, test over UDP with the Ubuntu which you can see swarms in from international sources. Then you can identify if it is network congestion on our end on of the pipe or somewhere closer to home.
Click to expand...

Torrent is doing about 2.3 MB/sec

The borderless traffic is not being proxied btw... it doesn't explain the low speeds.
 
Sinbad said:
Torrent is doing about 2.3 MB/sec

The borderless traffic is not being proxied btw... it doesn't explain the low speeds.
Click to expand...


UPLOAD SPEED
3.93 Mb/s
DOWNLOAD SPEED
1.31 Mb/s
Network latency: 386 msec round trip time

Jitter: 52 msec

TEST AGAIN


TCP receive window: 2130432 current, 2195968 maximum
0.07 % of packets lost during test
Round trip time: 383 msec (minimum), 435 msec (maximum), 386 msec (average)
Jitter: -
0.00 seconds spend waiting following a timeout
TCP time-out counter: 589
170 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.

0.7482 % of the time was not spent in a receiver limited or sender limited state.
0.0000 % of the time the connection is limited by the client machine's receive buffer.
Optimal receive buffer: - bytes
Bottleneck link: -
158 duplicate ACKs set
 
Bear in mind that the net is built on TCP and unless the server has 1) sufficient bandwidth on their host; 2) are not using best effort transit on their hosting; 3) suitably low latency to the end-point (you); 4) concurrent connection support, you will only see a few mb/s no matter how fast your link is. That's just the nature of TCP as it requires ACK to send the next packet, and will increase packet sizes until you drop one and often then it won't initiate a new session to retry faster speeds until a new TCP connection is established. This is also the problem with Twitch. They allow a single TCP connection but on 200ms latency that is a serious problem as the nature of TCP connections limits the throughput.

So on Twitch and other sources it takes one dropped packet for the receive window to halve and on international type latency and BDP calculations it puts users at a real disadvantage at getting decent performance. Hence the need for moving data sources closer to the subscriber but that ain't going to happen for things like Twitch until AWS take a proper local presence and Twitch buys into the local CDN. I use Twitch as an example here but the same applies to any single TCP connection to international destinations.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X