nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (02/10/88)
>Ivan Tadayoff <tada@athena.mit.edu> replies to... >>In article <598@nitrex.UUCP> rbl@nitrex.UUCP ( Dr. Robin Lake ) writes... >>>In article <635@ndmath.UUCP> milo@ndmath.UUCP (Greg Corson) writes... > The CPU can handle the windowing, etc, but you probably don't have > enough memory. DEC only sells 2000's with up to 6M of memory, ... We have color diskless VAXstation-2000s attached to an LAVC. The VS-2000s have only 4 MB of memory - its not enough. We recently attached a small disk (Seagate ST251 - RD32 lookalike) to the node getting the heaviest usage and saw profound improvement in performance just getting the paging and swapping onto a local disk and off the Ethernet and boot node (boot node is probably the bottleneck). We are awaiting delivery of an 8 MB memory board to upgrade the VS-2000 from 4 MB to 10 MB which should be about the right size in our application and should really improve the performance. The user's already comment that addition of the disk has improved performance to match that seen on our monochrome VAXStation-IIs (which all have local disks). As for the graphics, the color and grey-level VAXStations all use the Dragon chipset graphics coprocessor (introduced in the VAXStation-II/GPX and also used in the VT330 and VT340 terminals). The graphics coprocess signficantly improves graphics performance (or offloads the CPU0 provided your system has enought resources (memory) to drive it faster. > (long paragraph on X event queues and UIS ASTs) Based on our experience with SMG and ASTs, we plan to write our applications to use event queues even under UIS and GKS (yes, GKS V3.0 does do asynchronous input, badly). Basically this works like (in crude, C-like pseudocode): void EventTypeX_ASTRoutine() { Add notification message of event type X to event queue; if (queue-was-empty) sys$wake(); } main() { ... for(;;) /* ForEver */ { sys$hiber(); /* Wait for something on queue */ while (queue-is-not-empty) { remove item from head of queue; switch (event-type) { case X: handle event type X; break; } } } ... } Thus our applications for SMG, UIS or GKS will look much like X applications. This seems to be the only way to get things to function properly. The SMG code is explicitly stated to be non-AST reentrant. We have run into problems with the UIS code called from ASTs; and GKS doesn't state it in the manual (like SMG does), but we've been told to not call GKS routines from inside ASTs. > One final comparison -- X11 treats everything as one byte/pixel > whether you're on a monochrome or color system, so it is considerably > slower than UIS which is specific for monochrome or color. (The code > is the same, but the hardware knows what size to make things.) I understand that this problem in X is due to the X-Server (which is the part which handles the display) not being "tuned" properly for the hardware and is *NOT* an inherent limitation in the X protocol or X libraries. = Frank J. Nagy "VAX Guru & Wizard" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510