Conference bulova::decw_jan-89_to_nov-90

    Your not running DECW$QUOTE are you?
    
    I saw this happen when somebody ran that.
    
    

    My guess would be the following:  Writable pages use the local
    pagefile.  However, non-writable pages, e.g. the code which comes from
    you application's .exe file page from the .exe itself.  Since the .exe
    file is on the MSCP-served disk from the 750, it is paging over the
    ethernet, through the 750.  Since anything associated with DW tends to
    burn memory, DW apps, on average, are much more likely to show this
    problem than others.
    
    To confirm this, try moving the application to your paging disk and run it
    from there.  You could also use MONITOR to see who is doing what.
    MONITOR PAGE (I think) will tell a lot on the workstation.  Try MONITOR
    MODES on the 750.  A lot of time in kernel mode there might indicate
    a lot of locking going on.
    
    Having a real slow node for the boot node is a know-bad-thing to do for
    clusters in general.  DW tends to exagerate problems.
    
    To reduce the problem, I suspect you want to try to make
    sure that more of that 12 megs is being used.  Have you autogen'ed
    recently?  Is there a lot of free memory when you do SHOW MEM?
    
    Burns
    

    re .1
    
    No I'm not running DECW$QUOTE. What's that anyway?
    
    re .2
    
    I can't remember whether I have monitor the systems, but I am not
    actually running applications as yet. I merely logged-in, and try to
    *drag* a window. This would usually be the session mgr or a decterm
    window. Surely dragging a window around cannot cause that amount of
    paging. Besides, MSCP-served disk performance from the 11/750 is
    surprisingly good (hats off to my faithful old workhorse). Application
    startup time is good, even when I'm using the bookreader, with the
    books residing on the 11/750 also. Iconizing windows and other
    operations seem to be OK, only *dragging* the windows produces very
    obvious problems. Any ideas?
    
    HW

    Dragging would be an intraction between the window manager and the
    server.  Either one could be paging (probably the server), but you are
    right.  This does not really sound like it.
    
    All I can say is that you have to dig down a step deeper with monitor.
    Monitor is there by default unless you tailored it off (probably not 
    a good idea...it is sooooo usefu.
    
    Another useful thing is $SHOW PROC/CONT/ID=nnnnn on the server process
    and/or the window manager process.

    Oh, wait a minute.  I just read the base note again.  I wonder if this
    is the old "pseudo-deadlock" problem.  You know, the bit where if the
    client does not respond fast enough, the server stops and retries? 
    Usually the client ends up getting kicked off, but in this case, if it
    is genuinely slow, it will eventually catch up and make the sever happy
    again.
    
    See if the server is in HIB while things are hanging (using SHOW
    PROC/CONT.)  If so, this is probably it.  Upgrade to V5.3 to fix it.
    
    Burns

    re .5
    
    I take it that the server and clients you are talking about refers to
    the Xserver and Xclients?
    
    HW

Yes, I mean the X definitions, i.e. DISPLAY server, not COMPUTE server.  (You
can always tell the X people from everyone else in the company  by
what the mean when they say "server".

Burns

    but the 750 is only a disk-server. surely both the display-server and
    the client is in the workstation, since I logged onto the workstation,
    not the 750.
    
    HW

Right, but if there are paging problems, which involve the 750 if they are
code pages, the client may slow down sufficiently that the server thinks it
is blocked.

Burns

    OK, got it.
    
    I'll try it as soon as I get back to the office.
    
    Thanx and cheerio!