I can't tell if this is a trick question that has something to do with a quirk of USB running multiple lanes in parallel to get higher speeds.
Because if not then it's the same as any specification for connecting devices that allows for multiple speeds. It runs at the lowest of the max speeds supported of everything in the chain.
That's exactly the issue. I'm just pointing out that it's a fantasy to hope for simple numbering of max supported speeds will simplify the current USB mess.
It will not.
Consumers would expect plugging a 20Gbps device into a 40Gbps port should result in 20Gbps negotiated speed. In reality it will mostly likely end up at 10Gbps (or less) because of the mess.
Older Thunderbolt devices were not compatible with USB, so plugging them into an USB Type C port would not work.
Newer Thunderbolt/USB 4 devices do not have any technical reason for preventing them to work as USB 3.2 2x2, i.e. to work at 20 Gb/s when plugged into a 20 Gb/s host port, and vice-versa for 20 Gb/s devices plugged into a USB 4/Thunderbolt host port, because both Thunderbolt and 20 Gb/s USB need the same wires in the cable and connector.
I do not know if all USB 4 controllers also work at 20 Gb/s (USB 3.2 2x2), but if they do not work that should be considered a bug.
USB4/TB4 devices doing (only) PCIe tunneling will absolutely not work on a USB3.2 port, or even on an USB4 port without PCIe support (which you can find on some very recent smartphones I believe. It's spec compliant, PCIe is optional.)
> by the time batteries wear out, most people are going to want a new a phone.
Not true. In recent years smartphones do not advance much, and would be perfectly fine to keep working if not for the dying battery.
> At the very least we'd need to see some data that shows that most people replace batteries when it is possible to do so.
The degree of "possible" varies greatly depending on the available expertise and spare parts. Right now in EU it's cost prohibitive for both coz the special labor required is expensive and almost no official spare parts for consumers. So of coz this will be no data to support your claim.
Chips only have a certain number of pins. It probably works out better economically if those pins can be used for either input or output. Chip manufacturers can thus make one product that will fit the needs of more customers instead of (say) 9 different chip variants with 8 inputs and 0 outputs, 7 inputs and 1 output, 6 inputs and 2 outputs, etc.
It could also be useful to the end user. Motherboards have a limited number of ports since the connectors cost money and take up space on the back panel. One user might want a line input (for digitizing old cassettes, for example)[1] and another user might want an extra surround sound output (for 7.1 surround sound instead of just 5.1 surround). With retasking, the motherboard can support both these niche use cases with a single shared port.
---
[1] You can't use a microphone input for this because (a) it's mono and (b) it's a different voltage level.
eBPF is very limited in the code complexity you can achieve. DPI on QUIC, for example, needs a lot of cryptography. That's simply not possible in eBPF. DPI on ordinary TLS still requires that you collect enough network packets to get the name, hold them back until you have a decision and then re-inject them. Holding back packets is not even possible at the layer where we intercept. And even if we find a layer to do this, it adds enough complexity that we no longer pass the verifier.
Seamless WiFi roaming is mostly a client decision. The best you can do on AP is to:
a) optimize signal strength for coverage (stronger signals aren't always better in multi-AP deployment);
b) provide hints via 802.11k/v/r to help clients make, hopefully, better decisions;
c) forcefully drop and disassociate clients when signal is weak enough.
But if the client has bad WiFi implementation, there's nothing much you could do.
OpenWRT currently supports 802.11k/v/r, but optimizing coverage by adjusting signal strength and channels is left for experienced users to deal with manually. There is the are where some commercial offerings will do, but the result greatly varies. AFAIK there's no ideal system anyway coz physics is hard.
I used to think that the scenes of the TV series “Person of Interest” were exaggerated for storytelling purposes. Maybe not and it was accurate prescience.
SFTP was designed as a remote file system system access protocol rather than transfer a single file like scp.
I suspect that the root of the problem is that SFTP works over a single SSH channel. SSH connections can have multiple channels but usually the server binds a single channel to a single executable so it makes sense to use only a single channel.
Everything flows from that decision - packetisation becomes necessary otherwise you have to wait for all the files to transfer before you can do anything else (eg list a directory) and that is no good for your remote filesystem access.
Perhaps the packets could have been streamed but the way it works is more like an RPC protocol with requests and responses. Each request has a serial number which is copied to the response. This means the client can have many requests in-flight.
There was a proposal for rclone to use scp for the data connections. So we'd use sftp for the day to day file listings, creating directories etc, but do actual file transfers with scp. Scp uses one SSH channel per file so doesn't suffer from the same problems as sftp. I think we abandoned that idea though as many sftp servers aren't configured with scp as well. Also modern versions of OpenSSH (OpenSSH 9.0 released April 2022) use SFTP instead of scp anyway. This was done to fix various vulnerabilities in scp as I understand.
Notably, the SFTP specification was never completed. We're working off of draft specs, and presumably these issues wouldn't have made it into a final version.
Because that is a poor characterization of the problem.
It just has a in-flight message/queue limit like basically every other communication protocol. You can only buffer so many messages and space for responses until you run out of space. The problem there is just that the default amount of buffering is very low and is not adaptive to the available space/bandwidth.
Yeah, it's an issue because there is also the per channel application layer flow control. So when you are using SFTP you have the TCP flow control, the SSH layer flow control, and then the SFTP flow control. The maximum receive buffer ends up being the minimum of all three. HPN-SSH (I'm the dev) normalizes the SSH layer flow control to the TCP receive buffer but we haven't done enough work on SFTP except to bump up the buffer size/outstanding requests. I need to determine if this is effective enough or if I need some dynamism in there as well.
I hate the original Mac Pro case so much!!! The metal box is so heavy and the edges of the aluminum top handle is so sharp that you definitely need a pair of heavy-duty gloves to move it around.
Unfortunately it's not true.
Quiz: what happens when a device capable of 20Gbps is plugged into a port marked as 40Gbps?