MATLEVAN@EKU.BITNET (Jerry LeVan) (09/03/90)
Hello netters,
I have VERY recently installed A/UX 2.0. Today I felt brave and
decided to install X11R4 ( I had been running X with A/UX 1.1).
I reinstalled gcc 1-37 that I picked up from apple.com last
febuary.(Unfortunately this later lead to problems.) I tryed the
compiler on several small programs and it seemed to work ok.
I then mounted the disk containing the X source tree, I had just
applied some patches a couple of weeks ago and thought that everything
should just copy over to the target disk! When I pulled the trigger
"make install"
much to my chagrin, the compiler kicked in and a large part of X got
recompiled.Xlib,the clients and demos where recompiled but Xt and Xaw
where not! After several hours the installation completed. It seems to
be working OK.
The only problem I have encountered so far is that vi seems to have
changed. vi no longer "understands" xterm. Even though TERM=xterm
and TERMCAP contains the termcap info vi says it does not understand
"xterm" and falls into "open" mode. Does vi only examine the terminfo
file in this version of A/UX? (there is no xterm entry in terminfo.)
Has anyone built a xterm terminfo source description? (I am using
TERM=vt100 as a workaround but I don't know yet if there are going
to be editing problems.)
Another problem I have inflicted upon myself is that one must be
root in order to do the "make install" command consequently all of the
compiled files are now owned by root. I also neglected to give myself
the same uid as I had in v1.1, this means that all files in the
X system now belong to someone else sigh...
I have discovered how to launch X from the login window,
In the folder /mac/lib/sessiontypes there are 3 files (this
if from an man with an obviously defective memory so be careful).
These are the startup documents (disquised as applications). One
starts the old A/UX console mode, the other two start the 24 and
32 bit mac enviroments.I duped the mac32 file and peeked inside
with resedit. Turns out that there are 4 (as I recall) strings in
the file. One is the comment which appears in the session selection
dialog, one is the path to a startup file and another appears to be
the name of the startup file with a dot in front of the name. I replaced
the path string with /usr/bin/X11/X ( I have X linked to the actual
startup script for X) and replaced the .mac32 string with a .X
I named the resulting file X11R4. It appeared as a session choice.
I also modified the X startup script (aka X11R4) by pitching the
"screenrestore" line. The screenrestore command evidently just draws the
old A/UX console screen.
Well it worked! If I want I can now boot X cleanly from the login
screen.
******************* End of X Discussion ****************************
I have an eight meg mac, NBUF turns out to have a value of 337, buffer
size appears to have doubled since the last release, I was running with
NBUF=1000 in release 1.1, should NBUF be increased? Anyone out there
have any tuning suggestions?
I am a little irritated that CommandShell windows doesn't transmit vt100
escape sequences for the keypad. I have to spend a lot of time editing
on a VAX/VMS system.
TextEditor takes over 30 seconds to start! What's going on?
It would be nice if I could save/modify TextEditor defaults
I can't RTFM cuz I don't have the money to get the M.
Jerry
-----------------------------------------------------------------------------
| Jerry LeVan | Phone:(606)-622-1931 |
| Department of Computer Science | |
| Eastern Kentucky University | Email:matlevan@eku.bitnet |
| Richmond Ky 40475 | |
|---------------------------------------------------------------------------|
| "The series converges so slowly that it actually diverges." |
-----------------------------------------------------------------------------rmtodd@servalan.uucp (Richard Todd) (09/03/90)
MATLEVAN@EKU.BITNET (Jerry LeVan) writes: >The only problem I have encountered so far is that vi seems to have >changed. vi no longer "understands" xterm. Even though TERM=xterm >and TERMCAP contains the termcap info vi says it does not understand >"xterm" and falls into "open" mode. Does vi only examine the terminfo >file in this version of A/UX? (there is no xterm entry in terminfo.) Not only does vi only understand terminfo under A/UX 2.0, it did under 1.1 as well. Evidently you must have lost the xterm terminfo file somewhere in the shuffle. >Has anyone built a xterm terminfo source description? (I am using >TERM=vt100 as a workaround but I don't know yet if there are going >to be editing problems.) Compiled terminfo files for the Mac are supplied with the R4 distribution. Go to mit/server/ddx/macII and look at the xterm.tic and xterms.tic files. They should have been copied into the /usr/lib/terminfo directories automatically, but if not, copy them by hand to /usr/lib/terminfo/x/{xterm, xterms}. >TextEditor takes over 30 seconds to start! What's going on? Hmm... I wouldn't say it's that slow, but it definitely is not speedy. Me, I avoid TextEditor and use either GNU Emacs or vi, so....
MATLEVAN@EKU.BITNET (Jerry LeVan) (09/05/90)
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?) 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? 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) Or do you suppose there could be some other problem? ******************************************************************************** I still can't generate a multitape tar archive for my X system, directing the output through "tcb" causes an I/O error when the second tape is inserted. Not using "tcb" is slooow and and a get a memory fault deep into the second tape. (I have an 8 meg macII with the "outstanding" apple tc drive.) Jerry ----------------------------------------------------------------------------- | Jerry LeVan | Phone:(606)-622-1931 | | Department of Computer Science | | | Eastern Kentucky University | Email:matlevan@eku.bitnet | | Richmond Ky 40475 | | |---------------------------------------------------------------------------| | "The series converges so slowly that it actually diverges." | -----------------------------------------------------------------------------
rmtodd@servalan.uucp (Richard Todd) (09/07/90)
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
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (09/07/90)
In article <1990Sep7.012835.1821@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >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?) > >>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. >-- >Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us > rmtodd@servalan.uucp For some reason (maybe a very good one), you CAN'T change the value of SLICE. Even if you kconfig with SLICE equal to something else, it gets bumped back to 5. Well, let me be a bit more exact. I haven't been able to increase it (to 60). I don't know if it will allow changes to something close to 5, but I doubt it. Seems that something is keeping it to a 5. Good luck! -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."
urlichs@smurf.sub.org (Matthias Urlichs) (09/11/90)
In comp.unix.aux, article <3361@dftsrv.gsfc.nasa.gov>,
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes:
<
< For some reason (maybe a very good one), you CAN'T change the value of
< SLICE. Even if you kconfig with SLICE equal to something else, it gets
< bumped back to 5.
<
That's courtesy of one of the install scripts and/or of copying newunix to
unix when generating a new kernel.
You'll either have to patch newunix or to re-patch the kernel afterwards.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)liam@cs.qmw.ac.uk (William Roberts) (09/12/90)
In <7l+df2.pq4@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <3361@dftsrv.gsfc.nasa.gov>, > jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >< >< For some reason (maybe a very good one), you CAN'T change the value of >< SLICE. Even if you kconfig with SLICE equal to something else, it gets >< bumped back to 5. >< >That's courtesy of one of the install scripts and/or of copying newunix to >unix when generating a new kernel. >You'll either have to patch newunix or to re-patch the kernel afterwards. Note that A/UX 2.0 has TWO different partial kernels called newunix. The one in root (/newunix) is used only for booting when autoconfiguration is needed. Unlike A/UX 2.0, it is NOT used in building the new kernel. The new kernel is built from /etc/config.d/newunix, and this is the one you need to kconfig if you want changes to stick... Mind you, SLICE might still get tweaked by something else. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)