| Title: | DECWINDOWS |
| Notice: | DECwindows Motif V1.2-4 SSB kits: note 5519 |
| Moderator: | GRIM::MESSENGER |
| Created: | Wed Nov 28 1990 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5861 |
| Total number of notes: | 24081 |
Why my Dir/full command eats so much CPU time ?
First step my customer receive a Alpha server 1000A 5/300
with the built in graphic device and VRC15 as screen
Customer start his session , opens a decterm , and
runs a directory command .
------->in this state the DIR/full command eats 100% cpu time ,
all the cpu time for a single command !!!!!
We said the customer to change the card to speed up (because
the built in card is very poor .... )
Second step we installed a S3 trio 64 PCI 1Mb graphic accelerator
(PB2GA-JB) with the same performance
(card set slot #3 in the primary bus)
And third we swapped with the PCI 9FX Motion 331 (revision A01)
-------> but the same DIR/full command eats 80% CPU time (not really
satisfying !!!!!)
I don't have a such configuration.
If someone is using a such configuration , could you test this
"slow" command on your system !
Can someone explain why this command is consuming so much CPU ?
More information
OPENVMS V6.2-1H3
DECWINDOW motif 1.2.4
SYS$GQSdriver.exe (22-Feb-1996)
Alpha 1000A 5/300 srm 4.7-169
Configuration with ECU 1.9
Jumper J27 on mother board disabled
VRC15 set to 1024*768 70 hz supported
Resoltuion defines in sys$manager:decw$private_server_setup.com
$ DECW$XSIZE_IN_PIXELS ==1024
$ DECW$YSIZE_IN_PIXELS == 768
$ DEFINE/SYSTEM DECW$SERVER_REFRESH_RATE 70
W've connected a VT320 on the serial port (on the server)
and no excessive CPU time in this case
Thanks for your help
- Michel -
Cross posted Mikasa and Decwindow conference.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5838.1 | GRIM::MESSENGER | Bob Messenger | Mon May 05 1997 18:01 | 10 | |
Could you post the enitre contents of the customer's decw$server_0_error.log file? There is/was an IPMT case where the server eats up a large amount of CPU time because it's hung in GlobalWait state (i.e. it's polling the graphics card waiting for the CPU Busy flag to be cleared). Try using the latest DDX image in BULOVA::DECW$PUBLIC:[SERVER], i.e. DECW$SERVER_DDX_S3.EXE for the S3 Trio. Copy this image to SYS$LIBRARY on the customer's system and restart DECwindows. -- Bob | |||||
| 5838.2 | PRSSOS::AMAURY | Karl policy et lise plan | Tue May 06 1997 11:34 | 3 | |
Thanks bob , I 'll contact the customer
Michel
| |||||
| 5838.3 | STAR::KLEINSORGE | Fred Kleinsorge, OpenVMS Engineering | Tue May 06 1997 12:38 | 45 | |
It should be expected. The actual disk work needed to get the
information to display is trivial. So the system is spending it's time
drawing the text and scrolling it.
The "built in" which I will assume is the Cirrus on a AS1000 is a
totally dumb device, and drawing takes place by direct access to the
frame buffer for most operations. Text and scrolling in particular.
And because it's on a slow bus, it is *very* slow.
The other low-end cards are in the same basic boat to some degree.
They have better acelleration, but are still PIO devices that work by
writing some registers (or the frame buffer), and when the next thing
must be done, they spin on the fifo waiting for the device to be ready
to accept another command. If there is enough drawing commands comming
down the pipe, the XServer will go compute bound.
The low-end, and even to a great degree the high-performance 2D engines
are designed for raw graphics speed by using the CPU to keep them fed.
This is unlike, for instance the VAX VS4000 LCG or SPX engines which
were classic co-processors designed to offload the slow CPU and to
place the work in the graphics engine.
Only with the higher-end 3D devices will you see a DMA packet engine
approach which has a side effect of offloading the CPU for graphics.
Remember, the graphics were designed for systems with a single user -
either a PC user or a workstation user - but in any case, a single
user. So the belief was that the CPU could be used to drive the
graphics (which actually is nice because graphics performance then also
scales with the CPU speed). The fact that it might eat all the CPU
bandwidth if the user ran something with a high enough graphics content
was not considered a problem.
If you want to use the AS1000 as a "classic" server, connect a VT500 to
the serial port and set the console to serial. The server graphics
were provided for operator use, not as a workstation user on a
multi-user server. It just happens that a directory command keeps the
xserver busy.
If the CPU utilization is interfering with other users on the system,
then you can try lowering the DECW$SERVER0 process priority to
something under 5 (but note, then performance on the graphics may be
choppy).
| |||||