The reason that Ethernet can afford to do that even in entirely switched deployments, though, is that Ethernet’s CSMA is very aggressive/optimistic, meaning that there’s almost no overhead to it in the case that there really is nothing else sharing the medium. In fact, Ethernet’s “1-persistent” CSMA is effectively designed for low contention, falling over at high [100+ TXers] contention—which is why we don’t just use Ethernet over shared-medium WANs like a cable ISP’s (pre-fibre-backhaul) coax, but instead protocols like https://en.wikipedia.org/wiki/Asynchronous_transfer_mode.
My point with bringing up the low contention of modern media wasn’t that modern devices could somehow skip CSMA sense-idle altogether; but rather that, due to the aggressive nature of Ethernet’s CSMA, Ethernet when on a low-contention or no-contention media should have basically zero sense-idle overhead, which means one less thing standing in the way of fast Ethernet PHY autonegotiation in an archetypal modern deployment; and so one less reason to privilege the hypothesis of “it’s the laws of physics making PHY autonegotiation slow” over “Ethernet controllers are doing something dumb.”
Here’s something to chew on: USB is also a shared-medium PHY with many layers of legacy compatibility. And yet, on every OS I know of, a USB3 analog input device (e.g. a microphone) can go from “off/unplugged” to “negotiated, registered, driver up, and transmitting data to the host, that the host has an open buffer for such that it will acknowledge and process the data within the soft-real-time window”, all with 0.5s of delay or less.
Heck, the entire Bluetooth stack plus connections to pre-paired devices can come up faster than Ethernet—and Bluetooth sits on top of USB! Bluetooth comes up fast enough, that Apple bothers on its desktops to bring up the Bluetooth stack within EFI, finishing quickly enough that Bluetooth peripherals can be used to signal an interrupt to the EFI boot process within its ~1s interaction window. (We all know, meanwhile, what EFI under Ethernet control looks like: the modern server mainboard’s 6+ second “IPMI autoconfig” delay.)
Comparing USB to Ethernet is difficult. Any USB-device is talking USB1.1 at startup. So negotiation basically is transferring a data packet with the capabilities at a pre-defined data rate.
While Ethernet has to negotiate the number of wires, full-duplex vs half-duplex (which depends on the number of wires). The code like Manchester vs. 4B5B.
The main difference is, in USB the host decides on what to talk. In Ethernet there is no such instance.
The reason that Ethernet can afford to do that even in entirely switched deployments, though, is that Ethernet’s CSMA is very aggressive/optimistic, meaning that there’s almost no overhead to it in the case that there really is nothing else sharing the medium. In fact, Ethernet’s “1-persistent” CSMA is effectively designed for low contention, falling over at high [100+ TXers] contention—which is why we don’t just use Ethernet over shared-medium WANs like a cable ISP’s (pre-fibre-backhaul) coax, but instead protocols like https://en.wikipedia.org/wiki/Asynchronous_transfer_mode.
My point with bringing up the low contention of modern media wasn’t that modern devices could somehow skip CSMA sense-idle altogether; but rather that, due to the aggressive nature of Ethernet’s CSMA, Ethernet when on a low-contention or no-contention media should have basically zero sense-idle overhead, which means one less thing standing in the way of fast Ethernet PHY autonegotiation in an archetypal modern deployment; and so one less reason to privilege the hypothesis of “it’s the laws of physics making PHY autonegotiation slow” over “Ethernet controllers are doing something dumb.”
Here’s something to chew on: USB is also a shared-medium PHY with many layers of legacy compatibility. And yet, on every OS I know of, a USB3 analog input device (e.g. a microphone) can go from “off/unplugged” to “negotiated, registered, driver up, and transmitting data to the host, that the host has an open buffer for such that it will acknowledge and process the data within the soft-real-time window”, all with 0.5s of delay or less.
Heck, the entire Bluetooth stack plus connections to pre-paired devices can come up faster than Ethernet—and Bluetooth sits on top of USB! Bluetooth comes up fast enough, that Apple bothers on its desktops to bring up the Bluetooth stack within EFI, finishing quickly enough that Bluetooth peripherals can be used to signal an interrupt to the EFI boot process within its ~1s interaction window. (We all know, meanwhile, what EFI under Ethernet control looks like: the modern server mainboard’s 6+ second “IPMI autoconfig” delay.)