Hi Hongyi,
On Fri, Oct 28, 2016 at 10:55 PM, Hongyi Zhao <hongyi.z...@gmail.com> wrote:
>
> I tried it as follows:
>
> $ ping -c 10 -I eth0 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) from 192.168.0.2 eth0: 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=128 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=124 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=124 ms
> 64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=124 ms
> 64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=127 ms
> 64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=133 ms
> 64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=122 ms
> 64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=125 ms
> 64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=131 ms
> 64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=123 ms
>
> --- 8.8.8.8 ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 9011ms
> rtt min/avg/max/mdev = 122.963/126.756/133.225/3.199 ms
>
> $ ping -c 10 -I tun104 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) from 10.211.1.49 tun104: 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=209 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=206 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=435 ms
> 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=351 ms
> 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=202 ms
> 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=203 ms
> 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=206 ms
> 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=210 ms
> 64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=204 ms
> 64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=208 ms
>
> --- 8.8.8.8 ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 9008ms
> rtt min/avg/max/mdev = 202.260/243.852/435.330/77.155 ms
This is not a proper comparison of the latency overhead due to the tunnel,
assuming that's what you are trying to measure. Because of anycast, in one
case you are pinging a google dns server geographically close to you
(through eth0), while through the tunnel you reach one close to the vpn
server.
Instead, ping the vpn server's public address (through eth0) and compare
that with pinging the tunnel's remote endpoint or gateway. No -I eth0 or -I
tunxx needed for this as the former will automatically go through eth0 (in
clear) and the latter through the tun interface (encrypted), based on
routes set up when you use --redirect-gateway (which I guess you do use).
Will work only if the server responds to pings, though.
My experience is that the the tunnel adds an insignificant amount to the
latency. Here are two examples of such a ping statistics. Both are measured
under no or minimal load.
1. Client and server ~1000 kms away, but with an decent link between them
ping server_public ip: rtt min/avg/max/mdev = 16.116/16.298/16.512/0.198 ms
ping vpn_gateway: rtt min/avg/max/mdev = 16.805/16.920/17.024/0.061
ms:
2. Client and server in same city but over domestic DSL/cable, so RTT is
larger:
ping server_public_ip: rtt min/avg/max/mdev = 43.040/43.252/43.453/0.232 ms
ping vpn_gateway: rtt min/avg/max/mdev = 42.902/43.216/43.485/0.330 ms
(I cheated here as this server does not respond to ping. So another machine
on
the same LAN as the server was pinged instead of the server's public ip).
Selva
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
