Bug: ping6 responses increase into the 1000+ ms

[chrisintheshell]

I'm often noticing some swinging ICMP echo responses using ping6 for destination IPs that I know should be low latency . A lot of the time the response times will continuously increase into the 1000+ ms (seen it as high as 3000+ ms) and I get packet loss. When I send a Ctrl+C signal and start the ping immediately following it goes back down where I expect it to be.

Example below.

$ ping6 cloudflare.com
PING cloudflare.com (2606:4700::6810:84e5): 56 data bytes
64 bytes from 2606:4700::6810:84e5: icmp6_seq=0 ttl=59 time=7.577 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=1 ttl=59 time=11.692 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=2 ttl=59 time=12.290 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=3 ttl=59 time=13.790 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=4 ttl=59 time=12.677 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=5 ttl=59 time=13.359 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=6 ttl=59 time=13.891 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=7 ttl=59 time=10.327 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=8 ttl=59 time=13.803 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=9 ttl=59 time=12.851 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=10 ttl=59 time=13.059 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=11 ttl=59 time=43.106 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=12 ttl=59 time=43.852 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=13 ttl=59 time=55.909 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=14 ttl=59 time=98.987 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=15 ttl=59 time=1202.047 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=16 ttl=59 time=1048.761 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=17 ttl=59 time=1049.213 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=18 ttl=59 time=1016.270 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=19 ttl=59 time=1004.122 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=20 ttl=59 time=1004.633 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=21 ttl=59 time=1002.003 ms
^C

--- cloudflare.com ping statistics ---
23 packets transmitted, 22 packets received, 4.3% packet loss
round-trip min/avg/max/stddev = 7.577/350.192/1202.047/477.707 ms

$ ping6 cloudflare.com
PING cloudflare.com (2606:4700::6810:84e5): 56 data bytes
64 bytes from 2606:4700::6810:84e5: icmp6_seq=0 ttl=59 time=20.678 ms
64 bytes from 2606:4700::6810:84e5: icmp6_seq=1 ttl=59 time=9.657 ms

Let me know if there is anything else I can provide to help debug.

[kitknox]

While I wasn’t replicating the problem, I believe I understand the root cause. This was running on MainActor with a Task.yield() and if the system was busy it could end up missing a cycle. On the next cycle it was only reading at max one packet, so it was forever behind one interval. I’ve fixed this and also moved the RTT measurement to use the kernel packet timestamps instead of gettimeofday() to further increase RTT measurement accuracy. Restarting with CTRL-c would get it out of this always one behind state previously so it at least matches your description. Fix in next build.

As an aside on anything with the Broadcom WiFi chipsets the way Apple implements their stack for Airdrop etc in their device to device WiFi mode triggers channel hopping unless you happen to have the access point you are connected to on the same hard coded 5GHz channel that Apple uses. (I’m sure an LLM can tell you the channel number, I forget which one) This seems slightly better in newer OS versions, but it’s a total mess. If you are on something like Ubiquiti or others that let you set your channel you can in theory at least choose to overlap. If you are on Eero it’s going to randomly move you around. You can tell this has never bothered me in the past…. This is one of the big benefits of being actively connected to a 6GHz channel if you have gear that supports it. If you run pings and see latency spiking at roughly a consistent time interval this is likely the cause.

[kitknox]

@chrisintheshell Does this appear fixed in the latest build?

[chrisintheshell]

I think so. Thank you.