TID: FMail-W32 2.1.3.7-B20170919
RFC-X-No-Archive: Yes
TZUTC: 0200
CHRS: CP850 2
MSGID: 2:280/5555 61422bfe
REPLY: 149.fidonet_ipv6@1:142/103 25a74e16
Hello Brian,

On Wednesday September 15 2021 11:30, you wrote to me:

 MvV>> A tunnel is good, native IPv6 is better. I noticed it too when I
 MvV>> used tunnels. IPv6 over the tunnel is significantky slower than
 MvV>> IPv4. Up to 50% slower. Native IPv6 is always preferable so we
 MvV>> we should all keep perstering our ISPs about IPv6.

 BR> If  you were getting that much of a slowdown, something else was going
 BR> on.

Sure. The frustrating part is that I was never able to figure out what it was.

 BR>  Granted the MTU is slightly and I mean slightly less than native
 BR> IPv6 or IPv4, but it's only by 20 bytes/1500 byte packet. Doing the
 BR> math, this does NOT equal a 50% lag.

Indeed, so it is not that.

 BR> Maybe the issue is that your ISP's path to your IPv6 tunnel provider
 BR> is not an optimum path? Mine is just a couple hops away so it's not an
 BR> issue for me.

Unlikely. I used the the he.net POP in Amsterdam, no-one in The Netherlands is
more than a couple of hops from AMS-IX.

The prime suspect is still the router that ran my tunnel endpoint back than. A
Linksys WRT54G running OpenWrt. But I could bever make sure.

Now it is irrelevent, I now have native IPv6 and I see no significant
difference in pefomance between IPv6 and IPv4.

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
 * Origin: he.net certified sage (2:280/5555)
SEEN-BY: 1/123 19/10 90/1 105/81 120/340 123/131 153/757 154/10 203/0
SEEN-BY: 218/840 221/0 1 6 226/30 227/702 229/424 426 428 550 664
SEEN-BY: 229/700 240/5832 249/206 317 400 250/1 280/464 5003 5006
SEEN-BY: 280/5555 282/1038 301/1 310/31 317/3 322/757 335/364 342/200
SEEN-BY: 460/58 633/280 640/1384 712/848 770/1 2452/250 4500/1 5019/40
SEEN-BY: 5020/545 1042 12000 5053/58
PATH: 280/5555 221/6 229/664 426