v6 speed is always worse than v4 speed

[wRAR]

I'm forced to use the Amsterdam tunnel server because there is no better option (it's about 85ms ping time and about 3500km distance from there but there is no closer servers) and my v6 speed is always worse, sometimes (especially for local resources) more than 10x worse. I don't think I saw real download speeds better than 500Kb/s. Here are some fresh pictures from ipv6-test.com:







Is that expected for such a remote tunnel server? Is that inevitable?

[cholzhauer]

Tunneled IPv6 should be slower than IPv4 in most cases, but yours may be a little extreme

[kasperd]

Throughput should not drop that much just because of increased latency. I can't help wondering if the test you are using is skewing things by being more sensitive to latency on the IPv6 connection than it is on the IPv4 connection. Of course it is of course also possible that you are running into a congested link and dropping packets.

If it is due to congestion it might actually help to use a different tunnel server, even if slightly further away from you. There are several to choose from in Europe. Remember, you can create another tunnel without deleting the current one, but if you do delete your current one, you won't be able to get it back with the same IPv6 addresses.

[wRAR]

Throughput should not drop that much just because of increased latency. I can't help wondering if the test you are using is skewing things by being more sensitive to latency on the IPv6 connection than it is on the IPv4 connection. Of course it is of course also possible that you are running into a congested link and dropping packets.

Just downloading something from mirror.yandex.ru can have speeds up to several Mb/s over v4 while never being better than about 400 Kb/s over v6 (ping is 43 vs 134 ms).

Remember, you can create another tunnel without deleting the current one

Wrong: "You already have a tunnel to this IP.".

[kasperd]

Wrong: "You already have a tunnel to this IP.".

There is that annoying limitation. You have to change the IP of the existing tunnel while you test the new tunnel. You probably know somebody who will allow you to use their public IPv4 address for that purpose briefly, it is not like it is causing much traffic.

If you don't feel anything for the old tunnel, you can also just deleted, just be aware that once you create a new tunnel in the same location it will:
- Have a different IPv6 range
- Have IRC blocked by default
And there is a risk that the location is full and you cannot get a tunnel there again.

[bpier]

Tunneled IPv6 should be slower than IPv4 in most cases, but yours may be a little extreme

This is not a maxim, as path (hop count) and individual hop link speed and latency are all factors in overall throughput from end to end.  The end-to-end path might be significantly different between IPv4 and tunneled IPv6.
So, it might be said that generally the route via tunneled IPv6 could be slower.

[wRAR]

Stockholm (79 ms ping):





Frankfurt (89 ms ping):





And that's for gogo6:




As in 2 years of using he.net tunnels I didn't find any practical advantages of that (apart from greatly increased time of apt-get dist-upgrade), the solution is obvious.

[wRAR]

Except that the HE tunnel always works, even if it is slow

I didn't mean switching to gogo6 or to any other tunnel provider.

[kasperd]

The speed test on ipv6-test.com is very inaccurate. I ran it twice from the same browser under identical circumstances and got wildly different results.

First run: IPv4 11.9 Mbit/s, IPv6 2.64 Mbit/s
Second run: IPv4 4.82 Mbit/s, IPv6 28.6 Mbit/s

Sharing the images doesn't seem to work when I have already run the test twice.

Both tests were run from a computer in Aarhus using the tunnel server in Stockholm and the test server in Roubaix.

I tried a few more times:
Chromium:





Firefox:



I get the feeling the variation might be caused by how quickly the browser responds rather than the actual network performance.

[mleber]

Stockholm (79 ms ping):

Frankfurt (89 ms ping):

As in 2 years of using he.net tunnels I didn't find any practical advantages of that (apart from greatly increased time of apt-get dist-upgrade), the solution is obvious.

Pick a provider that has an upstream that IPv4 peers with Hurricane, if not native IPv6 peering so that you can get native IPv6?

Either of those solutions will help reduce those relatively large ping times.  I'm assuming you picked them because they are actually the closest you could pick.

The primary purpose of the tunnel broker service is to provide IPv6 connectivity for software developers, network engineers, and technologists, so that they can do testing, development, and experimentation, in a situation where a native IPv6 solution is not available.

And now, due to happy eyeballs being included in modern browsers, you can even leave it on all the time and whichever address family (IPv6 or IPv4) is faster will be the one that is used.

Mike.

[wRAR]

Pick a provider that has an upstream that IPv4 peers with Hurricane, if not native IPv6 peering so that you can get native IPv6?

Do I really need to explain that changing the ISP is not an option?

I'm assuming you picked them because they are actually the closest you could pick.

Of course.

And now, due to happy eyeballs being included in modern browsers, you can even leave it on all the time and whichever address family (IPv6 or IPv4) is faster will be the one that is used.

Huh? Which browsers violate RFC 3484?