I know how I can set the Scheduling-priority with CreateProcess if I want to start a new process, but how can I change the priority of my currently running app?

Posted on 2001-12-14 04:45:58 by nyook
Use the SetPriorityClass() API function. Check out the doco for it here. Note that you options are different depending on what version of Windoze you are running.
Posted on 2001-12-14 05:10:28 by sluggy
Thank you very much!

What about using realtime priority for a file compressor? I dont think this makes much sense, because I believe it can have an affect to the stability.
So I think Highpriority is enough, it can consume a lot of cpu time, too.

What do you think?
Posted on 2001-12-14 05:56:37 by nyook
Using realtime shouldn't cause any problem, but OTOH you shouldn't really need to set it. The only thing i would set to realtime is Winamp or some other media player, and then i would only do that if i had some other heavy process going on, like a huge unzip process, or a long virus scan.
Posted on 2001-12-14 06:49:30 by sluggy
i see.

How much can it affect the filetransfer speed? (From normal-p to high-p)? I don't think very much. But it will have a noteable improvement on compression algorithms, won't it?
Posted on 2001-12-14 07:44:57 by nyook
File transfer is dog slow, no matter what medium you use.

Modems - 56 kbits per second
*DSL - 512 kbits per second
HDD - 33 Mbytes per second

Processor bandwidth 2.1 Gbytes per second :D

You cannot hope to saturate the processor with any file transfer, unless you are doing about a million of them (even then you'll clog the PCI bus before you strain the processor).
You could need real-time priority if you really tried hard enough (transfer half your memory to the other half repeatedly, while reading a floppy disk, your hdd, CD-ROM, and a Zip disk, then deposting random data to the texture memory of your GFX card over an AGPx4 bus, all that while hosting an ultra popular web-site over a T1 line, but other than that.....).

Basically don't worry about it! You'll suffer more from data loss and noise than your processor chokeing up.

Posted on 2001-12-14 08:26:31 by Mirno
But it has an effect on compression, yes?
Posted on 2001-12-14 08:32:41 by nyook
It will have an effect on the speed of the compression, but the data will still get sent at the same rate. All you need to make sure is that the compression is faster than the send rate, then your pipeline will always be full.

Once you are at this situation, it doesn't really matter how much faster you compress (at least in terms of the file transfer). I'm not sure how good the task scheduler is in Windows, but it should pause a task that cannot do anything because of a stall (say sending data), so it being any higher priority will not affect it (other than it filling the send buffer a micro second sooner).

Posted on 2001-12-14 09:03:24 by Mirno
Ok, but if I have more CPU time left, I can use a compression which uses more CPU time, without slowing down the speed i send the data.

Thanks to you all for your advice, you will be noticed if I am done with my progg =)
Posted on 2001-12-14 10:57:31 by nyook
I think i understand what you are getting at, you want to change the type of compression based on what cpu the user has, and what speed it is running at, etc.

IMHO, you are being too nice to the user by worrying about this sort of thing (at work, i have a business analyst who is always nagging me to be nicer/friendlier to the user with my applications ;().

As Mirno was saying, the only way that you are going to be able to transmit at a speed that exceeds the compression rate is if the user is running an old 286 or something :)
Posted on 2001-12-15 05:17:55 by sluggy
RealTime priority is a dangerous beast. You can basically lock up your
system with it. Why anybody would set eg winamp to realtime priority
confuses me... just make sure the winamp decode buffers are sensibly

I would keep a compression thread at NORMAL priority. That way it
will have the least effect on the responsiveness of the system. Changing
the thread priority shouldn't really make the compression any faster...
compression tends to be pretty slow and compute-intensive, so
you'd just get a sluggish system by increasing thread priority, while
doing the compression perhaps... what... 1 second faster?

As for boosting priority, dunno really. Might want to boost it a bit
for important threads in a game.
Posted on 2001-12-15 08:35:00 by f0dder