Holger Parplies wrote: > first of all, where are you seeing these figures, and what are you measuring?
Rather than try to convince you of my competence, I will offer up these benchmarks for the exact same endpoint machines and file (a 2 gigabyte uncompressable *.avi file that did NOT exist on the target): Unix rsync->Unix rsync: 60MB/s Windows SMB->Unix smbclient: 65MB/s Windows rsyncd->Unix rsync: 5MB/s Windows rsyncd->BackupPC_dump: 5MB/s As you can see, something is now clearly wrong with the windows rsyncd source. I confirmed this by profiling actual rsync in Unix and saw that 77% of its time was spent waiting for data (which mirrors exactly what File::RsyncP::pollsys was doing, wasting 77% of its time waiting for data). So the problem isn't BackupPC, it's windows rsyncd. I initially used cygwin rsync; for the above test, I switched it out for DeltaCopy's rsync. BOTH VERSIONS had this kind of crappy speed. Both versions showed hardly any CPU or filesystem usage; they just simply run slowly for a reason I can't figure out. The network isn't slow (gigabit ethernet), the checksums aren't taking a long time (it's a brand new file that doesn't exist on the target so there's nothing to checksum), the hard drive isn't slow (raid-0 SATA stripe capable of 130GB/s read speeds) -- it just simply serves data really really slowly. I can't believe this is an isolated incident. Other people have got to be seeing this. Other than cygwin and DeltaCopy, is there any specific version of rsyncd I should be using? Any flags I can set in BackupPC that can improve speed? > The primary purpose of the rsync protocol is to save network bandwidth. So if, > for example, you are transferring only one tenth the amount of data for a full > backup, and that takes the same time as with SMB, your network throughput will These are not incrementals, but full backups, and the speed as previously mentioned is 1/10th that of SMB. SMB backups are quite fast on this same infrastructure (around 65MB/s) but I can't use SMB because of XP/Vista/Win7 permission problems. > I believe Craig is researching other alternatives (a fuse FS to handle > compression and deduplication, so BackupPC could, in fact, use native rsync). I hope that doesn't become mandatory, because that would limit BackupPC to Unix versions that support FUSE (not all do). -- Jim Leonard ([email protected]) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
