Re: ssh None cipher

From: Freddie Cash <fjwcash_at_gmail.com>
Date: Mon, 3 Nov 2014 09:59:23 -0800
On Sat, Oct 18, 2014 at 12:32 PM, Allan Jude <allanjude_at_freebsd.org> wrote:

> On 2014-10-18 13:21, Freddie Cash wrote:
> > On Oct 18, 2014 3:54 AM, "Mark Martinec" <Mark.Martinec+freebsd_at_ijs.si>
> > wrote:
> >>
> >> If the purpose of having a none cipher is to have a fast
> >> file transfer, then one should be using  sysutils/bbcp
> >> for that purposes. Uses ssd for authentication, and
> >> opens unencrypted channel(s) for the actual data transfer.
> >> It's also very fast, can use multiple TCP streams.
> >
> > That's an interesting alternative to rsync, scp, and ftp, but doesn't
> help
> > with zfs send/recv which is where the none cipher really shines.
> >
> > Without the none cipher, SSH becomes the bottleneck limiting transfers to
> > around 400 Mbps on a gigabit LAN. With the none cipher, the network
> becomes
> > the bottleneck limiting transfers to around 920 Mbps on the same gigabit
> > LAN.
> >
> > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs.
>
> Actually, looking into it, the bbcp command can support a pipe at each
> end instead of files, so you can actually do a zfs send | zfs receive
> via bbcp, and use multiple concurrent connections, to get around TCP
> window stuff when going transatlantic
>
> I am going to be trying it out shortly.
>
> Note: the other big improvement in newer ssh is the HPN stuff, that is
> switched on since 9.2 I think.


​After much finagling and testing, I have managed to incorporate bbcp into
my ZFS send/recv script.  And it works much better than regular, encrypted
SSH in my setup.

Regular SSH transfers tended to top out around 400 Mbps, using 100% of 1
CPU.  Was not able to get the multi-threadded AES cipher working.

SSH connections using the NONE cipher saturated the gigabit link with
minimal CPU usage.

And a bbcp connection is currently running between 500-800 Mbps (depending
on the size of the snpashot), also with minimal CPU usage.

NOTE:  I expect this be running much better next week, as the receiving
pool is currently resilvering a drive, slowing everything down.


Got things working using the following bbcp command format:

bbcp -N io "zfs send -I pool/fs_at_snap1 pool/fs_at_snap2" username_at_remotesys:"zfs
recv -d pool"


Have not played with any of the myriad tuning options for bbcp.  Just
wanted to see if I could get it to work, and how an untuned connection
compared to an untuned SSH connection (with and without NONE cipher).  So
far, I'm impressed.

​Thanks for the suggestion.  It's another tool in the box.  :)​

-- 
Freddie Cash
fjwcash_at_gmail.com
Received on Mon Nov 03 2014 - 16:59:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:53 UTC