Timothy J. Massey wrote: > The C3 is slow. I get it. I already *knew* that. However, the > performance numbers I posted demonstrate pretty clearly that the > failure is not in a simple lack of CPU power, but in truly how *much* > CPU power rsync demands. I get triple the performance in switching > from rsync to SMB. Same CPU, same network, same hard drives, > different protocol. Sure, I see that. I was only pointing out that the conditions of this code might be right to cause worse than normal performance for the C3 for any number of reasons, making it buckle under the load sooner. Not that it's a bad config at all. > > And interestingly enough, the load is far higher on the computer I'm > backing up, not the poor little C3. It takes a 2.6GHz Xeon with SCSI > RAID drives to force my anemic C3 to 100% utilization. I can live > with that. So while my C3 is leaving *some* performance behind, it's > nowhere near enough to cause me to switch from the tiny, attractive, > quiet, reliable, affordable package I have develeped around the EPIA. > (The DMA issue, though, might be. At least to a different motherboard.) All my machines here are older except my primary dev box (2.4ghz P4 w/HT). And on that machine, I use SMB to back it up, simply because it's a WinXP box and it responded well to SMB. I had another Win2k box over a quarter-speed WDS 802.11g link that would fail over SMB due to occasional interference that I *had* to switch to rsyncd just so it could complete--and I had to stage the introduction of directories with large files to the backup system so I could get them into the pool and have the backups complete at all (an incomplete backup due to lost connection does *not* enter new files into the pool, even if they completed, wasting that transfer time.. the single most serious flaw in BackupPC if you ask me). > > The whole reason I got involved in this discussion is because others > have repeatedly said that they get outstanding performance from > cast-off machines. That may be true: but it wasn't true for me. I > wanted to know why. And the reason is not the C3. It's rsync. My PPro200mhz server connects with SMB for my faster WinXP client with a quick network connection. I use rsyncd for a Win2k box over a slow wireless link. I used rsync+ssh on two older linux boxes and switched them to rsyncd to avoid privilege escalation and to hopefully improve performance a little. > > Are there others out here using rsyncd? What type of performance do > you get?
Maybe that statistic doesn't mean what you think it means. The number of MB/s that you get *should* decrease after your first full backup. That number, Craig correct me, is the amount of changed data transferred to the server, divided by the amount of time the backup took to run. The time the backup inspects files that did not change or get transferred is included in that time, reducing the apparent throughput. Rsync itself has lousy throughput too, so it makes it look worse. The only time this would be an accurate reflection of protocol throughput is when the pool is bone dry. The more files match the pool, the more time (relatively) the client machine will spend on files that will ultimately not be transferred and will not increase the data transferred. This is a good thing. So, the statistic is a little misleading. If you *were* getting something very high for that number, I think it means you've got something wrong with your pool, because no files are matching their checksums. For reference, none of my backups are over 1MB/s, and some are about 0.1MB/s because nothing changes except a few log files. One take-away from this is, if you have a number of large files that have scattered changes every week, maybe rsync is not the right protocol for that client? Thanks, JH ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
