MTP batch transfers slow to 30 MB/s after first file

On an 8-year-old MacBook Air, a batch of three 2-GB files was copied to an Android phone via MTP. The first file transferred at 45 MB/s, the second fell to 30 MB/s, and the third was even slower [Dev.to]. The hardware, cable, and host application remained unchanged between files. MTP forces a full negotiation for each object: a SendObjectInfo command followed by SendObject. During the gap, the Android device commits the previous file to its flash controller, flushes and re-establishes the USB bulk pipe, and processes metadata in its MTP stack before it can accept new data [Dev.to]. The longer the preceding file, the longer the device needs to finish these steps, producing a measurable dip at every file boundary. The author's HiyokoMTP client tried three mitigations: switching the Tokio thread pool to avoid blocking async threads, raising the USB bulk buffer to 4 MB, and adding a short pause between files. While these changes improved stability and peak throughput, they did not erase the inter-file slowdown [Dev.to]. The dip is a protocol-level issue, not an implementation-level one. For bulk migrations, ADB push delivers steadier throughput because it streams without per-file handshakes, even though its raw speed is lower [Dev.to]. Reducing the dip would require driver-level changes, such as non-async bulk pipelining or exposing zero-copy USB transfers, which Android's current MTP stack does not support.