I'm guessing that we don't do anything special for uploads from SMB network shares, so this is probably something like alternating reads and writes instead of reading ahead while part of the upload is writing.

To your point, I should mention that I re-tried this using NFS instead of SMB, and the bandwidth measurements are exactly the same.

Punting this back to the triage queue - I don't think there's any reason to believe this is HTTP specific?  (i.e., doesn't affect H2/QUIC), since they all use UploadDataStream.

I suspect the perf issue is relayed to how we read data (pull data only once we've written everything we've previously read from the network share to the socket), and how windows buffers (Or doesn't) data from files being read over network shares.

May just be best to make this as available and leave it at that - doesn't seem like a high priority, unless we're seeing issues with local files as well, though would be great if we did something better.

Network bug triager here.   Following the advice in comment #5.   The fact that other browsers are better shows we have room for improvement, and lack of overlap between reads and writes sounds like a highly plausible cause.   

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Archiving this, since it's unlikely to be investigated.