* Replying to a message in : SAVEAREA

On Friday, 13 November 1998,
     JEFF DUNLOP wrote to IVAN TODOROSKI about 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.

  Nope... checked it THOROUGHLY before I sent the message. If you start
  ping with the normal (default) priority, and drag windows around, it
  virtually stops! The five lines DON'T show up immediately when you
  stop dragging the window (remember, full-window dragging must be on).
  Instead, ping just continues to run with normal speed, and the
  statistics for the period you dragged the window around are far from
  normal, infact they are HORRIBLE!

  If you run "ping localhost" you should get ZERO return times for the
  packets, but while you're dragging the window the times are EXACTLY
  1000ms, which is consistent with my MAXWAIT=1 setting in CONFIG.SYS.
  (Imagine, 1 SECOND to get a reply from the SAME MACHINE!)

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

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

  Try it out and see for yourself (you might have to drag the window
  faster if you have a fast machine and/or fast video card, or else the
  PM activity might not consume 100% of CPU time, which is required to
  observe the effect)

  You gave me another idea. I will change the MAXWAIT setting to 2, and
  see if it will change the return times to 2000ms. If it does, my
  theory is correct, and ping (or any other regular priority thread)
  DOES INDEED stop (except for the short starvation boosts) while
  intensive PM screen activity is going on. Read the next message for
  results. I'll address it to ALL, since it may prove quite interesting.

                  [Changing CONFIG.SYS; Rebooting...]

                                                            - Ivan -

.!. Winerr 01F - Error In Progress; Please Wait....
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ