Bug#417620: limit on simultaneous transfers
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)
Bug#417620: limit on simultaneous transfers
martin f krafft writes: also sprach [EMAIL PROTECTED] [EMAIL PROTECTED] [2007.04.04.1101 +0200]: Indeed, i encounter the same kind of problems... I think you have a lot of small files in each directory. This cause a very inefficient transfer. The files are 5Mb and there are about 12 to each directory. I answer your private mail on the BTS (to keep track of things). The 3500/350 kbps explains me why it takes so long (hours compared to 15 min in my case). 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 ? Beside this, i agree that a limit should exists, and i think upstream author will agree too. Moreover, the solution seems pretty easy to implement. Concerning, I answer your private mail on the BTS (to keep track of things). The 3500/350 kbps explains me why it takes so long (hours compared to 15 min in my case). 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 ? Beside this, i agree that a limit should exists, and i think upstream author will agree too. Moreover, the solution seems pretty easy to implement. Concerning, 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. 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 ? Regards Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417620: limit on simultaneous transfers
martin f krafft writes: Package: unison Version: 2.13.16-6 Severity: wishlist A directory which I synchronise with unison just got 11 new directories, each containing files totalling at around 500Mb. Unison has been running all day, but not a single directory was finished by the time I got hit by #417614. I thus decided *not* to synchronise it all at once, but to synchronise only 2-3 directories at a time. As a result, unison was done after only 3 hours. Please implement a means to limit the number of simultaneous transfers such that additional transfers are queued to take place once the slots free up. Indeed, i encounter the same kind of problems... I think you have a lot of small files in each directory. This cause a very inefficient transfer. I will forward the bug upstream. Regards Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417620: limit on simultaneous transfers
also sprach [EMAIL PROTECTED] [EMAIL PROTECTED] [2007.04.04.1101 +0200]: Indeed, i encounter the same kind of problems... I think you have a lot of small files in each directory. This cause a very inefficient transfer. The files are 5Mb and there are about 12 to each directory. -- .''`. 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)
Bug#417620: limit on simultaneous transfers
Package: unison Version: 2.13.16-6 Severity: wishlist A directory which I synchronise with unison just got 11 new directories, each containing files totalling at around 500Mb. Unison has been running all day, but not a single directory was finished by the time I got hit by #417614. I thus decided *not* to synchronise it all at once, but to synchronise only 2-3 directories at a time. As a result, unison was done after only 3 hours. Please implement a means to limit the number of simultaneous transfers such that additional transfers are queued to take place once the slots free up. Thanks, -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries Versions of packages unison recommends: ii openssh-client [ssh-client] 1:4.3p2-9 Secure shell client, an rlogin/rsh -- no debconf information -- .''`. 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)
