Nice/2 ???
Dariusz Piatkowski
dynamically adjust the priority and class of any given process.
The version I got is, as far as I can tell, the latest available one : 0.7
Here is my problem: upon starting up the server I am supposed to be able to get
a 'priority adjustment' choice in the Task List context menu...well, nothing
like that appears on my system.
If I fire up the 'nicecc.exe' executable, which is the PM Control Center, even
though I can see the process stats, selecting a priority -/+ adjustment doesn't
seem to work.
Has anyone had any luck getting this to work?
It seems like a really nifty utility...
Dave Yeo
I could of sworn this used to work for me, but trying now it doesn't.
What does work for me is the plugin for WatchCat allowing renicing from
the WatchCat screen.
If you do use the WatchCat plugin make sure you use the files from ver 7
as earlier ones were unstable
Dave
Mr. G
I have v5.5 here from 2008. It appears that priority has been completely
rewritten from earlier versions. My guess is that it didn't properly work,
hence the rewrite. Here's the description of priority in my version...not
quite what you were looking for.
Calculate priority levels for all windows
If this option is selected the Nice-OS/2 will calculate and change priority
levels for all visible applications. Minimized and hidden applications
gives the lowest priority level (100), visible applications gives middle
level (100+), and active application gives regular (200) priority level.
Invisible (not accessible from Window List) and detached (internal system)
applications will works with their own levels. Workplace Shell works with
its own priority level.
This option is not recommended. By default this feature is disabled.
Paul Ratcliffe
wrote:
> Recently I came across this old utility...it's purpose is to allow you to
> dynamically adjust the priority and class of any given process.
Threads not processes.
> It seems like a really nifty utility...
What are you hoping to achieve using this? Thread priority is a matter for
the application developers to set, NOT for end users to twiddle about with
without any real knowledge of the implications.
Al Savage
<ab...@orac12.clara34.co56.uk78> wrote:
> What are you hoping to achieve using this? Thread priority is a matter for
> the application developers to set, NOT for end users to twiddle about with
> without any real knowledge of the implications.
It allows an end-user to un-screw-up the thread priority that an
application developer f*cked up.
My guess is that THAT is what Dariusz is hoping to achieve.
--
Regards,
Al S.
sctvguy1
Al,
Still in to PS/2 machines? Haven't seen you in that newsgroup in quite a
long while. Same regulars there. I am down to just one PS/2, a 9556
with OS/2 and WfWg on the HDD. Sometimes it goes on the Internet for
nostalgia purposes.
Paul Ratcliffe
> On Sun, 22 Nov 2009 23:20:14 UTC, Paul Ratcliffe
><ab...@orac12.clara34.co56.uk78> wrote:
>
>> What are you hoping to achieve using this? Thread priority is a matter for
>> the application developers to set, NOT for end users to twiddle about with
>> without any real knowledge of the implications.
>
> It allows an end-user to un-screw-up the thread priority that an
> application developer f*cked up.
Really? Name me some examples.
> My guess is that THAT is what Dariusz is hoping to achieve.
My guess is that he didn't really know what he was trying to achieve, seeing
as he didn't bother to answer. This is usually a clear sign when people are
challenged to explain.
Al Savage
<ab...@orac12.clara34.co56.uk78> wrote:
> > It allows an end-user to un-screw-up the thread priority that an
> > application developer f*cked up.
>
> Really? Name me some examples.
Nah, do your own research, Paul.
--
Regards,
Al S.
Lars Erdmann
what Dariusz said might be imprecise but it's not all that wrong.
The routine that does it all (DosSetPriority) allows to change the prio
for all threads in a process and even for all threads of all child
processes that are started from a process and I'm sure you know that.
I'd say that in practice only very few developers even consider thinking
about the priority of the threads they create. Therefore it is not
guaranteed they know any better than the users.
I had written a DLL called by some WPS DLL (I wrote a PAM DLL for the
IWF that came with VAC 3.x) and deliberately lowered the thread priority
of some container view update threads that called my DLL routines
because otherwise it would have left my system completely unresponsive
while the container view update was in progress. I can definitely say
that that was a good decision (ok, in this case I AM the developer but
the original developers of the WPS DLL obviously did not care).
In short, there are good reasons to have a utility like nice.exe for
example to put a job into the background when you can afford that it is
going to take longer to complete. It also exists under Unix for the very
same reason.
Lars
Paul Ratcliffe schrieb:
Dariusz Piatkowski
wrote:
> On Tue, 01 Dec 2009 20:21:55 -0600, Al Savage <asa...@iname.com> wrote:
>
> > On Sun, 22 Nov 2009 23:20:14 UTC, Paul Ratcliffe
> ><ab...@orac12.clara34.co56.uk78> wrote:
> >
> >> What are you hoping to achieve using this? Thread priority is a matter for
> >> the application developers to set, NOT for end users to twiddle about with
> >> without any real knowledge of the implications.
> >
> > It allows an end-user to un-screw-up the thread priority that an
> > application developer f*cked up.
>
> Really? Name me some examples.
>
> > My guess is that THAT is what Dariusz is hoping to achieve.
>
> My guess is that he didn't really know what he was trying to achieve, seeing
> as he didn't bother to answer. This is usually a clear sign when people are
> challenged to explain.
Actually Mr. Ratcliffe, I chose to ignore you. This is not the first time that I
have read one of your posts which just reeks of that "damn I'm an OS2 God"
attitude.
Dariusz Piatkowski
Specifically, here is my issue: while running aMule and using a number of
streams I find that aMule will eventually start to use 100% CPU. It gets to the
point of where the remainder of the system is getting noticably impacted by
this.
Now, on my machine I have Privoxy set up as Time Critical process to make sure
that my normal web-surfing is NOT impacted by Privoxy being 'starved' for CPU
time. This seems to work very well...my thinking was that I may be able to
specifically set aMule to run at IDLE time, and if possible might be able to
dynamically adjust it's priority down if it starts consuming too much CPU time.
Ultimately I was thinking maybe I could set up a little REXX script that could
do the tweaking for me on-the-fly.
Dave Yeo
Did you try just using nice.exe or nicex.exe to change the priority?
On further thought I think the GUI part was just not finished.
Dave
Dariusz Piatkowski
So far, to run amule at 'idle' priority I am kicking it off with 'spe' using the
following command:
"g:\util\misc\spe.exe i G:\amule\amuled.exe"
The system is much more responsive now, even as aMule gets into it's 100% CPU
utilization cycle...although now it appears to happen a lot more often...I
suspect there is really something else going on internally in the program
itself.
Anyways, from my perspective this does accomplish what I was after...to make
aMule non-obtrusive to the user-interface of the OS.