Once upon a time, Richard Sewill <rsewill@xxxxxxxxx> said: > I tried ping and ping6 anyway. This is NOT on an idle network. Since ICMP and ICMPv6 are low-priority, the data is not very useful. Also, since latency is only one component of throughput (and most communications are not particularly sensitive to latency less than about 200ms, except for issues like bufferbloat), this really doesn't mean much. However, since we're going for anecdotal evidence, this is on an otherwise idle system on an uncongested link (and not using a tunnel): $ ping -c5 www.google.com PING www.google.com (74.125.26.106) 56(84) bytes of data. 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=1 ttl=40 time=45.2 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=2 ttl=40 time=45.2 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=3 ttl=40 time=45.3 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=4 ttl=40 time=45.7 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=5 ttl=40 time=45.5 ms --- www.google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4052ms rtt min/avg/max/mdev = 45.238/45.443/45.796/0.244 ms $ ping6 -c5 www.google.com PING www.google.com(vh-in-x6a.1e100.net) 56 data bytes 64 bytes from vh-in-x6a.1e100.net: icmp_seq=1 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=2 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=3 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=4 ttl=55 time=24.9 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=5 ttl=55 time=24.9 ms --- www.google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4033ms rtt min/avg/max/mdev = 24.819/24.878/24.909/0.202 ms > There remains a performance penalty when using IPv6. No, there is possibly a performance issue with your ISP. Have you reported the problem? > Given the ISP is handing out 6to4 tunneling, I still think the ISP support > is "sort of not there". Lots of ISPs will probably use last-hop tunnels for a while, because a lot of the last-hop gear is old and doesn't properly support IPv6. Eventually that gear will be replaced, but in the interim, they'll install tunnel servers alongside the last-hop gear. It is possible your ISP doesn't have the tunnel server near your last-hop and is taking a sub-optimal path. However, similar kinds of sub-optimal routing happen with IPv4 all the time, especially once MPLS comes in to play. > I am guessing, please correct me if I am wrong, IPv4 will be used in > preference to IPv6, when both are available. No, when both are available, IPv6 takes precedence (in general for modern applications that don't override the precedence); this is spelled out in several RFCs (can't recall the numbers). I think there is a global way to override this (maybe /etc/gai.conf can do it?). -- Chris Adams <linux@xxxxxxxxxxx> -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
