On Fri, 9 Sep 2016 23:14:30 -0500 David Wright <deb...@lionunicorn.co.uk> wrote:
> On Fri 09 Sep 2016 at 20:36:39 (-0700), David Christensen wrote: > > On 09/09/2016 11:51 AM, Celejar wrote: > > > On Tue, 9 Aug 2016 18:57:02 -0700 > > > David Christensen <dpchr...@holgerdanske.com> wrote: > > > > > > ... > > > > > >> My laptop has 802.11 a/b/g WiFi and Fast Ethernet. Wireless data > > >> transfers are slow (~50 Mbps). Wired is twice as fast (100 Mbps); still > > >> slow. Newer WiFi (n, ac) should be faster, but only the newest WiFi > > >> hardware can match or beat Gigabit. > > > > > > You get ~50Mbps over a/b/g? 54Mbps is the theoretical maximum, and > > > everything I've read says that 20-24Mbps is the real-world maximum. > > > > > > Celejar > > > > > > > Benchmarking using WiFi (48 Mb/s): > > > > 2016-09-09 20:18:51 dpchrist@t7400 ~ > > $ time dd if=/dev/urandom of=urandom.100M bs=1M count=100 > > 100+0 records in > > 100+0 records out > > 104857600 bytes (105 MB) copied, 12.6709 s, 8.3 MB/s > > > > real 0m12.703s > > user 0m0.000s > > sys 0m12.481s > > > > 2016-09-09 20:19:32 dpchrist@t7400 ~ > > $ time scp -p urandom.100M samba:. > > urandom.100M > > > > > > 100% 100MB 1.5MB/s 01:08 > > > > real 1m16.023s > > user 0m4.548s > > sys 0m0.744s > > > > > > So, 1048576900 bytes * 8 bits / byte / 76.024 seconds > ↑ > > What's this 9? > > Cheers, > David. > Assuming the talk is about transfer rates over the medium, not something like pre-compression data rates (which might be called 'marketing-speak'). Good eye! I was going to say it's not possible to get 110Mb/s over 802.11g; 40-50 is closer tothe best I get. And 193Mb/s over 100Mb/s ethernet is right out; best I've ever managed is maybe 97Mb/s, and 92-95 is more typical. 11,034,157Mb/s on W/L and 19,338,838Mb/s on wired is *much* more believable. Unless one has a very fast multicore CPU with hardware crypto assistance, very fast RAM and the data to be transferred cached in RAM, one will probably never saturate a fastE or gigE link where one end must decrypt the data from disk/cache then encrypt the data to scp, and the other end must decrypt the data from scp then encrypt the data to disk. Even simple compression slows transfer down far too much. Now if one had many CPUs, hacked scp to open as many sockets and thread/child procs as there are CPUs, and had each thread work on a small-ish block of data at a time, one *might* be able to speed up the tranfser.
