On Mon, Sep 3, 2018 at 5:07 AM, Jakub Jelen <jjelen@xxxxxxxxxx> wrote: > On Sun, 2018-09-02 at 22:16 -0600, Chris Murphy wrote: >> Fedora 28 Server >> Fedora 28 Workstation >> dd-wrt 802.11n Broadcom based router >> Connected wirelessly 5GHz, wired ethernet cable is physically >> disconnected from Server >> >> File transfer from Workstation to Server >> >> scp: scp itself reports ~620KB/s; where nload on the server reports >> ~4.9Mbit/s >> smb: GNOME reports 4.9MB/s; where nload on the server reports >> ~39.8Mbit/s >> >> Why? That's rather unexpected. >> >> Command is >> scp test.bin f28s.local:/srv/scratch >> >> Using nc, I get speeds slightly faster than smb. OK so encryption? If >> I connect wired, and then 'nmcli c down <ID>' to disconnect the >> wireless connection: >> >> scp: 12MB/s, nload ~101Mbit/s >> smb: nload ~96Mbit/s >> >> Sooooo, it's not encryption. Why would scp be this much slower only >> with a wireless connection? And using: >> >> rync -avzhe ssh test.bin f28s.local:/srv/scratch >> >> Over wireless, this is just as bad as scp. > > > SCP protocol is really slow, especially on networks with high latency > (wireless). The reason why is mostly the size of buffers, which is very > small and SCP waits for every part to be confirmed by the remote host > before sending another part. > > You can google "scp speed" and you will get a lot of answers, sometimes > wrongly accusing the encryption or the compression, but really, the RTT > and buffers are the fault as I write here: > > https://superuser.com/a/1101203/466930 > > SCP should be really used only as fast hack for copying files in fast > local networks. For all other cases, use SFTP or rsync if you need > something more complex. Going from server to workstation, I get double the rate according to nload. 9.1Mbit/s server to workstation, and 4.9Mbit workstation to server. Same results with: rsync test.bin chris@f28h.local:~/Downloads Does that automatically do it over ssh and end up with the same problems? Separate issue, but related, dd-wrt reports MAC Address Interface Uptime TX Rate RX Rate Info Signal Noise SNR Signal Quality 00:C2:C6:F0:52:53 wl1 3:07:21 243M 270M N/A -49 -89 40 100% 34:02:86:CC:D8:69 wl1 14:33:01135M 135M N/A -36 -89 53 100% :53 is workstation :69 is server The Fedora Workstation Tx and Rx rate is usually 270M but during idle it's often 6M. This is a: 6c:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] (rev 3a) The Fedora Server Tx and Rx rate is never greater than 135M even though it's closer to the AP. This is a: 02:00.0 Network controller [0280]: Intel Corporation Wireless 3165 [8086:3165] (rev 81) So for some reason, the server (an Intel NUC) never uses a rate higher than 135M. Anyway, in the case where the server is wired, the only 5Ghz wireless device is the workstation, so no relay. But if the server is wireless, then both server and workstation are competing and relay is happening. It might be this old WRT600N is starting to crap out, even though it's recently reflashed with a current version of dd-wrte. On 2.5Ghz, my Android phone freaks out every 2-3 days, kernel wake locks prevent the CPU from idling, and it soaks the battery at a 10%+ rate per hour doing nothing. Reboot the router? Problem solved for 2 more days. So does disassociating from that AP. Or airplane mode. Reassociating without rebooting the router instantly triggers the kernel wake locks. One of the weirder phone batter problems I've seen. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
