Hi
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?
Thanks.
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?
Thanks.
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.
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?
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?
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.
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?
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?
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.
Mirno
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.
Mirno
But it has an effect on compression, yes?
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).
Mirno
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).
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 =)
Thanks to you all for your advice, you will be noticed if I am done with my progg =)
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 :)
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 :)
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
large.
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.
system with it. Why anybody would set eg winamp to realtime priority
confuses me... just make sure the winamp decode buffers are sensibly
large.
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.