Sun-Spots-Request@Rice.edu (William LeFebvre) (10/31/88)
SUN-SPOTS DIGEST Sunday, 30 October 1988 Volume 6 : Issue 277 Today's Topics: Mail problems at ukc.ac.uk Re: Memory for a Sun 3/50 (2) Re: PosScript printers for Suns? (networking printers) Re: Shared memory "zombies" Re: Kernel paramters for streams Re: LaTeX and TeX environment on Suns viewtool DELNI collisions (was: SLOW Boot on diskless Suns) 4.0 Sun3 assembler vs. New S Cure for the Summertime Blues? experiences with multiple file servers ? How to adjust tset to setup vt100 emulation? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Sun, 30 Oct 88 14:20:02 CST From: William LeFebvre <phil@Rice.edu> Subject: Mail problems at ukc.ac.uk The host ukc.ac.uk seems to be having some mail problems. And it likes to send failed mail messages about a digest to *everyone* who has a message in the digest (all the addresses in all the "From:" lines throughout the entire body---and it doesn't even do a very good job of building the addresses). Everyone please note: (1) I am aware of the problem, having received quite a few of these messages myself, (2) I am *NOT* the source of the problem (it isn't my fault), (3) I can do nothing about the problem, (4) sending copies of this particular failed mail message to the request address is appreciated but unnecessary and is even getting to be a hindrance, (5) someone has already complained to ukc.ac.uk and hopefully the problem will be cleared up soon, (6) this is happening to other digests (such as TeXHax) as well. William LeFebvre ------------------------------ Date: Fri, 21 Oct 88 09:24:25 PDT From: frame!merlin!sll@sun.com (Suzann Larsen) Subject: Re: Memory for a Sun 3/50 (1) > I spoke with a company in Cambridge, MA recently, that claims to > have upgrade memory for Sun-3/50s.(I will believe it when I see it.) We saw it, we have it, we believe it, we love it! I don't know about the Cambridge company, but we have been a beta site for add on memory for Sun-3/50s from Helios and have been using it with no problems for nearly a month. We have a 4MB and an 8MB add on, giving two very happy users an 8MB 3/50 and a 12MB 3/50. We were sworn to silence during beta, but now they've recently made an official announcement. I was told 4MB would list at $2500 and 8MB at $4750, but of course this is not "official". The local rep I have been dealing with is Dave McWalters, 408-730-2121. If you are interested, I suggest you jump on it quickly, they are still ramping up production and only have limited quantities available. Suzann Larsen Frame Technology System Administration 2911 Zanker Road, San Jose CA 951324 ------------------------------ Date: Mon, 24 Oct 88 14:20:21 PDT From: Jim Frew <frew%huevos@hub.ucsb.edu> Subject: Re: Memory for a Sun 3/50 (2) I just got a teaser card in the mail from Helios Systems advertising add-in memory for Sun-3/50s. A phone call produced the following info: The memory is available in the following sizes: MB Univ. of Calif. price (real world == $ ?) -- ------ 4 $ 2200 8 $ 4250 [[ Rob Liebschutz (rob@presto.ig.com) sent in a message that said "real world" prices were 4 meg for $2500 and 8 meg for $4750, and that price breaks were available for quantities of 10 or more. My thanks to him and others who have sent in similar information. --wnl ]] Each card is a daughter board that sits on top of the 3/50 mother board. The connecting cable must be SOLDERED (!) to the mother board. Since this is a non-trivial installation procedure, you can: -- send the motherboard to Helios and have them install it, for an additional $200 (UC price) -- have them train one of your people to do the installation ($ ?) -- have them send someone to your site to do the installation ($ ?) The teaser card advertises "immediate delivery"... For more info try: Helios Systems 1996 Lundy Ave San Jose, CA 95131 408 432 0292 NOTE: I have NO connection with Helios, other than being a satisfied customer. Our Clearpoint rep has told me that they are working on a similar upgrade, but I haven't seen an announcement yet. James Frew CSL/CRSEO, UCSB, Santa Barbara, CA 93106 +1 805 961 8413 frew@hub.ucsb.EDU ucbvax!ucsbcsl!frew frew@ucsbuxa.BITNET ------------------------------ Date: Mon, 24 Oct 88 10:53:28 EDT From: ted@braggvax.arpa Subject: Re: PosScript printers for Suns? (networking printers) In #268 there's some discussion between wnl and Stephen Daniel about networking postscript printers. I've just come across an interesting item in my mail from QMS (who now own Imagen, by the by). They have a box called QMS PrintLink that sits on your Ethernet as an IP host and lets you FTP print jobs to it. It spools them and prints them on an attached serial or parallel printer. So you should be able to network just about any kind of printer... [[ FTP?!? FTP?!? Why FTP? Seems like overkill to me. --wnl ]] Their Atlanta number is (404) 751-0043 Ted Nolan ted@braggvax.arpa (192.5.92.100 these days) Disclaimer: I have no connection with QMS, haven't called the above number, and have never even seen the thing. ------------------------------ Date: 20 Oct 88 08:06:53 GMT From: rb@ist.CO.UK (Bob Bishop) Subject: Re: Shared memory "zombies" > Has anyone using System V shared memory found a clean way of dealing with > the potential "zombie" shared memory segments? My best shot at this is: the process creating the shm segment forks off a child which sits on a timer, doing a shmctl(IPC_STAT) periodically to find out how many processes have the segment attached. When the count drops to 1, it does a shmctl(IPC_RMID) and exits. This keeps the shared segment around as long as any process other than its "minder" process is attached, and other processes can attach and detach freely. There is of course a race condition to be avoided: "minder" finds shm_nattch == 1, another process attaches, "minder" does shmctl(IPC_RMID) ... ------------------------------ Date: Mon, 24 Oct 88 10:09:49 PDT From: stevo@judy.jpl.nasa.gov (Steve Groom) Subject: Re: Kernel paramters for streams >From: ehrlich@shire.cs.psu.edu (Dan Ehrlich) >... >It appears that not only is the number of streams NOT dependent on >MAXUSERS, number of pseudo-ttys, or anything else. In order to get around >the current problem we just upped NSTREAM to 48, until we can figure out >what a reasonable formula for it should be. > >Has anyone else seen this happen? What if anything was done to fix it? >Can anyone at Sun explain why NSTREAM is fixed at 32? This problem started for us the day after we upgraded to 4.0. Like Dan, I went into /usr/sys/sun4/HOSTNAME/param.c and changed NSTREAMS, I went to 64. I rebuilt the kernel using the fixed param.c and the problem went away. (for the record: this was originally on a 4/280, but applies to all Sun2's, 3's, and 4's.) Later, when speaking to a tech person at Sun about another matter, I mentioned the streams problem. He said that in 4.0, there are a number of streams data structures that are statically sized and do not depend in MAXUSERS, but will be dynamically allocated in later releases. NSTREAMS is only one of them. He suggested that I check and modify several parameters in param.c (in addition to NSTREAMS). These are the number of streams data blocks (dblks) of different sizes (bytes) that the kernel allocates at boot-time. #define NBLK4096 0 #define NBLK2048 32 #define NBLK1024 12 #define NBLK512 8 #define NBLK256 32 #define NBLK128 96 #define NBLK64 240 #define NBLK16 400 #define NBLK4 128 After a machine has been up for a while and has been heavily loaded, do a 'netstat -m'. The output describes network memory allocation information and streams information. The streams information shows the current and the maximum (since boot, not max avail) number of streams allocated, and the number of allocation failures. Below that is allocation information for dblks. The idea in tuning these parameters is to reduce the number of allocation failures to 0. How to do it? Brute force. The method suggested was to increase all of the NBLXx parameters by a large amount (say, triple or quadruple each of them, and raise NBLK4096 to about 16). Then load the machine and watch for more allocation failures. Maybe let it run for a day or two. If you see a lot of failures, increase the corresponding parameter(s) and repeat. When things look good (few or no failures), start trimming them back down. Use the high-water marks under the 'maximum' column as a guide, setting the parameter to something like 20% over the maximum. (BTW, I'll say it here in case you haven't figured it out -- you need to make and install a new kernel, and reboot each time you change param.c.) I am not certain of the overhead associated with these parameters - in other words, what it costs in terms of kernel memory usage when you increase them. NBLK4 refers to 4-byte blocks and so on, so if you add them all up you'll find its on the order of 100K - not too much to ask on server. Even tripling that probably wouldn't hurt. But it is important to realize that you should be sure to go back and trim out the excess. Never-used buffer space doesn't buy you anything in performance, and it does cost something in terms of wasted memory. So don't skip the trim-down step, even though its not that urgent. This appears to have helped performance on our machines, especially on our I/O-intensive Sun2. Precise measurements are difficult, because we are talking about overall system performance, not just raw speed or throughput or somesuch. But as I said, it appears to have helped. Of particular help was the addition of a few NBLK4096's. Why the default on that one is 0 I don't know. Many thanks to the extremely helpful tech person at Sun. -steve Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109 Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo Disclaimer: (thick German accent) "I know noothingg! Noothingg!" ------------------------------ Date: Mon, 24 Oct 88 12:04:51 pdt From: rusty@cartan.berkeley.edu Subject: Re: LaTeX and TeX environment on Suns > From: bonham@ucalgary.ca (Michael Bonham) >... > 1) Is there an undump for SunOS 4.0? Where is it or how do I build one? >... In my opinion (and other's) you're better off using the virtex scheme of loading the .fmt files IF you use the c version of tex. You can get the c version of tex, metafont, et. al. via ftp to ics.uci.edu. "get" the file web2c.tar (and anything else that looks obvious). This is so much faster than the pascal version that the time loading the .fmt files is trivial. An additional advantage is that the undumped versions are huge (take up a lot of disk space) whereas the virtex/.fmt files aren't. Another advantage is the the web2c package includes a change file to make a "gargantuan" tex, and it doesn't use any more disk space. With the gargantuan tex you'll probably never get the "tex capacity exceeded" message unless there's a bug in one of your macros. ------------------------------ Date: Mon, 24 Oct 88 11:53:02 EDT From: rainbow@sbcs.sunysb.edu Subject: viewtool Two friends and myself have developed a SunView program that can be used to quickly prototype SunView user interfaces (A more complete discribtion of viewtool is at the bottom of this message). This tool is called viewtool and is currently being beta tested. If anyone out there in "Netland" would like to join the growing number of viewtool beta testers, or would just like a copy of the sources to check out, you can do the following: send email to: UUCP: {allegra, philabs, pyramid, research}!sbcs!rainbow CSnet: rainbow@suny-sb Bitnet: in%"rainbow@sbcs.sunysb.edu" Arpanet: rainbow@sbcs.sunysb.edu with the Subject: viewtool source request or viewtool can be ftp'ed from sbcs.sunysb.edu (129.49.89.3). (ALSO, touchup (bitmap editor) and 8to1 (sun rasterfile color to mono converter) are available for anonymous ftp from suny) When the release version of viewtool is complete, it will be posted to the net. min ____________________ Viewtool is a window and mouse-based user interface tool for generating SunView application programs. Viewtool provides a convenient and powerful user interface for SunView programmers to write their application programs' user interface part, they do not have to go through the tedious job of creating windows, setting window parameters etc. but are provided a visual interface to create frames, subwindows and panel_items, resize, copy and move them dynamically. Finally, viewtool generates the "C" code with the SunView window-specification calls for you, what you see is what you get. Viewtool enable the user to quickly create frames, panels etc. dynamicly. While the user is on viewtool they can "move", "copy" and "tidy" panel items. Once you have built the correct SunView user interface, you can have viewtool generate the "C" code that is required to build the current interface. This "C" code then can be incorpated in to you only programs. ------------------------------ Date: Mon, 24 Oct 88 14:54:30 edt From: eplunix!das@harvard.harvard.edu (David Steffens) Subject: DELNI collisions (was: SLOW Boot on diskless Suns) > Appearently there is enough shared logic in the DELNI that trying to > rapidly pump large amounts of data between two ports results in a large > number of 'collisions' being reported. (Can anyone confirm/deny this?) I'm no expert, but this doesn't sound right. We had a similar problem and found the _real_ cause of these "pseudo-collisions" was Ethernet version mismatches. We thought we could just insert a DELNI between an old Interlan board and its transceiver. No way since that hardware was version 1 and the DELNI is (sort-of) version 2. We saw a _lot_ of collisions when sending thru the Interlan, e.g. average of 1.5 collisions per packet sent! Attaching the DELNI to the backbone with its own transceiver and re-connecting the old hardware fixed that. Now I can send gobs of packets from one port of the DELNI to the other without seeing a _single_ collision when our net is lightly loaded. {harvard,mit-eddie,think}!eplunix!das David Allan Steffens 243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory (617) 573-3748 Mass. Eye & Ear Infirmary ------------------------------ Date: Mon, 24 Oct 88 10:15:53 EDT From: mcintosh@flash.bellcore.com (Allen Mcintosh) Subject: 4.0 Sun3 assembler vs. New S I ran into this one also. You can bypass it by moving the definition of catchfpe() to the front of the file. I suspect that this is an obscure bug in the SDI algorithm in the assembler. I have a relatively small file that re-creates the problem, if anyone out there is interested. Allen McIntosh mcintosh@flash.bellcore.com ------------------------------ Date: Mon, 24 Oct 88 12:59:02 BST From: Paul Leyland <pcl%robots.oxford.ac.uk@nss.cs.ucl.ac.uk> Subject: Cure for the Summertime Blues? The algorithm for detecting the end of summertime in the UK for SunOS is bugridden this year. We all altered our clocks this weekend. When I came in this morning, the machines were still on BST. 'Sfunny, but it got it right in the spring. Does *anyone* understand how BST/GMT is decided? Paul Leyland (JANET: pcl@uk.ac.ox.robots) (UUCP: ...!mcvax!ukc!ox-rob!pcl) ------------------------------ Date: Mon, 24 Oct 88 08:02 EDT From: davis%blue@sdr.slb.com Subject: experiences with multiple file servers ? Organization: Schlumberger Cambridge Research Snail: PO Box 153, Cambridge CB3 0HG, England Phone: [+44] (0) 223 325282 We're in the process of trying to install our new 4/260 file server and I'd appreciate some pointers on other folks experiences. The heart of our problem is that it really looks as if we're going to move from a system with a single point of failure (the exiting server) to one with two: here's the gen: existing: 3/180 server with 14 clients (3/50's, 3/110's) with 2 375MB disks and 1 575MB disk planned: 4/260 server with 14 clients (3/50's, 4/110's) with 2 892MB disks 3/180 server with 7 or 8 clients (3/50's, 3/110's) with 2 375MB disks and 1 575MB disk Problems: /home : if we put all user home directories on one disk attached to the 4/260, the whole system is `down' if this server goes down. /export/exec/sun3: there seems little point in duplicating the binaries for the Sun 3's, so the plan is to "mount" the /usr dir of the old server as /export/exec/sun3 on the new one, albeit done directly by the clients (you can't do a third party mount). This gets us into a stupid cross-thread of file-serving activities. It looks to me as if we might be trying to do something highly inappropriate here: comments or pointers anyone ? What I'd really like to go for is all home dir's on one disk (or at least, one server), and as little other cross-threaded file serving as possible. It doesn't look straightforward, but maybe I'm thinking about it TOO hard. thanks in advance, Paul Davis Internet: davis%blue@sdr.slb.com ------------------------------ Date: Mon, 24 Oct 88 09:02:52 CDT From: AARON KONSTAM <79343382@TRINITY.BITNET> Subject: How to adjust tset to setup vt100 emulation? I wonder if someone could help with the following problem. I can set a tset containing line in .login so that all dialin access causes the Sun 3 to enter Vt100 emulation but I have been to construct a command that would force the Sun to be a vt100 terminal if the user was on a dialin terminal or the user wasn't on the console. This should be possible but I can't male SunOS 3.5 accept the @ sign that the documentation says means not. You can write me directly. Aaron Konstam Trinity University 79343382@trinity.bitnet P.S. By the way ASCII to EBCDIC to ASCII turns right and left Brackets to U and E and converts the C OR symbol to right bracket. I couldn't type those directly into this message for that reason. This as one might imagine plays havoc with C source and shell programs sent by electronic mail. ------------------------------ End of SUN-Spots Digest ***********************