Conference bulova::decw_jan-89_to_nov-90

Darned if I know - on my workstation, the various DECwindows activities
take only a few percent of the CPU, and that's only when something is
happening on the display.  I would imagine that the culprit was memory.
However, I'm running VMS and not a DS3100 with Ultrix, so "your mileage
may vary".

					Steve

Possibilities:

- blinking cursors in lots of windows

- user is running fish, rotating cube, spinning globe, kaleidoscope, clock with
  sweep second hand, or some other such thing that eats CPU time

--PSW

If I had to bet, I'd bet that it's merely C.Matco ignorance.

	paul

    .2 may be correct.  If the user was running some monitoring software
    while the benchmark was running it would eat of a lot of risc cycles
    keeping the screen updated.  It is my understanding that the DS3100
    uses the CPU as the graphics engine instead of dedicated graphics
    chips.
    
    I also have a 2nd hand story from a friend that their DS3100 screams as
    long as they don't do anything that causes something to display on the
    screen.  Once something happens on the screen, they loose a significent
    percent of the CPU while that is happening.

RE: .4
    
If you  want  to  listen closely to the people from the left cost who think
that  the DS3100's dumb frame buffer is the way  to  go,  check  out  their
presentation  tomorrow  in  ZK.    Personally,  I don't buy it,  given  the
experience of a VS-II compared to a VS-II/GPX (which factors difference  in
CPU  speeds out of the equations).  If they are correct, I'll  gladly  step
aside, but  it  makes  me  wonder why Silicon Graphics, SpectraGraphics and
people like E&S  are  wasting  so  much  time  building customized graphics
pipelines outboard of the CPU.
    

The following abstract taken from the presentation mailings:
    

                          SMART CODE, STUPID MEMORY:
                 A FAST COLOR X SERVER FOR THE DECSTATION 3100
                                JOEL MCCORMACK

Processor  speeds are improving faster than memory access speeds.  A DECStation
3100 (pmax) has ten times the compute power of a MicroVAX  II,  but  a  roughly
equivalent  memory-cycle time.  Color graphics on the MicroVAX requires special
chips with exotic reptile names; the pmax uses its "excess" processing power to
achieve superior graphics performance with a cheap dumb frame buffer.

This talk discusses the memory system of the pmax, some nice MIPS instructions,
algorithms used  to  implement  various  graphics  operations,  the  unexpected
problems that arose, and possible frame buffer improvements.

    Re .5:

>                                     If they are correct, I'll  gladly  step
> aside, but  it  makes  me  wonder why Silicon Graphics, SpectraGraphics and
> people like E&S  are  wasting  so  much  time  building customized graphics
> pipelines outboard of the CPU.

    One thing to keep in mind is that Silicon Graphics, SpectraGraphics or
    E&S offer graphic performance at least an oder of magnitude, sometimes
    two or three orders of magnitude (x1000 and more) better than what a
    PMAX can deliver today. They are playing a real game, err, sorry, they
    are 'niche market players'. It's my understanding that what Joel has
    proved with the PMAX Color X server is that what they have done
    couldn't have been done with the Dragon chip set, and that they did it
    for cheap; I don't think that Joel will attempt to show that you can do
    solid modelling in a way that's competitive with what the competition
    offers using only software and a frame buffer! It's like with PCs: VGA
    is ok, but the 8514 special hardware will blow your socks off, for a
    price.

    Denis.    

RE: .5

James


I think the decision on pmax revolved around the current graphics 
capability in Digital at the time, and time-to-market for the base
platform.  At the time, an analysis was done on including something 
like Dragon into pmax, but it turned out that the system would have been
slower than the dumb frame buffer that they chose, based on 
memory contention, and just the overhead necessary to fillthe dragon
pipelines.

It would have also made the design more complex, and slipped the product
out further.  There's no doubt that something like GX (Sun) option 
or SiliGraph stuff is desireable on pmax.  That's what the next
generation stuff is all about.


-bill

    Hi folks!
    
    	I think the argument for software vs. hardware goes
    	something like this:
    
    	At a given moment in time custom silicon will be faster than
    	software on a fast CPU.
    
    	However, if you can come up with a fairly portable software
    	architecture, then you can use the NEXT (not NeXT) generation
    	CPU to run your software because you will be up and running before
    	the hardware guys can wire it all up.
    
    	Also as complexity increases, the software solution looks
    	more attractive because you can port your tower of layered
    	functionality easier than you can write the driver for this
    	exotic hardware. (Case in point is Firefox, whose hardware has
    	functionality which is not accessible through the driver).
    	The trouble with software is where, in a particular application,
    	the difference between silicon and software is huge (3D shading
    	etc) then you are forced down the silicon route. (Joel says
    	something like this in his report, he argues for 2D go software
    	but for 3D you can't beat silicon, least I think that's what he
    	says).
    	
    	To get the best of both worlds you need to come up with a
    	long range hardware architecture which will be backwards
    	compatible with older (slower) versions, so you can port
    	your software over and get it running, then tune it to use
    	all the new gizmos whilst the field starts taking orders.
    	Trouble is you get locked into your architecture and can't
    	take advantage of newer (unforseen) hardware developments
    	(do you remember VAX?).
    	
    	I worry nights that the "do it in software" thinking may just be an
    	excuse not to tackle the (much harder) problem of getting a
    	long range hardware architecture figured out, and that the Pixar's
    	and Silicon Graphics of this world may be doing just that. On
    	the other hand, we are definitely NOT competing with Silicon
    	Graphics/Pixar, whether that is intentional or wise is another
    	story.....
    
    Regards,
    Paul Tallett,
    CEC Karlsruhe,
    West Germany

I have the slower (slowest) MVII-GPX configuration and I understand I/O and
Terminal Emulators, and some Dragon stragies but I have still come to a 
stalemate for the following situation.

16 terminal lines were on the system when I inherited it. I have a LN03R,
LJ250, a VT340-AIV (IVIS), both VT330 lines , a DECserver LAT line, 
Scholar Modem, and now two serial lines. Reasons vary as to why
things are connected but the system was going good until V5.3/V2. Now
if I use the MODEM at 2400 baud to a public bulliten board 
  and SET HOST/DTE TXxx/LOG=yy
I get DATA OVERUNS trying to display in a DECTerm.
 I remembered the PRO-350 had similar problems related to Video writes 
and RS232 I/O so I figured use the smaller font.
 Still got over runs. 
I tried shrinking the DECTerm to an ICON
and still had problems because when it OVER RAN I didn't see it. 
I tried using the VT330 at 9600 and this worked fine until 
I went to move the mouse or any DECwindows related activity.

 Therefore my question is 
"HOW FAST A PROCESSOR IS NEEDED TO SUPPORT DECWINDOWS WITH RS232 
DEVICES ALSO CONNECTED ?" 
Is the GPX no-longer usable for this type stuff? 
Are serial devices such as modems and printers not recommended to be connected? 

P.S.
 I now set host and run a detached process on another node to use the
GPX as just a super TERMINAL and not with CPU/BATCH/FILEVIEW/DECTerm/ETC... 
manager. 
All that runnning is Session MANAGER, EVE, and the remote FILEVIEW and MAIL 
in user space and LPS40/LN03R client, SECURE_PACK. 

See following SHOW SYSTEM

$ sho sys
VAX/VMS V5.3  on node XXXXXX   1-DEC-1989 14:31:59.91   Uptime  2 21:49:12
  Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
20200041 SWAPPER         HIB     16        0   0 00:00:11.15         0      0
20200047 ERRFMT          HIB      8     2160   0 00:00:29.52        93    131
20200048 CACHE_SERVER    HIB     16        6   0 00:00:00.14        75    100
20200049 CLUSTER_SERVER  HIB      8       10   0 00:00:00.45       163    199
2020004A OPCOM           HIB      8      112   0 00:00:09.39       234    124
2020004B AUDIT_SERVER    HIB     10      126   0 00:00:03.14      1376    340
2020004C JOB_CONTROL     HIB     10     1887   0 00:00:15.59       175    338
2020004D CONFIGURE       HIB     10        7   0 00:00:00.42       122    145
2020004E SMISERVER       HIB      9       82   0 00:00:02.08       350    435
2020004F NETACP          HIB     10      378   0 00:00:45.51       292    461
20200050 EVL             HIB      6       71   0 00:00:23.31     63348     50  N
20200051 REMACP          HIB      8       13   0 00:00:00.20        85     51
20200053 DECW$SERVER_0   COM      6   289515   0 01:09:53.30     12052   3908
20200054 DAVY            LEF      4      909   0 01:07:16.14     12642   4096
20200059 VPA_DC          HIB     15     7261   0 00:13:21.46       922    717
2020005B SYMBIONT_0001   HIB      5      736   0 00:01:14.30      2332     51
2020005C SYMBIONT_0002   HIB      4       22   0 00:00:00.68       179    125
2020005D SYMBIONT_0003   HIB      7     1802   0 00:01:07.65      1459    600
20200060 DECW$WM_1       LEF      7       43   0 00:04:01.26      1512   1898
202000A1 DAVY_SM1        LEF      6      602   0 00:00:55.75      7046   3166
20200062 DAVY_SM2        LEF      4     1321   0 00:08:12.90     14566   4096
20200063 DECW$TE_1       COM      4    21414   0 00:08:15.77      2882   3036
202000A4 VUE$DAVY_1      LEF      4     1561   0 00:03:07.89     12115    410  S
202000A6 VUE$DAVY_2      LEF      4      949   0 00:01:49.77      6744    461  S
202000AC DMCLURE         HIB      5      441   0 00:00:04.08       914    297
20200073 _TWA4:          CUR      7     9627   0 00:02:43.62     13887    350

DMCLURE is another VT340-AIV used to set host else where sometimes.

Did you forget to set the lines with bigger type-ahead buffers? Or did
an autogen affect some TTY_xxx params in SYSGEN that were set in by hand,
and not put in MODPARAMS.DAT so they could be picked up by AUTOGEN?

    
    Try a different serial line interface like MODEM or Kermit.  If you
    are using SET HOST/DTE you can need all the horses you can get, it
    wasn't really designed for heavy-duty dumb-terminal links.
    
    Also make sure that you have hostsynch and ttsynch set on the entire
    path so that you get a shot at having flow control.
    
    _Fred