NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Upgrading openssh help
Hi all, I've been suffering from really slow rsync speeds when copying files from one NV+ to another. Speeds around 700k/sec compared to having a computer in between doing the copying via afp/nfs...
You're just not going to get 30 MB/sec on an NV+ with rsync. I get about 4 MB/sec on my rsync backup jobs (which uses the daemon method) - remote source is my Pro-6. So I think the results you are getting are normal.
Eirik in the original post says he got 7.5 MB/sec, but that was his only post (ever) so we can't follow up with him. But from the script, it appears that he built SSL, which isn't relevant if you don't use encryption. We don't know anything about his network setup, or how much memory was in his NAS. You could perhaps enable jumbo frames and see if you get any improvement.
Apart from that I have no suggestions.
jak0lantash wrote:
So you're using Rsync, not Rsync over SSH...
Which means that upgrading ssl won't improve the performance - because you aren't using ssl for this anyway.
What performance are you seeing?
Sorry for the delay, had to sort out some cabling.
I'm quite confused.. My understanding is that by default rsync uses SSH for its communication - regardless of the -e prefix.
I'm reading more about it,
http://linux.die.net/man/1/rsync
"There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP. The remote-shell transport is used whenever the source or destination path contains a single colon (:) separator after a host specification. Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync://"
I believe I'm using SSH, because this is how I'm running it,
xn1:/media/iso# rsync -av --progress large.iso xn2:/media/Files/
sending incremental file list
large.iso
21594112 3% 1.45MB/s 0:07:06
The above just has both NASs connected via a gigabit switch via cat6. Granted I'm surprised as usually it's half that speed.
NAS1 ----(1G)---- Switch ----(1G)---- NAS2
While if I plug my MAC to the switch, mount both NAS's on my Mac via AFP/CIFS/NFS, drag and drop from one to the other via Finder, it's at least 10 times faster - 30MB+/sec. I could take a screenshot but it means I have to connect in the garage :)
Mac ----(1G)---- Switch -----(1G)----- NAS1 and NAS2
Edit: Here's an example from my Mac, connected via Wifi to the airport express connected via 100M link to the switch.
Mac ----(wifi)--- Airport Express ------(100M) ----- Switch -------(1G)------ NAS1 and NAS2
Yes it's not as fast as Gigabit ethernet, but again it's pushing some good limits with ~5.6M/sec and should show what I'm talking about when compared to the 2 NASs.
rsync -av --progress large.iso xn2:/media/Files/
This doesn't use SSH
http://www.tecmint.com/rsync-local-remote-file-synchronization-commands/
Mate, I'm quite certain it uses SSH as a protocol. It's like the rsync documentation says
"using a remote-shell program as the transport (such as ssh or rsh)"
"The remote-shell transport is used whenever the source or destination path contains a single colon"
Granted the above in red is really confusing in referring to remote-shell == ssh, but it should mean using a protocol such as rsh or ssh... I presume that's where the confusion is.
# rsync my.file 172.24.106.123:/var/tmp/
Password:Result:
[root@foo] ~ # tshark -r /var/tmp/rsync_test.cap 1 <snip> 2 9.516019 172.24.106.122 -> 172.24.106.123 TCP 74 34309 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=3731814100 TSecr=0 WS=128 3 9.516090 172.24.106.123 -> 172.24.106.122 TCP 74 ssh > 34309 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=3731994813 TSecr=3731814100 WS=128 4 9.516944 172.24.106.122 -> 172.24.106.123 TCP 66 34309 > ssh [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=3731814102 TSecr=3731994813 5 9.929440 172.24.106.123 -> 172.24.106.122 SSH 87 Server Protocol: SSH-2.0-OpenSSH_5.3\r 6 9.930704 172.24.106.122 -> 172.24.106.123 TCP 66 34309 > ssh [ACK] Seq=1 Ack=22 Win=14720 Len=0 TSval=3731814516 TSecr=3731995226 7 9.930952 172.24.106.122 -> 172.24.106.123 SSH 87 Client Protocol: SSH-2.0-OpenSSH_5.3\r 8 9.931024 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34309 [ACK] Seq=22 Ack=22 Win=14592 Len=0 TSval=3731995228 TSecr=3731814516 9 9.933026 172.24.106.122 -> 172.24.106.123 SSHv2 442 Client: Key Exchange Init 10 9.933059 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34309 [ACK] Seq=22 Ack=398 Win=15616 Len=0 TSval=3731995230 TSecr=3731814517 11 9.938326 172.24.106.123 -> 172.24.106.122 SSHv2 490 Server: Key Exchange Init 12 9.947816 172.24.106.122 -> 172.24.106.123 SSHv2 338 Client: Diffie-Hellman Key Exchange Init 13 9.967178 172.24.106.123 -> 172.24.106.122 SSHv2 914 Server: New Keys 14 9.976503 172.24.106.122 -> 172.24.106.123 SSHv2 82 Client: New Keys 15 10.016117 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34309 [ACK] Seq=1294 Ack=686 Win=16640 Len=0 TSval=3731995313 TSecr=3731814559 16 10.017505 172.24.106.122 -> 172.24.106.123 TCP 118 [TCP segment of a reassembled PDU] 17 10.017544 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34309 [ACK] Seq=1294 Ack=738 Win=16640 Len=0 TSval=3731995314 TSecr=3731814602 18 10.017820 172.24.106.123 -> 172.24.106.122 TCP 118 [TCP segment of a reassembled PDU] 19 10.019201 172.24.106.122 -> 172.24.106.123 TCP 134 34309 > ssh [PSH, ACK] Seq=738 Ack=1346 Win=17408 Len=68 TSval=3731814604 TSecr=3731995315[Reassembly error, protocol TCP: Dissector writer didn't bother saying what the error was] 20 10.020409 172.24.106.123 -> 172.24.106.122 TCP 150 ssh > 34309 [PSH, ACK] Seq=1346 Ack=806 Win=16640 Len=84 TSval=3731995317 TSecr=3731814604[Reassembly error, protocol TCP: Dissector writer didn't bother saying what the error was] 21 10.021773 172.24.106.122 -> 172.24.106.123 TCP 438 34309 > ssh [PSH, ACK] Seq=806 Ack=1430 Win=17408 Len=372 TSval=3731814606 TSecr=3731995317[Reassembly error, protocol TCP: Dissector writer didn't bother saying what the error was]
<snip>-e isn't needed. It's just used to specify the remote shell to use or if you have additional paramenters, like using a different port etc.. You don't need it. If you use a single colon as above, it will use SSH. Here's the same file copied with -e
# rsync -e ssh my.file 172.24.106.123:/var/tmp/ Password:
and result (same..)
[root@foo] ~ # tshark -r /var/tmp/rsync_e.cap
1 <snip> 2 8.004732 172.24.106.122 -> 172.24.106.123 TCP 74 34350 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=3732482352 TSecr=0 WS=128 3 8.004799 172.24.106.123 -> 172.24.106.122 TCP 74 ssh > 34350 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=3732663061 TSecr=3732482352 WS=128 4 8.005878 172.24.106.122 -> 172.24.106.123 TCP 66 34350 > ssh [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=3732482357 TSecr=3732663061 5 8.333778 172.24.106.123 -> 172.24.106.122 SSH 87 Server Protocol: SSH-2.0-OpenSSH_5.3\r 6 8.334641 172.24.106.122 -> 172.24.106.123 TCP 66 34350 > ssh [ACK] Seq=1 Ack=22 Win=14720 Len=0 TSval=3732482685 TSecr=3732663390 7 8.334908 172.24.106.122 -> 172.24.106.123 SSH 87 Client Protocol: SSH-2.0-OpenSSH_5.3\r 8 8.335232 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34350 [ACK] Seq=22 Ack=22 Win=14592 Len=0 TSval=3732663392 TSecr=3732482685 9 8.335953 172.24.106.122 -> 172.24.106.123 SSHv2 442 Client: Key Exchange Init 10 8.335975 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34350 [ACK] Seq=22 Ack=398 Win=15616 Len=0 TSval=3732663393 TSecr=3732482687 11 8.349915 172.24.106.123 -> 172.24.106.122 SSHv2 490 Server: Key Exchange Init 12 8.357833 172.24.106.122 -> 172.24.106.123 SSHv2 338 Client: Diffie-Hellman Key Exchange Init 13 8.377945 172.24.106.123 -> 172.24.106.122 SSHv2 914 Server: New Keys 14 8.387377 172.24.106.122 -> 172.24.106.123 SSHv2 82 Client: New Keys 15 8.428205 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34350 [ACK] Seq=1294 Ack=686 Win=16640 Len=0 TSval=3732663485 TSecr=3732482737 16 8.429542 172.24.106.122 -> 172.24.106.123 TCP 118 [TCP segment of a reassembled PDU] 17 8.429573 172.24.106.123 -> 172.24.106.122 TCP 66 ssh > 34350 [ACK] Seq=1294 Ack=738 Win=16640 Len=0 TSval=3732663486 TSecr=3732482780 18 8.430036 172.24.106.123 -> 172.24.106.122 TCP 118 [TCP segment of a reassembled PDU] 19 8.430984 172.24.106.122 -> 172.24.106.123 TCP 134 34350 > ssh [PSH, ACK] Seq=738 Ack=1346 Win=17408 Len=68 TSval=3732482782 TSecr=3732663486[Reassembly error, protocol TCP: Dissector writer didn't bother saying what the error was] 20 8.433597 172.24.106.123 -> 172.24.106.122 TCP 150 ssh > 34350 [PSH, ACK] Seq=1346 Ack=806 Win=16640 Len=84 TSval=3732663490 TSecr=3732482782[Reassembly error, protocol TCP: Dissector writer didn't bother saying what the error was] <snip>Can you try a test that uses the double-colon and measure the speed that way?
Do you actually need encryption on this particular connection?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
