* Replying to a message in : SAVEAREA

On Monday, 16 November 1998,
     DENIS TONN wrote to IVAN TODOROSKI about 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).

  That's because you have a fast machine, and your video driver can keep
  up with your draging the window.

 DT>  I am running Warp 4, FP 8, on this 266mz, 96MB laptop.

  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).

    There you have it... that "occasional" on your machine turns into
    "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..

   Yes, I am aware of that. Maybe I wasn't quite clear.
   I *know* that's its the video driver's fault, since I'm using a slow
   and unoptimized one. BUT, even if it is slow, there is no reason why
   it should run at a higher priority than the calling process.

   And it DOES, because if the process runs at any priority less or
   equal to Server, delta 31, the video update is NOT preempted, and
   if the process runs at Time Critical, delta 0, the video driver
   update IS preempted.

   This proves that the video update DOES NOT run in non-preemptable
   Kmode (since it is preempted by Time Critical threads), but simply
   runs at a higher priority than most other processes, IOW the PM
   screen update is BOOSTED.

   This boost happens even at PRIORITY=ABSOLUTE, and even when all of
   PMSHELL's threads are set to 0x200 priority.

  BUT, when I patched the kernel this boost went away, and applications
  no longer freeze when I drag various windows around.

   So, the only logical conclusion that I can draw from this is that the
   PM video update is as preemptable as any other user process, but it
   runs at a priority between 0x31f (Server, delta 31) and 0x61f
   (starvation boost).

   There was a more detailed explanation in some of my previous
   messages, sorry I repeated it here.

   I am aware that you know a *lot* more about OS/2 than I do. If you
   (or someone else) have a different theory which could fit the facts
   above, I would be very interested in hearing it... this was my best
   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..

  Yes, those comments actually inspired me to do additional experiments,
  but in this case, the video driver operations are infact preemptive,
  since by simply changing the priority table I managed to prevent them
  from freezing other applications. If they were truly non-preemptive,
  they would have stayed that way even after the kernel change.

                                                            - Ivan -

.!. Format Drive C: ?  [Y]es [O]kay [F]ine by me
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ