I have a service that has been running on a 3x cluster of headless M1 Mac Studios since Ventura, and before that on headless Mac minis since Monterey. Now, after updating the Studios from Sonoma to Sequoia, response times have slowed to a crawl. For example, generating and sending a 150KB PDF file normally takes around 20 milliseconds. Now it takes over 15 SECONDS! The daemon code didn't change between updates. The issue seems to center around TSO on the ethernet port. Connecting via a port without TSO works as expected. But the 10 GB ethernet port on the Studio has built-in TSO. I've tried to disable TSO using sudo sysctl -w net.inet.tcp.tso=0. This works for an hour or so before the daemon eventually becomes unresponsive. At this point the daemon has to be terminated and restarted. So for now I'm having to use cheap USB-C to Ethernet adapters to connect the Mac Studios. Is there a configuration setting I'm missing for proper TSO in Network Framework?

I have the following snippet of code for receiving incoming data on a NWConnection: self.Connection.receive(minimumIncompleteLength: 1, maximumLength: self.MAX_INTAKE) { (data, context, isComplete, error) in if let err = error { // receive <error> returned non-nil self.Connection.cancel() return // exit completion handler } ... } This generally works and rarely receives an error. But seemingly at random, will return 89. When this happens I've been sending a .cancel before returning from the completion handler. It will work great for tens of thousands of connections, then suddenly return 89 error codes. My question is: Should I be canceling the connection here or simply let NWFramwwork do as it will? Canceling the connection seems to throw my NGINX reverse proxy into fits, from which it never recovers without a restart. In short what is the best practice for handling errors when receiving bytes in NWFramework?