Tino Schwarze 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 would take a look at a network traffic dump - maybe something is bad
> there? More suspects: Windows firewall, some other firewall inbeteween?
> Did you try Windows rsyncd -> Windows rsync (to rule out some strange
> Linux vs. Windows network stack issue)?

The usual killer with windows targets is an on-access virus scanner, but that 
doesn't explain the SMB speed unless there is some kind of exception there.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT 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
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/