Re: Queued tasks

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Queued tasks
by Leo S on Tuesday 23/Jan/2007, @23:03

Well it sure is true on my system. Maybe I don't have this disk scheduling enabled or something.
But just try it, if you copy two files on the same disk at the same time, they don't slow down more than 50% each? I find that hard to believe, as it completely contradicts my experience on every system I've ever seen.

Can anyone back this up?

Related Links

·   Articles on KDE Public Relations and Marketing
·   Also by Leo S
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Queued tasks
by lanroth on Wednesday 24/Jan/2007, @02:43

I can back you up - it's an annoyance. Performance drops through the floor when copying multiple large files simultaneously.

It would be great if this job progress manager allowed one to pause a job until another one had finished.

Maybe:

RMB->file copy job->pause this job until this job has finished->another file copy job

This would have other benefits - you could start downloading a large .tar.gz, ask ark to extract it and then pause the task until the download had finished.

[ Reply To This | View ]

Re: Queued tasks
by Zan Lynx on Wednesday 24/Jan/2007, @09:37

Reminds me of the time I ran Nautilus (GNOME file-manager for you KDE guys :) on a multi-processor system, on a CDROM mounted directory.

Now, someone was smart and made Nautilus launch thumbnail generators in parallel, one for each CPU, and that is a good thing. Worked great on hard disk or network folders. However, on the CDROM I thought the system was going to crash, it got so laggy.

Read a bit of file here, seek, seek, seeeeeeeeeeek, read a bit of file over here, seeek, seeeeeeek, seeeeeeeek, repeat.

:)

[ Reply To This | View ]

Re: Queued tasks
by Corbin on Wednesday 24/Jan/2007, @15:37

In my experience it's often the opposite of what you state (1 transfers at X MB/s, 2 at 1.5 X MB/s which often confuses me, though at some point adding more does cause it to go slower), though I think that a configuration option (probably would have to be in Konqueror, with the options based on the kio-slave) to say the number of concurrent transfers before queuing up new ones (with an option to allow 'infinite')

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"I didn't know there was a superlative of 'Warmduscher'." -- Carsten Pfeiffer
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.