[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-optimize
Subject:    Re: Speed of protocol fish
From:       Werner Modenbach <modenbach () alc ! de>
Date:       2006-05-10 14:18:03
Message-ID: 200605101618.03596.modenbach () alc ! de
[Download RAW message or body]

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 ISO 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:
> On 09/05/06, Werner Modenbach <modenbach@alc.de> wrote:
> > 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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-optimize
_______________________________________________
Kde-optimize mailing list
Kde-optimize@kde.org
https://mail.kde.org/mailman/listinfo/kde-optimize
[prev in list] [next in list] [prev in thread] [next in thread]