Re: Queued tasks

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Queued tasks
by Rudd-O on Tuesday 23/Jan/2007, @20:34

This is not true. Modern Linux and UNIXes have advanced disk scheduling algorithms based on "elevators" (think of an elevator sweeping up and down a building) that avoid the thrashing and in practice two or three files copied simultaneously have almost no impact in total disk throughput. They also minimize the effects of disk fragmentation (though not so much).

Related Links

·   Articles on KDE Public Relations and Marketing
·   Also by Rudd-O
·   Contact author

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

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?

[ Reply To This | View ]

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 ]

Re: Queued tasks
by anonymous on Tuesday 23/Jan/2007, @23:45

you are wrong. although the elevator algorithm is rather good, you will still loose a lot of performance when copying two sequential files. reason being that for a single sequential file copy there is no seek time at all and the seek time is significantly larger than the time it takes to read a whole cylinder (ie. multiple sectors).

this problem becomes more significant as hdd size increases.

[ Reply To This | View ]

Re: Queued tasks
by superstoned on Wednesday 24/Jan/2007, @03:55

with a modern (>2.6.18) linux kernel and using the (default) CFQ scheduler, the performance difference will be very small (eg a few % max). so, not to worry about.

[ Reply To This | View ]

Re: Queued tasks
by giu73 on Wednesday 24/Jan/2007, @10:02

Can you expand on this? I don't really know how CFQ works, but, the "Fair" in its name makes me think that it would not be the best choice for this scenario. Basically, we have two large tasks, with a very high switching cost between the two. To optimize performance, we should minimize the number of switches, that is serving each task for a very long time interval before switching to the other (the best being serving one task until it is completely finished and then going to the other). This does not sound "Fair", to me.

[ Reply To This | View ]

Re: Queued tasks
by superstoned on Wednesday 24/Jan/2007, @10:21

but it is what CFQ does, both ensuring task interactivity AND increasing throughput. compared to the previous kernel scheduler, cfq uses longer timeslices, but has some logic to ensure reads don't slow down, and there are maximum waits for apps who want to read and write data.

[ Reply To This | View ]

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


		"coffee? kde developers drink tea ;)" -- Dirk Mueller
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.