Friday, April 2, 2010

Rsync slowness?

I was having some slow rsync issues on my all gig ethernet network. I was rsyncing as such and was having less than stellar download speeds. My network is setup with one macbook, a linksys routers[gig ethernet](one of the slightly higher end models not the standard wrt54g). And it's connected on my fedora box, here are the speeds I was getting:

My "rsync -avz -P /Users/lane/Downloads/ root@192.168.1.201:/home/lane/Downloads/rsync/":
Code:
Bones/Bones Season 2/Bones.S02E05.HDTV.XviD.avi
366486588 100% 7.42MB/s 0:00:47 (xfer#11, to-check=858/1014)
Bones/Bones Season 2/Bones.S02E06.HDTV.XviD.avi
365428736 100% 7.41MB/s 0:00:47 (xfer#12, to-check=857/1014)
Bones/Bones Season 2/Bones.S02E07.HDTV.XviD.avi
366942838 100% 6.59MB/s 0:00:53 (xfer#13, to-check=856/1014)
Bones/Bones Season 2/Bones.S02E08.HDTV.XviD.avi
366863346 100% 7.25MB/s 0:00:48 (xfer#14, to-check=855/1014)
Bones/Bones Season 2/Bones.S02E09.HDTV.XviD.avi
366988952 100% 7.08MB/s 0:00:49 (xfer#15, to-check=854/1014)
Bones/Bones Season 2/Bones.S02E10.HDTV.XviD.avi
366969326 100% 6.37MB/s 0:00:54 (xfer#16, to-check=853/1014)
Bones/Bones Season 2/Bones.S02E11.HDTV.XviD.avi
366988976 100% 7.19MB/s 0:00:48 (xfer#17, to-check=852/1014)
Bones/Bones Season 2/Bones.S02E12.HDTV.XviD.avi
366975374 100% 7.60MB/s 0:00:46 (xfer#18, to-check=851/1014)
Bones/Bones Season 2/Bones.S02E13.HDTV.XviD.avi
367679488 100% 6.76MB/s 0:00:51 (xfer#19, to-check=850/1014)
Bones/Bones Season 2/Bones.S02E14.HDTV.XviD.avi
367340574 100% 6.69MB/s 0:00:52 (xfer#20, to-check=849/1014)
Bones/Bones Season 2/Bones.S02E15.HDTV.XviD.avi
366983676 100% 6.98MB/s 0:00:50 (xfer#21, to-check=848/1014)
Bones/Bones Season 2/Bones.S02E16.HDTV.XviD.avi
366794752 100% 7.34MB/s 0:00:47


I ran this command on my linux box
ethtool -s eth0 speed 1000 duplex full
I think ifconfig eth0 down then ifconfig eth0 up and restarted the rsync.
And the speeds increased but not dramatically:

ue_Gender1-26(complete)/zx.blue.gender.05.divx503.ogm
237303388 100% 17.56MB/s 0:00:12 (xfer#1, to-check=887/1014)
Blue_Gender1-26(complete)/zx.blue.gender.06.divx503.ogm
238456995 100% 11.51MB/s 0:00:19 (xfer#2, to-check=886/1014)
Blue_Gender1-26(complete)/zx.blue.gender.07.divx503.ogm
237551102 100% 5.34MB/s 0:00:42 (xfer#3, to-check=885/1014)
Blue_Gender1-26(complete)/zx.blue.gender.11.divx503.ogm
243860297 100% 16.20MB/s 0:00:14 (xfer#4, to-check=881/1014)
Blue_Gender1-26(complete)/zx.blue.gender.12.divx503.ogm
242815771 100% 16.70MB/s 0:00:13 (xfer#5, to-check=880/1014)
Blue_Gender1-26(complete)/zx.blue.gender.13.divx503.ogm
239553347 100% 20.09MB/s 0:00:11 (xfer#6, to-check=879/1014)
Blue_Gender1-26(complete)/zx.blue.gender.14.divx503.ogm
237805952 100% 11.54MB/s 0:00:19 (xfer#7, to-check=878/1014)
Blue_Gender1-26(complete)/zx.blue.gender.15.divx503.ogm
237405118 100% 16.57MB/s 0:00:13 (xfer#8, to-check=877/1014)
Blue_Gender1-26(complete)/zx.blue.gender.16.divx503.ogm
238030584 100% 17.48MB/s 0:00:12 (xfer#9, to-check=876/1014)
Blue_Gender1-26(complete)/zx.blue.gender.20.divx503.ogm

However, this still isn't satisfactory. After some more investigation I started using the mii-tool
mii-tool -v
Which showed that my eth0 card was still at the same speed:
eth0: negotiated 100baseTx-FD flow-control, link ok

This does not explain the speed increase if this tool is accurate.
I decided to then investigate the mac and after a greping of the dmesg found this:
sudo dmesg |grep 'en0'
Ethernet [AppleYukon2]: Link up on en0, 1-Gigabit, Full-duplex, Symmetric flow-control, Debug [796d,af08,0de1,0200,cde1,2800]

And while it is not definite proof that the port is running at gigabit it does make me want to look to other areas for a speed boost. Does rsync just have an incredible amount of overhead? Or is there something else wrong? And if something else is wrong, is it the router, or one of the boxes...perhaps I should just be less picky about my speeds. If you have any answers let me know.

2 comments:

Kyle said...

By default, when invoked as you show, rsync uses SSH. You may be seeing slowness as a result of the SSH encrypt/decrypt process.

There is an invocation to request that SSH not encrypt, or encrypt with lesser/faster encryption, which might speed things up quite a bit, if you the lesser security is OK for your situation.

bsdpunk said...

I've been thinking the same thing Kyle and will be investigating further. Although my fedora box crashed due to some unstable test packages I installed, so further studies will probably be done on arch being that I just set up.