Re: Thread Priority in OS/2 client

Roman Trunov wrote:
> Christer Jacobsson wrote:
> 

As Salaam Aleikum!

>> In the Config->Performance related options->3 Priority level one can 
>> select the priority level dnetc should run with. If priority 0 is 
>> selected, dnetc will run at Class=idle, delta=0 but if priority 1 is 
>> chosen it will run at Class=Idle, delta=9. 
> 
> Delta=9 look strange, because code for setting the priority is:
> 
> DosSetPriority( PRTYS_THREAD, PRTYC_IDLETIME, ((32 * prio)/10), 0);
> 
> This it not exactly correct mapping (it maps to 0..28 range instead of 
> 0..31 supported in OS/2), but priority 1 should give Delta=3, priority 2 
> - Delta=6, and so on. This is confirmed on my old Warp 3 test box:
> 
> Client Priority=1:
> 
>     Owner      T-ID  TSID  Prio   State
>  ------------  ----  ----  ----  -------
>  DNETC.EXE        1   199  0200  Blocked
>                   2   183  0103  Ready
> 
> Client Priority=2:
> 
>     Owner      T-ID  TSID  Prio   State
>  ------------  ----  ----  ----  -------
>  DNETC.EXE        1   183  0200  Blocked
>                   2   199  0106  Ready
> 
> 
> Regarding more accurate priority tweaking, there are some compatibility 
> issues. Client supports only 10 priority levels (0..9), this range is 
> hard-coded in many places of client code. OS/2 have 4 priority classes 
> (we could skip this part because only Idle class is used) with 32 
> priority deltas (0..31) so we have to do rough mapping of client level 
> to OS/2 delta with step of 3. Simply allowing to enter range of 0..31 
> could break a lot, including existing setup.
> 
> I think a command-line option "-sysprio N" could be implemented. It will 
> allow to set cruncher priority in some OS-specific way (for OS/2, "N" 
> could be at least in 0..31 range). It will NOT be saved to .ini file or 
> configured via menus to avoid problems if .ini file is shared by 
> different clients. If you want to use such fine tweaking, you should be 
> fine with command line.
> 

That would be fine with me: I kick off dnetc from the startup.cmd file 
with the following 4os2 command lines:

cdd g:\os2ut\bovine
start "RC5-72 Cracker" /FS /BG /C dnetc.exe

So inserting a future "-sysprio 1" (in my case as I also runs Seti@home 
here, the OS/2 flavour and the cruncher itself is started by the BOINC 
program, so changing the cruncher's priority from it's default value of 
Idle, Delta=1 is not an option here as the cruncher exits when it has 
completed processing a workunit, reports the result to BOINC which if 
there are more WUs queued would relaunch the cruncher again). Heretofore 
I have used a small program from hobbes called nice.exe to set dnetc to 
Idle, Delta=1 literally by hand from a cmdline, so it will share the 
idle CPU cycles with Seti@home. Running dnetc at Idle, delta=0 would 
mean that it won't crunch: it had to live at the mercy of the seti@home 
cruncher.

> But don't expect that it'll happens very fast :) OS/2 client had no 
> major changes since last released version, so expect an update only when 
> something really important happens, like new core added.
> 

Will there be a new release when the next phase of the OGR project 
(OGR=29?) begins to run or will the current os/2 version of dnetc work 
with the future OGR=29 as well?

As I understands it, OGR=28 is now completed and the stubs that we get 
is some sort of "leftover" work that should be processed as well. RC5-72 
is still forging ahead strongly :-)


Cul8er alligator!
gaea - feminist & chunkawakan
-- 
     *****
    *     *
    *     *
     *****
       *
     *****
       *


/GAIA (Insulin User - 18th Anniversary :-) Ex-wife deceased :-(
        Team OS/2      e-mail:  cribo.jacobsson-PTt/[email protected] (Primary)
        Team eCs       e-mail:  gaianerthus-/[email protected]   (Alternate)
        Team DRW       Dare Refuse Windows
        Chunkawakan    Lakota/Sioux: Horse
_______________________________________________
rc5 mailing list
rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/rc5