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.

Reply via email to