Might be worth doing it at different times of the day, and also seeing the route it takes...Just switched my main OpenWRT router from Singtel native IPv6 to Singtel 6rd to see the penality of the 6rd tunnel, Intel N100 CPU based mini PC, two virutal core assigned to the OpenWRT VM, virutal Linux bridge as WAN/LAN.
Reference IPv4 WAN (Internet speed), Singtel 5Gbps, 6rd tunnel does not affect IPv4 speed.
Bash:root@OpenWrt:~/ookla# ./speedtest -s 13623 Speedtest by Ookla Server: Singtel - Singapore (id: 13623) ISP: Singtel Fibre Idle Latency: 1.32 ms (jitter: 0.22ms, low: 0.97ms, high: 1.45ms) Download: 5635.14 Mbps (data used: 2.5 GB) 1.81 ms (jitter: 0.81ms, low: 1.11ms, high: 5.35ms) Upload: 4977.62 Mbps (data used: 2.4 GB) 6.63 ms (jitter: 0.50ms, low: 1.25ms, high: 7.25ms) Packet Loss: 0.0% Result URL: https://www.speedtest.net/result/c/3616a3d2-707e-4118-92fa-d1e5c533b315
6rd tunnel does seem to have quite a bit of penality on the upload speed, and dual birection speed got greatly reduced. Download speed is not affected as the test server is limited to 4Gbps.
The good thing is that the tunnel is at least able to cope with 4Gbps.
Bash:root@OpenWrt:~/crusader_bin/v0.3.2# ./crusader test --load-duration 60 --streams 8 --stream-stagger 4 singapore.starlink .taht.net [2024-11-27 12:01:50] Client version 0.3.2 running [2024-11-27 12:01:51] Connected to server [2600:3c15::f03c:95ff:fe7e:75a2]:35481 [2024-11-27 12:01:52] Idle latency to server 2.88 ms [2024-11-27 12:01:54] Testing download... [2024-11-27 12:03:24] Testing upload... [2024-11-27 12:04:54] Testing both download and upload... -- Download test -- Throughput: 4034.61 Mbps Latency: 3.6 ms (2.2 ms down, 1.4 ms up) Packet loss: 0.18% down, 0% up -- Upload test -- Throughput: 3071.63 Mbps Latency: 7.1 ms (1.6 ms down, 5.4 ms up) Packet loss: 0.04% down, 0% up -- Bidirectional test -- Throughput: 5663.09 Mbps (2905.34 Mbps down, 2757.75 Mbps up) Latency: 8.8 ms (6.8 ms down, 2.0 ms up) Packet loss: 0.15% down, 0% up [2024-11-27 12:06:29] Writing data... [2024-11-27 12:06:29] Saved raw data as crusader-results/test 2024-11-27 12.06.29.crr [2024-11-27 12:06:29] Saved plot as crusader-results/test 2024-11-27 12.06.29.png
Switching back to native IPv6 and carry out the test again. Somehow the download is a bit slower but I can see the test server is not limited on the upload speed.
Bash:root@OpenWrt:~/crusader_bin/v0.3.2# ./crusader test --load-duration 60 --streams 8 --stream-stagger 4 singapore.starlink .taht.net [2024-11-27 12:22:40] Client version 0.3.2 running [2024-11-27 12:22:41] Connected to server [2600:3c15::f03c:95ff:fe7e:75a2]:35481 [2024-11-27 12:22:42] Idle latency to server 2.31 ms [2024-11-27 12:22:44] Testing download... [2024-11-27 12:24:15] Testing upload... [2024-11-27 12:25:45] Testing both download and upload... -- Download test -- Throughput: 3812.55 Mbps Latency: 2.1 ms (0.7 ms down, 1.4 ms up) Packet loss: 0.03% down, 0% up -- Upload test -- Throughput: 4873.02 Mbps Latency: 9.5 ms (0.8 ms down, 8.7 ms up) Packet loss: 0% -- Bidirectional test -- Throughput: 8022.09 Mbps (3174.82 Mbps down, 4847.27 Mbps up) Latency: 9.5 ms (0.9 ms down, 8.6 ms up) Packet loss: 0.02% down, 0% up [2024-11-27 12:27:19] Writing data... [2024-11-27 12:27:19] Saved raw data as crusader-results/test 2024-11-27 12.27.19.crr [2024-11-27 12:27:19] Saved plot as crusader-results/test 2024-11-27 12.27.19.png
The peering link between the two providers could be a single 10GB, so you might find that the peering gets saturated during busy times which would slow things down for you.