also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007.04.05.1126 +0200]: > I answer your private mail on the BTS (to keep track of things).
Sorry about that. > The 3500/350 kbps explains me why it takes so long (hours compared > to 15 min in my case). Right. Although it's not really a "slow" link. > However, i am a bit suprised that transfering several files at > once is longer than transfering only one. I was thinking that you > get a better time transfering more file on a LAN and that it makes > no difference transfering on a slow link... > > Do you have any idea ? In general I would tend to agree. However, this only applies if unison used separate SSH connections for each transfer. This does not appear to be the case, so it transfers everything in a single SSH tunnel, and thus it cannot go any faster, really. > >I am not talking about syncing per se. I am talking about the > >first time directories are transferred. > > You alway sync with unison... It is a file synchroniser ;-) Even > the first time it is syncing. Just making sure you know what I mean. > Anyway, i hope that i have understand your problem. Here is the > solution i will propose to upstream: * implement a flag/option > max-simultaneous-file-transfer which will limit the number of file > transfered in parallel * document that this option help to speed > up transfer on slow link * document that this option can reduce > the risk of an interruption/resume by processing a more > "step-by-step" transfer, since after having finished to transfer > a unit you won't loose it after resuming. > > Do you agree ? Yes, sounds great. Thanks! -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
