Edgar Fuß <ef%math.uni-bonn.de@localhost> writes: > [There was a thread started by me on the same subject (scp throughput) > in August 2019.] > >> 1. install iperf3 and run that. > That gives me >500 Mbits/sec, about half what I would expect at best. With 10 streams in parallel (-P 10), I see 559 Mb/s, on a GbE wired network between a 2014 computer (netbsd9) and a 2010 computer (current). I got 549 Mb/s with one stream. I do not understand why you expect more than 1000 Mbits/s. I would not realistically expect more than 800 Mb/s on 1000 Mb/s physical medium, with headers, but I am using hand-me-down computers mostly. However, this establishes that your interfaces, kernel, wiring, switches are capable of 500 Mb/s. >> 2. run netstat -s (on both machines) before and after the test, and diff them > Attached. I wouldn't know what to look for. Note that the sending host is doing > a *lot* of other things in parallel. You are looking for things that are not expected, which is why I advise diffing before/after, not checking specific things. Skimming "send", this seems higher than I'd expect: - 120493495 out-of-order packets (107507515 bytes) + 120493701 out-of-order packets (107507515 bytes) >> 3. receive cpu usage seems high. > All cores are >50% idle (according to top -1) on both sides (minus CPU0 on the > sending end, which is only ~25% idle and ~25% interrupt) during scp. > > Disabling HPN raises scp throughput from 10MB/s to 25MB/s. Wow. There have been reports that HPN isn't working well. So turn it off and move on. > So raw througput is about half of what I'd expect, and SSH throughput is > (with HPN disabled) about half of what I'd expect based in raw troughput. > And SSH throughput with HPN enabled is less than half of that. Now that you've measured TCP without ssh, you can measure reading from the filesystem on the sender with dd, and writing to the filesystem on the receiver also with dd.
Attachment:
signature.asc
Description: PGP signature