Enable rsh or other way for fast file transfer
Dave
is quite old, the other is new.
1) Sun Blade 2000, 2 x 1200 MHz SPARC
2) Sun Ultra 27. Quad core 3.33 GHz Xeon.
I've stuck a Gigabit Ethernet card in the Blade 2000, so these have a gigabit
connection between them.
Transferring a 1000 MB file via ssh is taking 49 seconds (20 MB/s), compared to
the 11 seconds (91 MB/s) I can achieve with ftp. It's clear the Blade is
limiting the transfer speed, due to the speed of its CPU.
What are my options for a faster transfer between these two machines? I want to
do a recursive copy, so normal ftp is not convenient.
I can't seem to work out how to enable rcp to work. Can anyone tell me how?
Perhaps I can find an ftp client which can work recursively.
Security is not an issue - these is between two machines on a home LAN.
Any other suggestions?
Dave
Chris Ridd
> I have two Sun workstations which I want to copy a lot of data between
> - one Sun is quite old, the other is new.
>
> 1) Sun Blade 2000, 2 x 1200 MHz SPARC
> 2) Sun Ultra 27. Quad core 3.33 GHz Xeon.
>
> I've stuck a Gigabit Ethernet card in the Blade 2000, so these have a
> gigabit connection between them.
>
> Transferring a 1000 MB file via ssh is taking 49 seconds (20 MB/s),
> compared to the 11 seconds (91 MB/s) I can achieve with ftp. It's clear
> the Blade is limiting the transfer speed, due to the speed of its CPU.
>
> What are my options for a faster transfer between these two machines? I
> want to do a recursive copy, so normal ftp is not convenient.
>
> I can't seem to work out how to enable rcp to work. Can anyone tell me
> how? Perhaps I can find an ftp client which can work recursively.
Does using an efficient algorithm (eg blowfish) help?
--
Chris
Dave
I tried using blowfish, but I get a message there is no matching ciper. (See end
of posts for some outputs with various cipers tried).
I can't see why blowfish should not work, as I've not added anything to
sshd_config to limit the cipers that can be used: The only ciper I tried that
appears to work is 'aes128-ctr' and that took almost identical amount of time to
the secure copy where I did not specify the ciper. This rather makes me think
aes128-ctr' might be the default ciper.
I'm sure I've used 'blowfish' as a ciper on Solaris 10 machines before. But I
somewhat doubt the overhead will be so much lower that it will give a dramatic
increase in performance. I have noticed 'blowfish' faster in the past, but not
by a factor of 4, which is what I need to achieve here. That said, none of the
stuff had Gigabit connections then, so perhaps it was limited by the 100 Mbit/s
connection, rather than the CPU speed. Clearly here the CPU of the Blade 2000
can't keep up.
I'm going to try wget, to see if that works. I think if I enable the ftp server
on the machine with the data on, I can pull it off via wget. I'd rather use scp
if I could find out how to get it to work!
In the copies below, the machine 'swan' is the Blade 2000 running Solaris 10
update 7. The machine 'hawk' where the file is being transfered to is the Ultra
27 running OpenSolaris 06/2009.
drkirkby@swan:[~] $ scp fox drkirkby@hawk:.
fox 100%
|*************************************************************************************************************************************************|
1000 MB 00:48
drkirkby@swan:[~] $ time scp fox drkirkby@hawk:.
fox 100%
|*************************************************************************************************************************************************|
1000 MB 00:48
real 0m49.177s
user 0m41.599s
sys 0m11.323s
drkirkby@swan:[~] $ time scp -c blowfish fox drkirkby@hawk:.
no matching cipher found: client blowfish-cbc server
aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
lost connection
real 0m0.072s
user 0m0.003s
sys 0m0.006s
drkirkby@swan:[~] $ time scp -c blowfish-cbc fox drkirkby@hawk:.
no matching cipher found: client blowfish-cbc server
aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
lost connection
real 0m0.072s
user 0m0.002s
sys 0m0.006s
drkirkby@swan:[~] $ time scp -c aes128-ctr fox drkirkby@hawk:.
fox 100%
|*************************************************************************************************************************************************|
1000 MB 00:48
real 0m49.117s
user 0m41.504s
sys 0m11.430s
drkirkby@swan:[~] $ time scp -c aes192-ctr fox drkirkby@hawk:.
Unknown cipher type 'aes192-ctr'
lost connection
real 0m0.019s
user 0m0.007s
sys 0m0.013s
drkirkby@swan:[~] $ time scp -c aes256-ctr fox drkirkby@hawk:.
Unknown cipher type 'aes256-ctr'
lost connection
real 0m0.020s
user 0m0.007s
sys 0m0.013s
solx
If you use FileZilla on your Sun Blade 2000 to transfer the files using
port 22 (scp) it will create up to 10 simultaneous file transfers.
Filezilla will also handle recursive directory copying and creation.
Casper H.S. Dik
>I have two Sun workstations which I want to copy a lot of data between - one Sun
>is quite old, the other is new.
>1) Sun Blade 2000, 2 x 1200 MHz SPARC
>2) Sun Ultra 27. Quad core 3.33 GHz Xeon.
>I've stuck a Gigabit Ethernet card in the Blade 2000, so these have a gigabit
>connection between them.
>Transferring a 1000 MB file via ssh is taking 49 seconds (20 MB/s), compared to
>the 11 seconds (91 MB/s) I can achieve with ftp. It's clear the Blade is
>limiting the transfer speed, due to the speed of its CPU.
Is the CPU a 100% busy? The ssh protocol isn't fast even when you're not
encrypting.
>What are my options for a faster transfer between these two machines? I want to
>do a recursive copy, so normal ftp is not convenient.
Tar and move the tar file using any file exchange utility.
>I can't seem to work out how to enable rcp to work. Can anyone tell me how?
>Perhaps I can find an ftp client which can work recursively.
svcadm enable svc:/network/shell:default (on the receiving machine's side)
Casoer
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dave
Thank you.
That might help a bit, as the Blade 2000 has two 1200 MHz CPUs. But even if I
could double the throughput from 20 to 40 MB/s, it is still less than half of
what I get via ftp (91 MB/s).
I think wget will solve me problem. I initially had trouble, as the ftp server
would not accept the password. The password has a '$' symbol in it, and despite
putting the password in quotes
wget --mirror --ftp-user=drkirkby --ftp-password="yyyyy$x" ftp://swan/
the password would not work. I then tried escaping the '$' character, and that
seems to have solved it, so:
wget --mirror --ftp-user=drkirkby --ftp-password="yyyyy\$x" ftp://swan/
does look like it will copy from the host 'swan', at a little over 90 MB/s,
which is all I can reasonably expect from Gigabit ethernet. I'm actually
surprise it is achieving that, as I would have thought the SCSI bus in the Blade
2000 was not able to do that, but it seems to be ok.
Dave
Dave
> Dave <f...@coo.com> writes:
>
>> I have two Sun workstations which I want to copy a lot of data between - one Sun
>> is quite old, the other is new.
>
>> 1) Sun Blade 2000, 2 x 1200 MHz SPARC
>> 2) Sun Ultra 27. Quad core 3.33 GHz Xeon.
>
>> I've stuck a Gigabit Ethernet card in the Blade 2000, so these have a gigabit
>> connection between them.
>
>> Transferring a 1000 MB file via ssh is taking 49 seconds (20 MB/s), compared to
>> the 11 seconds (91 MB/s) I can achieve with ftp. It's clear the Blade is
>> limiting the transfer speed, due to the speed of its CPU.
>
> Is the CPU a 100% busy? The ssh protocol isn't fast even when you're not
> encrypting.
prstat shows 50%, but since there are two CPUs, it basically means the Blade
2000's CPU is the limit I think.
>> What are my options for a faster transfer between these two machines? I want to
>> do a recursive copy, so normal ftp is not convenient.
>
> Tar and move the tar file using any file exchange utility.
How would that compare with using 'wget', which does seem to be working? One
obvious downside is needing to create the tar file, which will take time. It's
my home directory, so there are a mix of file sizes ranging from half a dozen
bytes to the odd 4+ GB DVD iso image. I assume lot of processes being created
with small files might be inefficient.
>> I can't seem to work out how to enable rcp to work. Can anyone tell me how?
>> Perhaps I can find an ftp client which can work recursively.
>
> svcadm enable svc:/network/shell:default (on the receiving machine's side)
>
> Casoer
Thank you.
There are clearly many options for this file transfer. A nice comparison of
speeds would be nice. Perhaps I'll do that and write it on a web page. I do not
expect I am the first to hit this problem, and are probably not going to be the
last.
Dave
Casper H.S. Dik
>prstat shows 50%, but since there are two CPUs, it basically means the Blade
>2000's CPU is the limit I think.
Sounds indeed CPU limited. ssh isn't fast even when you use "none" as the
encryption algorithm.
>How would that compare with using 'wget', which does seem to be working? One
>obvious downside is needing to create the tar file, which will take time. It's
>my home directory, so there are a mix of file sizes ranging from half a dozen
>bytes to the odd 4+ GB DVD iso image. I assume lot of processes being created
>with small files might be inefficient.
That's fine; though typically updating every file one by one adds an additional
latency.
What I typically use is something like:
ufsdump/taretc | <local buffer> | <network> | <local buffer> | unpack
where "local buffer" is a program which stores and forwards data, specifically
because reading (finding) files, network and storing files all have different
latency and different variances. Network latency/throughput is constant
but reading/write a large file is quicker than reading/writing a bunch
of smaller files.
Casper
Colin B.
ncftp will do recursive FTP, if I'm not mistaken (and is a really great
ftp client in general).
Look up HPN-SSH - High performance networking additions to the SSH source
code. Amongst other things, it allows you to use "none" as a cipher with
SSH, and also can multithread a connection, using both of your CPUs. As a
bonus, it makes SSH much MUCH faster over high latency connections. (Not
your case between two local machines, but very useful in general.)
Colin
Dave
> Dave <f...@coo.com> writes:
>
>> prstat shows 50%, but since there are two CPUs, it basically means the Blade
>> 2000's CPU is the limit I think.
>
> Sounds indeed CPU limited. ssh isn't fast even when you use "none" as the
> encryption algorithm.
>
>> How would that compare with using 'wget', which does seem to be working? One
>> obvious downside is needing to create the tar file, which will take time. It's
>> my home directory, so there are a mix of file sizes ranging from half a dozen
>> bytes to the odd 4+ GB DVD iso image. I assume lot of processes being created
>> with small files might be inefficient.
>
> That's fine; though typically updating every file one by one adds an additional
> latency.
>
> What I typically use is something like:
>
> ufsdump/taretc | <local buffer> | <network> | <local buffer> | unpack
>
> where "local buffer" is a program which stores and forwards data, specifically
> because reading (finding) files, network and storing files all have different
> latency and different variances. Network latency/throughput is constant
> but reading/write a large file is quicker than reading/writing a bunch
> of smaller files.
>
> Casper
What program would you use as 'local buffer' though? I can see how this would
work in principle, but are unsure how to do this in practice.
I'm using wget (and have been for 7 hours), but have only tranfered 2.5 GB,
which is an average of about 1 MB/s. Clearly well below the 90 MB/s I can
achieve on large files via ftp. Therefore 'wget' does not seem to be the answer
if there are a lot of small files.
Perhaps once $HOME is copied, I'll try 'tar' for some other directories, though
these tend to have much larger files anyway.
Dave
> I'm using wget (and have been for 7 hours), but have only tranfered 2.5
> GB, which is an average of about 1 MB/s. Clearly well below the 90 MB/s
> I can achieve on large files via ftp. Therefore 'wget' does not seem to
> be the answer if there are a lot of small files.
Correction, it was 25 GB in 7 hours, not 2.5, so a rate of about 10 MB/s - still
well below the 90 MB/s I get on large files.
ITguy
> do a recursive copy, so normal ftp is not convenient.
>
rsync
Chris Ridd
Have you changed tcp_max_buf/tcp_xmit_hiwat/tcp_recv_hiwat on your
boxes? (cf the "solaris downloads much slower than linux" thread)
--
Chris
Canuck57
ssh/scp will always be slower than ftp because of the encryption and
compression. But try "scp -C ..." as it might help.
Second, while the old system may have a GB card in it, it may not be
able to feed the card at wire speed. Slower CPU and I/O bus, slower
disks etc. Not much you can do about that.
If your network is secure, try NFS and copy he files out of the mount.
Sami Ketola
> Transferring a 1000 MB file via ssh is taking 49 seconds (20 MB/s), compared to
> the 11 seconds (91 MB/s) I can achieve with ftp. It's clear the Blade is
> limiting the transfer speed, due to the speed of its CPU.
I doubt it. Since even if you disable encryption completely on the ssh connection
(yes it can be done if you really want to) you will find out that even then
copying files with scp is much slower than plain ftp.
> What are my options for a faster transfer between these two machines? I want to
> do a recursive copy, so normal ftp is not convenient.
nfs? tar? rsync over nfs?
Sami
--
Jim Leonard
wrote:
> nfs? tar? rsync over nfs?
I use rsync over rsh when I need fast syncing. I enable rsh only
between the two endpoints, then disable when done.
Michael Tosch
GNU Midnight Commander connects to the remote host with ftp,
presents it like a file system, and let you do a recursive
copy in either direction.
However it is interactive, and uses the F-Function keys.
rcp uses rsh.
In Solaris 10 you enable rsh service by command
inetadm -e svc:/network/shell:default
And you invite the calling host in ~root/.rhosts
The syntax is
+host root
The invited host must be an exact string match, i.e. as shown
after an ssh-login by the command
who am i
In case the rsh is much slower than ftp,
you should enable NFS server on the one host,
and have an NFS v3 mount on the other host.
--
echo imhcea\.lophc.tcs.hmo |
sed 's2\(....\)\(.\{5\}\)2\2\122;s1\(.\)\(.\)1\2\11g;1s;\.;::;2'