6 ms·

According to many commenters in the linked thread, it's fixed in MacOS 13.2.1. Not great that it happened at all, but good to see that it was a software issue.

segfaultbuserr 4y ago
Is it a software issue, or a hardware issue that could be worked around in software... (sorry for the rant as an embedded system developer).
- throwaway5959 4y ago
  To the end user, if it doesn't impair performance, does it matter?
  - Dylan16807 4y ago
    To the end user, and doesn't impair performance, and covers all edge cases, then it doesn't matter if something is a workaround. But we're not being end users here, we're trying to look at what went wrong. And we don't know if the other two are true either.
    - mbreese 4y ago
      And, if it's something that's worked around in software (meaning, it was a hardware issue), that might have issues for things like Asahi Linux, which probably won't have that workaround in place.
  - makeitdouble 4y ago
    Arguably it would impact the support for other OSes, especially alternative ones who'd need to reverse engineer the workaround and/or write their own to get the network stack working. It could also fall apart the day Apple decides this machine is not supported anymore, and their next OS won't have the correct drivers anymore. It's their prerogative, but will sure suck for the machine owners.
    - deleted 4y ago
      [deleted]
- loeg 4y ago
  The latter is very common in the desktop/server space, too. If you ever write or work on drivers, you know.
  - segfaultbuserr 4y ago
    > If you ever write or work on drivers, you know. Especially when the hardware vendor doesn't provide public documentation on the correct workaround.
  - deleted 4y ago
    [deleted]
ed25519FUUU 4y ago
I have MacOS 13.2.1 and it's definitely not completely fixed -- but better. I did a ping test against my home router and I still get about 10% packet loss. Much better than the 40% when I first plugged it in.
- icedchai 4y ago
  Can you try a speed test? That level of packet loss will make TCP connections perform incredibly poorly.
  - ProAm 4y ago
    10% loss inside your home network is bonkers bad.
    - icedchai 4y ago
      Absolutely. I had ~2% loss on an old cable modem and it would drop my upload speeds to single digit megabits.
- singularity2001 4y ago
  Uff yeah it's still horrible! PING fritz.box (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=11.845 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=24.287 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.120 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.630 ms Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.801 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.139 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.772 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.784 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.674 ms The above suggestion fixes it, hopefully permanently: settings->network-><ethernet interface>->details->hardware "change anything, safe and undo"

segfaultbuserr 4y ago

Is it a software issue, or a hardware issue that could be worked around in software... (sorry for the rant as an embedded system developer).

throwaway5959 4y ago
To the end user, if it doesn't impair performance, does it matter?
- Dylan16807 4y ago
  To the end user, and doesn't impair performance, and covers all edge cases, then it doesn't matter if something is a workaround. But we're not being end users here, we're trying to look at what went wrong. And we don't know if the other two are true either.
  - mbreese 4y ago
    And, if it's something that's worked around in software (meaning, it was a hardware issue), that might have issues for things like Asahi Linux, which probably won't have that workaround in place.
- makeitdouble 4y ago
  Arguably it would impact the support for other OSes, especially alternative ones who'd need to reverse engineer the workaround and/or write their own to get the network stack working. It could also fall apart the day Apple decides this machine is not supported anymore, and their next OS won't have the correct drivers anymore. It's their prerogative, but will sure suck for the machine owners.
  - deleted 4y ago
    [deleted]
loeg 4y ago
The latter is very common in the desktop/server space, too. If you ever write or work on drivers, you know.
- segfaultbuserr 4y ago
  > If you ever write or work on drivers, you know. Especially when the hardware vendor doesn't provide public documentation on the correct workaround.
- deleted 4y ago
  [deleted]

ed25519FUUU 4y ago

I have MacOS 13.2.1 and it's definitely not completely fixed -- but better. I did a ping test against my home router and I still get about 10% packet loss. Much better than the 40% when I first plugged it in.

icedchai 4y ago
Can you try a speed test? That level of packet loss will make TCP connections perform incredibly poorly.
- ProAm 4y ago
  10% loss inside your home network is bonkers bad.
  - icedchai 4y ago
    Absolutely. I had ~2% loss on an old cable modem and it would drop my upload speeds to single digit megabits.
singularity2001 4y ago
Uff yeah it's still horrible! PING fritz.box (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=11.845 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=24.287 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.120 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.630 ms Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.801 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.139 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.772 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.784 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.674 ms The above suggestion fixes it, hopefully permanently: settings->network-><ethernet interface>->details->hardware "change anything, safe and undo"