Original from  IVAN TODOROSKI  to DENIS TONN on 11-24-1998
Original Subject: PM drawing priorities...

                         ---------------------------------------

 IT>>   If you run "ping localhost" you should get ZERO
return times for the
 IT>>   packets, but while you're dragging the window the times are EXACTLY
 IT>>   1000ms, which is consistent with my MAXWAIT=1 setting in CONFIG.SYS.
 IT>>   (Imagine, 1 SECOND to get a reply from the SAME MACHINE!)
 
  DT>  What version of OS/2 are you using? What FP level? What video driver?
  DT> Any WPS extensions?
  DT>  I duplicated your tests here, and consistently had 0ms response time
  DT> while pinging localhost. The *only* way I could get it to be larger
  DT> than 0 ms is by a dir /s against a zipstream packed drive (and then it
  DT> went to 50-75ms for a short period until zipstream got it's cache
  DT> filled).
 
IT>   That's because you have a fast machine, and your video driver can keep
IT>   up with your draging the window.
 
  DT>  I am running Warp 4, FP 8, on this 266mz, 96MB laptop.
 
IT>   I have Warp 4 GA, on a 486/100, 16 megs of RAM.
 
 IT>>   Try it out and see for yourself (you might have to drag the window
 IT>>   faster if you have a fast machine and/or fast video card, or else the
 IT>>   PM activity might not consume 100% of CPU time, which is required to
 IT>>   observe the effect)
 
  DT>  I retried just now and I *could* get an occasional 1000ms delay if,
  DT> and only if, I started dragging a session so fast and over so much
  DT> screen real estate that the video driver could not keep up (and I
  DT> could not follow anything moving so fast).
 
IT>     There you have it... that "occasional" on your machine
turns into
IT>     "almost every" on mine ;)
 
  DT>  Keep in mind that there are repaint messages going to every app that
  DT> you are "covering and uncovering" with the dragging window. In
  DT> addition to the continual update of the dragged window. The video
  DT> driver speed is a BIG factor here..
 
IT>    Yes, I am aware of that. Maybe I wasn't quite clear.
IT>    I *know* that's its the video driver's fault, since I'm using a slow
IT>    and unoptimized one. BUT, even if it is slow, there is no reason why
IT>    it should run at a higher priority than the calling process.
IT> 
IT>    And it DOES, because if the process runs at any priority less or
IT>    equal to Server, delta 31, the video update is NOT preempted, and
IT>    if the process runs at Time Critical, delta 0, the video driver
IT>    update IS preempted.
IT> 
IT>    This proves that the video update DOES NOT run in non-preemptable
IT>    Kmode (since it is preempted by Time Critical threads), but simply
IT>    runs at a higher priority than most other processes, IOW the PM
IT>    screen update is BOOSTED.
IT> 
IT>    This boost happens even at PRIORITY=ABSOLUTE, and even when all of
IT>    PMSHELL's threads are set to 0x200 priority.
IT> 
IT>   BUT, when I patched the kernel this boost went away, and applications
IT>   no longer freeze when I drag various windows around.
IT> 
IT>    So, the only logical conclusion that I can draw from this is that the
IT>    PM video update is as preemptable as any other user process, but it
IT>    runs at a priority between 0x31f (Server, delta 31) and 0x61f
IT>    (starvation boost).
IT> 
IT>    There was a more detailed explanation in some of my previous
IT>    messages, sorry I repeated it here.
IT> 
IT>    I am aware that you know a *lot* more about OS/2 than I do. If you
IT>    (or someone else) have a different theory which could fit the facts
IT>    above, I would be very interested in hearing it... this was my best
IT>    shot at explaining the results of the experiments.
 
  DT>  Full screen dragging is highly affected by the video driver and cpu
  DT> speed, which is why IBM does not recommend it on older CPU's.. Note my
  DT> previous comments about driver operations being non-preemptive, which
  DT> is part of what is happening here..
 
IT>   Yes, those comments actually inspired me to do additional experiments,
IT>   but in this case, the video driver operations are infact preemptive,
IT>   since by simply changing the priority table I managed to prevent them
IT>   from freezing other applications. If they were truly non-preemptive,
IT>   they would have stayed that way even after the kernel change.

 The biggest incorrect assumption in the above is that each call into 
the video driver is an "atomic" operation. In fact, there are many 
sequential calls into the driver for a particular "video update". A 
thread could be preempted between these calls (and very probably is). 
What you have uncovered is the basic priority of the PM drawing 
thread, not any form of priority adjustment done to the threads. 

 As I stated in another message, most of your experiments are related 
to PM and video driver behaviour. They have no direct relationship
to priority adjustment, even if does affect the results indirectly.
You are trying to extrapolate priority behaviour from it's "indirect"
effects. A tough thing to do even if you (or I) totally understood the
behaviour of PM and the video drivers involved. 

 Let me suggest a better "test". Write an app that sets itself to Time
Critical and then goes into a tight loop. At that time you will have
absolutely no video updates (except from this app), PM or otherwise.
If the app does not do any video updates, the system will appear
"dead". The mouse will move, you can click on other things, but no
other app will be dispatched (except other TC threads). If the app
then "finishes" (it's loop ends), all the "stacked"
mouse presses will
then happen along with the video updates they trigger. This shows that
the PM DD has queued the events, but that none of them have been 
delivered by PM yet. The detection of the events is done by the DD 
based on interrupts, but the delivery of the events is done via 
threads in PM. 
 For a little more sophisticated test, build a looping (and counting)
app that slowly raises it's delta (and priority class) from idle 00 to
TC 31 and then back down. Keep track of how many counts you can do 
in x time (or how long to do x counts). Run 2-3 copies of the app 
(staggered time frame). Watch the results. Run them full screen,
foreground, background, etc at different points in time. Then
build a PM version of the app and observe the results.
 I suspect the above will give you a little better look into what the 
priority and priority adjustment are actually doing. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 






--- Maximus/2 3.01