Original from  IVAN TODOROSKI  to JEFF DUNLOP on 11-15-1998
Original Subject: PM drawing priorities...

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

  IT>>   If you run the ping process at any lower priority than Time Critical
  IT>>   (doesn't matter if it's Regular, Idle, or Foreground Server) you'll
  IT>>   notice it stops while you're draging the window,
 
  JD> You're misinterpreting what you see. Both ping and dir/s continue
  JD> to run, it's just the display to the screen that is suspended
  JD> while you drag the window around. For instance, even if you can't
  JD> hear dir/s chugging away in the background, you can certainly
  JD> 'freeze' ping for about five seconds, release the drag window and
  JD> observe five lines instantly appear with normal statistics.
 
IT>   Nope... checked it THOROUGHLY before I sent the message. If you start
IT>   ping with the normal (default) priority, and drag windows around, it
IT>   virtually stops! The five lines DON'T show up immediately when you
IT>   stop dragging the window (remember, full-window dragging must be on).
IT>   Instead, ping just continues to run with normal speed, and the
IT>   statistics for the period you dragged the window around are far from
IT>   normal, infact they are HORRIBLE!
IT> 
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!)

 What version of OS/2 are you using? What FP level? What video driver?
Any WPS extensions? 
 I duplicated your tests here, and consistently had 0ms response time 
while pinging localhost. The *only* way I could get it to be larger 
than 0 ms is by a dir /s against a zipstream packed drive (and then it 
went to 50-75ms for a short period until zipstream got it's cache 
filled).
 I am running Warp 4, FP 8, on this 266mz, 96MB laptop. 

IT>   Because the higher priority process (dragging the window) is eating
IT>   all the cycles, the ping process only runs in short bursts
IT>   (caused by the starvation boost) one second apart, and that's the
IT>   reason why it registers the packets as returning 1 second after
IT>   sending.

 Not that I can see here.. It looks like there is something else 
involved here than just what you surmise.. 

IT>   It sends out a packet, and starts waiting for a reply, but it will
IT>   actually be able to receive the packet on the next burst, because the
IT>   sending of the packet involves a kernel call, which causes a task
IT>   switch, so the next time the ping process will regain control is after
IT>   one second. Only then it will be able to receive the packet, and by
IT>   calculating the time difference between sending and receiving, it will
IT>   conclude that the round trip was 1 second, as was observed. Most of
IT>   the return times were EXACTLY 1000ms.
IT> 
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)

 I retried just now and I *could* get an occasional 1000ms delay if, 
and only if, I started dragging a session so fast and over so much 
screen real estate that the video driver could not keep up (and I 
could not follow anything moving so fast). 
 Keep in mind that there are repaint messages going to every app that 
you are "covering and uncovering" with the dragging window. In 
addition to the continual update of the dragged window. The video 
driver speed is a BIG factor here.. 
 Even so, the only way I could get more than 1 out of 30 or so pings 
to be larger than 0ms is to slow the cpu down to 1/4 speed (low power 
mode for this laptop) and then it was one out of every 4-5 with 
maximum screen dragging speed.. 
 Full screen dragging is highly affected by the video driver and cpu
speed, which is why IBM does not recommend it on older CPU's.. Note my
previous comments about driver operations being non-preemptive, which 
is part of what is happening here.. 


   Denis       

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

 



--- Maximus/2 3.01