Conference bulova::decw_jan-89_to_nov-90

    Uh, what's a "DECwindows Terminal"?

Pat,

DECwindows Terminal has been program announced.  We are allowed to talk about it.

John,

You should probably take this up with the DECwindows Terminal product management.
Since this is only program announced, you are not likely to get any performance
details in here.  Unfortunately, I don't know who the product manager is.  Sorry.

Dick

    The article with the details of "Digital's Windowing Display" which we
    have been calling the DECwindows Terminal appeared in the July 10 SALES
    UPDATE special issue, I just read the article again on VTX.
    
    The external program announcement I shall assume took place on July 10
    as well.

>    The external program announcement I shall assume took place on July 10
>    as well.

	There was also a full color picture of the DWT on the cover of Digital
	News last week with two DEC managers  {Abbot Gilman and Larry
	Cabrinety of Desktop System Group} showing it off.

	The article does say that Gilman would not discuss when it would be
	officially announced.

	I believe the product manager is Vic Bellemare and he
is on VIDEO::BELLEMARE. 

    In any case, the important configuration question is not "how many Dwts
    should I put on one segment" but instead "how many Dwts should I
    connect to the same client node of model xxx".  Processing cycles on the
    clients will run out before bandwidth on an Ethernet does.

    .6 has it right: worry about the node(s) running the clients before
    worrying about the ethernet.
    
    > 		b)	What determines the performance of accessing DECwindows
    >			applications remotely. 
    
    CPU, memory, and I/Os
    
    DECwindows applications use a fair amount of CPU in a very time-critical 
    fashion.  The user wants his window now, not in a second or two. 
    Bursty performance can be very frustrating, so you want to run your
    clients on a relatively fast CPU that has a fair amount of reserve
    capacity.
     
    DECWindows apps use a fair amount of memory, too.  But if you can save
    some memory through sharing if several users are running the same
    images on the same node and you install those images
    /OPEN/HEADER/SHARED.  $ SHOW DEV/FILES/NOSYS SYS$SYSDEVICE: will show
    you who is accessing which files on your system disk.  Install the
    files that appear several times.  You may have to up your global
    section and page counts. 
    
    DECwindows apps running on a node which is different from the server 
    uses the network transport which is bit slower than shared memory
    transport that a local application can use.  No surprise.  But consider
    how much time is spent using the transport in relation to the rest of
    the time doing computes, page faults, disk I/Os, etc. etc. etc.  You'll
    find that the time-in-transport is relatively low and that the
    difference in performance due to the different transport to be
    negligable.  (In fact, you may see a performance improvement if you
    have more CPU and memory available for the clients to use...)
    
    In terms of the bits and bytes that go out on the ethernet, packet size
    and interarrival time analysis indicates that the traffic is bursty,
    but overall it is relatively light considering the capacity of the
    wire.  
    
    BTW, there is a nasty rumor going around that says DECWindows is a
    network hog.  But if you read the fine print, it says that DECWindows
    apps running on a memory poor system causes a lot of page faults and
    that when the memory poor system is also a diskless LAVc member, it has
    to page across the net to a LAVc disk server, thus generating a lot of
    network traffic.  Giving the system more memory or a local paging disk
    "fixes" the "DECwindows network problem".  
    
    Bottom line: worry about finding a zippy CPU with spare capacity and 
    enough memory to host your clients, and don't worry much about the
    ethernet.
    
    
    John B.

    Also see note 1176.9