Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!servalan!rmtodd From: rmtodd@servalan.uucp (Richard Todd) Newsgroups: comp.unix.aux Subject: Re: A/UX 2.0 and X11R4 Message-ID: <1990Sep7.012835.1821@servalan.uucp> Date: 7 Sep 90 01:28:35 GMT References: Organization: Ministry of Silly Walks Lines: 49 MATLEVAN@EKU.BITNET (Jerry LeVan) writes: >Hello Netters, >Examining the kconfig parameters I noticed that the SLICE parameter was >changed from a "60" to a "5". This will force a lot more context switches. >(?So Multifinder can get some time for mac stuff?) So anything else on the system can get time. My experience has been that the default setting of 60 for SLICE that A/UX 1.1 had makes the system virtually unusable when background compiles, etc. were running. If I'd wanted a system that takes well over a second to give me response when under any sort of load, I'd still be running MacOS :-). With SLICE=5 the whole system is more responsive, and I'm glad Apple finally noticed this and made it the default in A/UX 2.0. >As I recall in version 1.1 I could load up many X demos and still >get some action. However with A/UX 2.0 running "plaid" the whole >shebang grinds (try starting "plaid" and then "puzzle" it takes puzzle >a looong time to draw its window) to a snails pace. >Do you suppose the "main" problem here is the small value of SLICE? That and the behavior of the program "plaid". As near as I can tell, what "plaid" does is, once it gets started, spew draw requests as fast as it can at the server, at a rate faster than the server can process them. (I gather this from the fact that when I killed plaid, the server still drew in that window for a couple of seconds, doing the draw requests that plaid had already had queued up.) Here's what I guess is happening: With SLICE=60, the X server is getting a 60-tick (1 second) time slice and that's enough for it to clear out the queue of requests before "plaid" gets the CPU. With SLICE=5, the X server can only run for 5 ticks before some other ready to run process (i.e. plaid) gets the CPU and gets a chance to queue up even more X requests, with the result that the X server always has a backlog of requests in the queue and thus things are difficult for anything else that's trying to make X requests. >Is it possible to change SLICE on the fly or does one have to kconfig >for new values? (That would take the fun out of X) You gotta kconfig. This only takes the fun out of X if you think the only way to have fun with X is to run "plaid". Believe it or not, but this behavior doesn't really seem to affect performance in "real world" situations. My experience is that the real slowdown only occurs when the paging rate gets heavy (which, even with 8M of RAM, still happens to me occasionally, with emacs and maybe a gcc compile running in the background. The extra memory taken up when running a virtual desktop with tvtwm doesn't help either...) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp