Hi there,
this is my first posting on this list, so please apologise for any violations
of rules here.
Today I tried to make a backup of a big amount of data to our fileserver using
drag and drop in konqueror and fish for access protocol to the server.
I recognised a limitation of speed of about 1MB/sec. which is really
unsatisfying. So I cancelled the copy process. When doing drag and drop with
more than 10 subdirs of my data separately in parallel I recognised the same
limit for each transfer. But the total transfer rate of all copies was about
10MB/sec. . So this should not be a limit of disk access, CPU power or the
network.
What is the reason for the limitation? Is there anything I can do here?
Thanks for any hints.
- Werner -
Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org

09/05/06, Werner Modenbach <modenbach (AT) alc (DOT) dewrote:
I recognised a limitation of speed of about 1MB/sec. which is really
unsatisfying. So I cancelled the copy process. When doing drag and drop with
more than 10 subdirs of my data separately in parallel I recognised the same
limit for each transfer. But the total transfer rate of all copies was about
10MB/sec. . So this should not be a limit of disk access, CPU power or the
network.
What is the reason for the limitation? Is there anything I can do here?

I don't know the fish protocol, but the usual reason for multiple
streams going faster than a single stream is latency (e.g. time for
the other end to ack the data). You can sometimes reduce the effect of
end-to-end latency on throughput by reading and writing in larger
'chunks' - is there an option regarding that?

jb

Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org

Hi John,

thanks for your fast answer.
As far as I understand fish is the same than using scp except it isn't on a
command line but implemented as a protocol in KDE.
When using scp in a shell transfers are significantly faster!!!
You can easily verify that by copying a large file i.e. a CD IS image to a
server using both methods.
To my knowledge there is no option in konqueror or KDE to manipulate chunk
sizes.
- Werner -
Am Mittwoch, 10. Mai 2006 15:57 schrieb John Berthels:
09/05/06, Werner Modenbach <modenbach (AT) alc (DOT) dewrote:
I recognised a limitation of speed of about 1MB/sec. which is really
unsatisfying. So I cancelled the copy process. When doing drag and drop
with more than 10 subdirs of my data separately in parallel I recognised
the same limit for each transfer. But the total transfer rate of all
copies was about 10MB/sec. . So this should not be a limit of disk
access, CPU power or the network.
What is the reason for the limitation? Is there anything I can do here?

I don't know the fish protocol, but the usual reason for multiple
streams going faster than a single stream is latency (e.g. time for
the other end to ack the data). You can sometimes reduce the effect of
end-to-end latency on throughput by reading and writing in larger
'chunks' - is there an option regarding that?

jb

Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org

Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org

Werner Modenbach wrote:
Hi there,

this is my first posting on this list, so please apologise for any violations
of rules here.

Today I tried to make a backup of a big amount of data to our fileserver using
drag and drop in konqueror and fish for access protocol to the server.

I recognised a limitation of speed of about 1MB/sec. which is really
unsatisfying. So I cancelled the copy process. When doing drag and drop with
more than 10 subdirs of my data separately in parallel I recognised the same
limit for each transfer. But the total transfer rate of all copies was about
10MB/sec. . So this should not be a limit of disk access, CPU power or the
network.
What is the reason for the limitation? Is there anything I can do here?

try sftp:// I've also used fish for a long time, and sftp works much
better, and is not such a hack than fish

best regards,
Yves

Thanks for any hints.
- Werner -
Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org

Thanks, I'll do some test on it.
- Werner -
Am Mittwoch, 10. Mai 2006 15:52 schrieb Yves Glodt:

try sftp:// I've also used fish for a long time, and sftp works much
better, and is not such a hack than fish

Kde-optimize mailing list
Kde-optimize (AT) kde (DOT) org