phil@eecs.nwu.edu (Bill LeFebvre) (08/03/89)
Sigh. Some programs can make system management sooooo much easier. Too bad UMAX doesn't have them. Wishful thinking: maybe I can get copies from *somewhere*...... I realize that some of these are non-standard, but here's my list anyway: vmstat pstat clri (especially given the UMAX4.2 file system problems) sps top (but that's my fault, I guess) All I have is ps, and it can't even select processes by username. Sigh. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
rackow@SKEEVE.MCS.ANL.GOV (Gene Rackow) (08/03/89)
There is also a problem with depending upon the OS level you are at with sysmon. The VM stats are incorrect. This is not really a problem with sysmon, but the system calls themselves if I remember correctly. You can't even write a utility that will give you the correct info, unless you correct the system call. This is somewhat from memory as these are things that I wanted some time ago, but has been promised for the next release. -- Gene Rackow email: rackow@mcs.anl.gov Math & Computer Science voice: 312-972-7126 Argonne National Labs Argonne, IL 60439
clyde@ut-emx.UUCP (Clyde W. Hoover) (08/03/89)
Well, you are discovering that UMAX 4.2 is not BSD 4.2. Those particular programs won't work under UMAX (well, clri probably could). The others in your list (vmstat, sps, top, pstat) all rely on the kernel data structure formats and naming convention from BSD kernels. UMAX uses a sufficently different way of organizing its kernel structures that these BSD-isms won't work. However, all is not lost - there are sufficent equivilants available in the 'sysmon' command: vmstat = sysmon -n vm sps, top, pstat = sysmon -n proc Play around with the '-d' option to sysmon to truely get more information than you know what to do with. -Clyde Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@emx.utexas.edu; ...!cs.utexas.edu!ut-emx!clyde Tip #268: Don't feel insecure or inferior! Remember, you're ORGANIC!! You could win an argument with almost any rock!
phil@delta.eecs.nwu.edu (Bill LeFebvre) (08/03/89)
In article <16531@ut-emx.UUCP> clyde@ut-emx.UUCP (Clyde W. Hoover) writes: >Well, you are discovering that UMAX 4.2 is not BSD 4.2. Those particular >programs won't work under UMAX (well, clri probably could). The others in your >list (vmstat, sps, top, pstat) all rely on the kernel data structure formats >and naming convention from BSD kernels. UMAX uses a sufficently different way >of organizing its kernel structures that these BSD-isms won't work. Yeah, I figured that, having written one of those utilities :-). But clri?!? C'mon! >However, all is not lost - there are sufficent equivilants available in the >'sysmon' command: Yes, and thanks to all who pointed me at sysmon. I didn't know it was there (I haven't had time to explore yet). I wish there was something simpler to use, but it will have to do. Think about it, tho.... The times when you REALLY want to run something like sysmon are the times when the system is misbehaving. Chances are that you are going to have a difficult time getting anything started. Sysmon uses curses, which is a big hog. It's going to take forever to crank up if someone has started a bunch of processes running amok. And when I noticed that pstat was missing was when processes were dying from an inability to allocate virtual memory. I NEEDED to find out how much swap space was left to see if that's what the problem was. Sysmon is HUGE! There's no way it would have started up. So it's pretty much useless at that point. If I'm stuck in a traffic jam, I can't use a car to get to the source of the jam very easily. I need something smaller, like a bike! So my feeling is: sysmon is a cute toy, but it isn't going to be much of a help when I really need it. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
peralta@xenna.Encore.COM (Rick Peralta) (08/04/89)
In article rackow@SKEEVE.MCS.ANL.GOV (Gene Rackow) writes: > There is also a problem with ... > [and the fix] has been promised for the next release. There will be a normal /dev/kmem in Umax 4.0 (4.3BSD w/tahoe) too. So, all your favorite kernel toys will be able to have access... - Rick "Running at better beta sites now..."
phil@delta.eecs.nwu.edu (Bill LeFebvre) (08/04/89)
In article <12006@xenna.Encore.COM> peralta@xenna.UUCP (Rick Peralta) writes: >There will be a normal /dev/kmem in Umax 4.0 (4.3BSD w/tahoe) too. >So, all your favorite kernel toys will be able to have access... Yeah, but will the nlist labels be the same?!? :-) William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
peralta@xenna.Encore.COM (Rick Peralta) (08/05/89)
In article phil@delta.eecs.nwu.edu (Bill LeFebvre) writes: >In article peralta@xenna.UUCP (Rick Peralta) writes: >>There will be a normal /dev/kmem in Umax 4.0 (4.3BSD w/tahoe) >>So, all your favorite kernel toys will be able to have access... > >Yeah, but will the nlist labels be the same?!? :-) Well, the basic answer would have to be no. But, the raw information should all be there. - Rick "Uh oh... I hear the peanut gallery clammering..."
robertl@bucsb.UUCP (Robert La Ferla) (08/05/89)
In article <16531@ut-emx.UUCP> clyde@ut-emx.UUCP (Clyde W. Hoover) writes: >Well, you are discovering that UMAX 4.2 is not BSD 4.2. Those particular >programs won't work under UMAX (well, clri probably could). The others in >your list (vmstat, sps, top, pstat) all rely on the kernel data structure >formats and naming convention from BSD kernels. UMAX uses a sufficently >different way of organizing its kernel structures that these BSD-isms won't >work. We have both top and sps running here at Boston University on our 4 XPC Multimax. __ / \ / __/_ /___/ __ /_ __ __ / / \ '_' /_/ |_- / ' /
barbarae@maxzilla.Encore.COM (Barbara S. Epstein) (08/07/89)
Here is the status of the Umax 4.3 programs in question . . . vmstat - this has been ported for Umax 4.3 and uses (for the most part) inq_stats rather than kmem. pstat - this has been ported for Umax 4.3 and uses (for the most part) kmem. clri - this exists in Umax 4.3 sps - top - I beleive that this is in Umax 4.2 (the current release) but it is certainly in Umax 4.3 and uses inq_stats. sysmon - same as always netstat - this exists in Umax 4.2 and also in Umax 4.3. It uses inq_stats. iostat - this has been ported for Umax 4.3 and uses (for the most part) inq_stats rather than kmem. systat - this has been ported for Umax 4.3 and uses (for the most part) inq_stats rather than kmem. (it also contains an extra section to display relative cpu statistics) Of course I, personally, make no guarantees on the above mentioned programs. Furthermore there may be one or two fields missing from any given program. Hope this is helpful, Barbara Epstein
boneill@hawk.ulowell.edu (Brian O'Neill - SoftXc) (08/08/89)
In article <1000@accuvax.nwu.edu> phil@delta.eecs.nwu.edu (Bill LeFebvre) writes: > >Yeah, but will the nlist labels be the same?!? :-) > > > William LeFebvre Speaking of the nlist labels, does the UMAX 4.2 kernal have an equivalent to BSD's avenrun, for finding the load average? In porting X-windows code, xload is the only program I could not compile, and it needs the load average variable. ============================================================================== Brian O'Neill, MS-DOS Software Exchange Coordinator Internet: boneill@hawk.ulowell.edu UUCP: {(backbones),harvard,mit-eddie,et. al.}!ulowell!hawk.ulowell.edu!boneill
madd@bu-cs.BU.EDU (Jim Frost) (08/09/89)
In article <12267@xenna.Encore.COM> barbarae@maxzilla.UUCP (Barbara S. Epstein) writes: |Here is the status of the Umax 4.3 programs in question . . . [..] |sps - [..] If you've been reading this you know, but I just posted my public-domain version of sps for the encore. It makes use of inq_stats. jim frost software tool & die madd@std.com
wtm@buengc.BU.EDU (W. Thomas Meier) (08/11/89)
I wonder how accurate the inq_stats are for some of the calls. On using vm_swap and vm_file it seems like you get pretty low values on a loaded system with little memory. There is little in the form of direction on how to use the system calls beside what you can read from the ".h" files in /usr/include/sys. Also, does anyone know what the value of lazy validations is? Tom Meier System Mangler Boston Univeristy Information Technology
loverso@Xylogics.COM (John Robert LoVerso) (08/16/89)
Actually, the two things I miss greatly are process arguments and working network code! (Not being able to reach BARRnet from NEARnet because the of 4.2-style IP TTL handling is sad). Thankfully, the network code has been taken care of in UMAX4.3 (hopefully, ptys too). However, the only way to get real argument lists out of a kernel is to run MACH instead of UMAX. Thankfully again, it is available now, albeit as a beta release. Additional pluses are that you also get 4.3BSD-Tahoe compatibility at the kernel and user code levels, with such bonuses as bind4.8, sendmail5.61, etc, all being standard and working. John (of course, the viewpoints above in no way reflect opinion at Xylogics)
phil@delta.eecs.nwu.edu (William LeFebvre) (08/16/89)
In article <6917@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes: >Actually, the two things I miss greatly are process arguments and >working network code! (Not being able to reach BARRnet from NEARnet >because the of 4.2-style IP TTL handling is sad).... I'ts really not IP TTL that's the problem (does IP even *have* a TTL field?). It's TCP's TTL field that's too small: 15. But if you have software support, tell Encore that you need a larger TTL. We did, and we are now running a UMAX 4.2 kernel with TCP TTL set to 60! They were quite helpful. This is kind of an annoying, funny, sad story: when one of the technical guys got back with me about this problem, he said "we'll make you a kernel with TCP_TTL set to 60. Is that alright?" I said, "60?!? What were you using before?" He said, "30". I said, "well you started off where I want to be---ours came set at 15. So 60 will certainly be adequate." William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
loverso@Xylogics.COM (John Robert LoVerso) (08/16/89)
In article <1057@accuvax.nwu.edu> phil@delta.eecs.nwu.edu (William LeFebvre) writes: > I'ts really not IP TTL that's the problem (does IP even *have* a TTL > field?). It's TCP's TTL field that's too small: 15. Actually, it is an IP TTL. TCP doesn't have one. The problem is really in the default value for the IP TTL that's given to originating TCP segments. 4.2BSD did two bad things: set the default to 15 (4.3 has 30) and decrement the TTL of incoming IP datagrams by 5 (4.3 decs by 1). John