Speed Tests

[#1]

This is not a Tech Problem !... it is for "General Discussion" . ( shudda posted it in General Chat ! ! )

My internet connection is via a 4G LTE router running on the Three network with a SMARTY SIM only deal.

Laptop is connected to the router via ethernet cable.  Router has home built Twin Yagi antennas replacing the "bunny ears" and pointing on the compass bearing of the Mast about 2 miles away, up hill, and just over the top of the hill the other side. No direct line of sight, to the Mast. as the intervening 2 miles is dense urban housing.

18:34  Run a speed test with OOKLA... resulted in a

PING of 28 ms and a speed of 17.90 Mbs down to a server in ABINGDON ( about 100miles as the crow flies from me)

One minute later.

18:35 Switched in a freeby VPN ( Courtesy of Firefox Addons ). repeated the speed test via a VPN in Germany ( distance 450 miles )

PING 58 ms    resulted in a speed of 46.15 Mbs via same server in ABINGDON

One minute later.

18:36 Still on the VPN...changed the server to a "local" one in Gosport      Repeated speed test. 

PING 55ms  speed 49.17 Mbs

One minute later

18:37  switched out the VPN.. so direct to the Gosport Server...

PING 30 ms    Speed 24.48 Mbs

Not "that" concerned about hi speed,  as I don`t do gaming or watch TV on line....  so just an "academic interest in it.

Seems a bit strange that using a VPN  boost the speed by a factor of x2. going via Germany, to the local server in GOSPORT, ( or ABINGDON )

Can anyone explain why this should be?   ( it`s not a "one-off" situation, I have run this kind of test a few times at varying time of day...and the difference in speed is always the VPN gives double the speed, compared to without the VPN . )

[#2]

If this is just a general discussion then I'll chip in with a couple of things....

When we talk about "speed" we seem to be obsessed with how much data you can move in a given time period (which I would call capacity) and I think it is generally the Network provider capping the transfer rates to your subscribed package e.g. 74 down / 20 up... even though the capacity of the connection could be much greater if you have a good line (or in your case a good 4G wireless link)  and can be increased if you upgrade to a different package say 150/30.  So what we refer to as speed is really the capacity allowed by the ISP on your package, unless you have a poor connection that can't cope with so much data.

The speed of the line doesn't actually change....   The Ping time really indicates the speed the packets get transmitted to and from a given server.  So perhaps the speed of the connection is slower over VPN (the pings take longer) even though for some reason the "capacity" is greater.

So "speed" (or capacity) is less important than the Ping time (or speed) for "real time" things like gaming (or landing an aircraft on EE.)  Marketing has a lot to answer for!

So perhaps when you are not using a VPN Three are applying a constraint (perhaps because of how the packets are routed?) that they don't when you use a VPN - may be it's about the end point of the connection and the way Three connect or control capacity.  Who provides and where are the VPN servers you are connecting to?

[#3]

A few more thoughts in case anyone more knowledgeable wants to join in with better info or corrections....

It's clear that the speed tests over your VPN is slower because it takes longer for the ping from your machine to travel to the the speedtest server and back.  What is confusing is that you would expect to be able to transfer more data per second over a faster (non-VPN) connection but that obviously isn't happening on your speed tests.

Perhaps it is worth trying a a traceroute and comparing how the data gets to the speed test servers over VPN and not over VPN... logic would suggest from your speed tests that there is somethings in the non-VPN route that is causing a constraint and when using your VPN connection you are bypassing that constraint.   However both connections use the Three 4G signal to transmit data from your network to Three's - after that the VPN and Non-VPN routes are different and must be impacting the amount of data you are able to transfer...

I suppose the other thing that could be happening is that the initial ping measurement doesn't represent the packet speed when you are running a longer file transfer... it could be that over the VPN some sort of caching of the connection info improves the transfer speed (volume) but that seems unlikely to have such a big effect... might be interesting to run 2 or 3 speed tests back to back over the VPN.

One other thought:  Is there a difference in maximum packet size (MTU) between the VPN and non-VPN connections. I saw some comments from gamers having problems with the MTU size on the Three network recently.

If the connection over VPN is able to send more data in each packet then it may be able to transfer data more quickly even though it takes longer for each packet to reach it's destination and be acknowledged. I have no idea if that would cause such a big difference in the "speed test" results...

[#4]

Have you tried to ascertain whether network traffic is being dropped? Dropped packets will slow down the data transfer rate. But end-to-end response times may not be as negatively affected (depending on how they are measured - ICMP traffic can be prioritised to achieve a perceived better response time).

Without visibility of the end-to-end connection (and intervening hrdware and connections) it is hard to arrive at definitive answers. Application of QoS in the WAN may also be a factor (which will delay, or drop packets if the queues get too long - which will affect data throughput.)

I've been mulling this over since you posted the question.

[#5]

@greygit1  & @Ian06   Thanks to both for your very technical input !... unfortunately, it is all way above my pay grade in understanding what you have both been saying. 

As I mentioned... it is not really a problem for me... more of a "weird thing". so long as web pages appear reasonably quickly, I have no real issue with what speed the bits and bytes travel at between the web site and me !.

I have a program that I use, to send and receive Morse Code over the internet, and I chat to other like minded persons around the world, but mostly with a couple of guys in Australia... There does not seem to be any delay or increased speed of response from the distant station(s) when using the VPN or not... Generally speaking, when I send my K to the other guy ( invitation to transmit) his response comes back to me with no delay just as if it were being transmitted on air.. ( no matter the speed on OOKLA ! )

Thanks again for "mulling it over" and your responses.

Happy New Year to all my readers !.

cheers

[#6]

Assuming your Morse code messages are sent in a single packet yor speed test suggest that the messages over VPN could take around 15mS (half of 30mS) longer to be delivered than the non-VPN route ... don't think any human would be able to notice the difference.

When doing a speed test I think the speedtest transfers a file of reasonable size and measures how long it takes (and how much data is transmitted in each given interval) to work out the "speed" -- to transfer a file of 5Mbytes requires of the order of 3,500 packets to be exchanged, if the packets each takes 15 to 30mS longer over VPN then it's going to take 60 to 100 seconds longer to transmit the data....  if as @greygit1 says the packets get dropped and have to be retransmitted it'll take even longer.

The smaller the packet size the more packets need to be sent to transfer the file content and the longer it will take. (assuming a small and large packet take the same time to get transmitted end to end, which is probably fair.)  Internet protocols determine the maximum packet sizes that can be sent (about the same thing as the MTU.) and I believe there are significant differences between IPv4 and IPv6 maximum packet sizes.....

From the above it's difficult to understand why the "speed" test is faster transferring a large amount of data over the VPN connection, but then we don't really know anything about how the VPN providers network is structured...

Again I don't know much in detail about networking and it would be interesting to hear from someone who does or has worked/works in network engineering...  hope I am not too wrong and completely misleading folks...

[#7]

@Ian06  said...

From the above it's difficult to understand why the "speed" test is faster transferring a large amount of data over the VPN connection, but then we don't really know anything about how the VPN providers network is structured...

Agree 100%  !... Just seems strange that  there is so much difference between the two.

As a point of interest... all users of the software are connected directly to a server in the USA..  so even if I were to send morse to someone in the UK...it would go to the USA first, and be received by the UK station on that server..( if that makes sense! ) .

So .... my connection route  (for the Morse Software ) would be.

"Normal Route".... Laptop and software > ethernet cable to router >  4G wifi mobile phone signal from router to mast 2 miles away > from there, haven`t a clue !... but it goes on the THREE network ( SMARTY SIM ONLY ) . and connects to the server in the USA.

"VPN Route"  would be similar, except that I assume that it goes on the THREE network to/ from ( say ) Frankfurt in Germany to the server in the USA  ? ? ? 

[#8]

Might be interesting to try tracert and ping from your laptop to the morse server using VPN and not... from my laptop to the bbc I get these results:

tracert bbc.co.uk

Tracing route to bbc.co.uk [151.101.192.81]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms ROUTER [192.168.1.1]
2 6 ms 4 ms 4 ms 172.15.10.173
3 * * * Request timed out.
4 9 ms 7 ms 7 ms 213.121.98.136
5 10 ms 22 ms 13 ms 87.237.20.132
6 * * * Request timed out.
7 8 ms 7 ms 7 ms 151.101.192.81

Trace complete.

ping bbc.co.uk

Pinging bbc.co.uk [151.101.192.81] with 32 bytes of data:
Reply from 151.101.192.81: bytes=32 time=7ms TTL=58
Reply from 151.101.192.81: bytes=32 time=11ms TTL=58
Reply from 151.101.192.81: bytes=32 time=12ms TTL=58
Reply from 151.101.192.81: bytes=32 time=12ms TTL=58

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

It will give you some idea of how many hops the messages to the morse server are taking and roughly how long it takes to send a message and get a networking acknowledgement...  There are other factors determining the "speed" test results that we won't be able to see like the packet window size (i.e. how many messages, the window, the originator can send without waiting for an acknowledgement) which could have a significant impact on the speed test results...  but my assumption is that this would be the same over a VPN and non-VPN connection as I believe it is an end to end window.

Probably worth trying the tracert to the speed test server over VPN and non-VPN to compare results....

But as I have said I am not that knowledgeable and I may be mis-understanding what I have read / seen.

[#9]

Out of interest...

Are these morse comms transmitted with a specific application?

My past (some of which involved data compression techniques) has been piqued.

[#10]

@greygit1  Yes.... the software is CWCOM... and you can download it from variou places... I run a Blog that gives a lot of useful info about how to get the best out of the software... Written for W95 by an Australian Radio Ham, but works on all versions since, including W11... and I have also written a page on how I got it to work on LINUX and another user has written a page on how to get it to work on MAC machines.

https://morsepower.blogspot.com/  

Free to us... free to download.. no callsign needed... no registration. 

More info... see the blot or PM me !.

[#11]

@Ian06  Hmm... 

My Terminal reports  

Command `tracert` not found, did you mean:

   command `tracert6 from deb ndisc6 (1.0.4-2ubuntu2)

Try: sudo apt install tracert6

So I installed tracert6

tracert6 bbc.co.uk gives  the following

bbc.co.uk: Network is unreachable

and it reports morsecode.dyndns.org port 3343: Name or service not known

[#12]

---

@shutter wrote:

Command `tracert` not found

---

Does the 'mtr' command work for you ?

For example -

mtr  bbc.co.uk

---

@shutter wrote:

tracert6 bbc.co.uk gives  the following

bbc.co.uk: Network is unreachable

'tracert6' will be trying to ping using IPv6.

Knowing that  'bbc.co.uk'  does respond to IPv6 (see below),  that would suggest your connection doesn't, and is IPv4 only.

'mtr' using IPv6 -

mtr -6 bbc.co.uk
                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- Home_Router               0.0%    10    0.3   0.3   0.2   0.3   0.0
  2.|-- *                         0.0%    10    6.7   6.8   6.5   6.9   0.1
  3.|-- *                         0.0%    10    6.7   6.7   6.6   7.1   0.2
  4.|-- 2001:7f8:4::d361:1        0.0%    10    7.1   7.2   6.9   7.3   0.1
  5.|-- 2a04:4e42:200::81         0.0%    10    7.2   7.2   7.1   7.4   0.1

'mtr' using IPv4 -

mtr -4 bbc.co.uk
                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- Home_Router               0.0%    10    0.3   0.2   0.2   0.3   0.0
  2.|-- *                         0.0%    10    6.7   6.7   6.5   7.0   0.1
  3.|-- *                         0.0%    10    6.7   6.8   6.4   7.1   0.2
  4.|-- 195.66.225.91             0.0%    10    7.1   7.2   6.8   7.4   0.1
  5.|-- 151.101.0.81              0.0%    10    6.8   7.0   6.7   7.5   0.2

[#13]

@shutter  tracert is a Dos command, the equivalent in Linux is the properly named traceroute, no idea what tracert6 is or does.🤔

[#14]

Yes "tracert [hostname]" is a dos/windows command and the linux equivalent is "traceroute [hostname]"

A traceroute provides a map of how data on the internet travels from its source to its destination.  When you connect with a website, the data you get must travel across multiple devices and networks along the way, particularly routers.

A traceroute plays a different role than other diagnostic tools, such as packet capture, which analyzes data. Traceroute differs in that it examines how the data moves through the internet. 

see this link:  What is Traceroutes 

[#15]

OK... thanks for the mrt   and yes my connection is only ipv 4 ..

so that does seem like traceroute6 is for ipv6 ! .

How long should I let the mtr -4 run ..... does it actually "finish" and give a final picture ?