Sun-Spots-Request@RICE.EDU (Scott Alexander) (02/28/86)
SUN-SPOTS DIGEST Thursday, 27 Feb 1986 Volume 4 : Issue 6 Today's Topics: Sun multi-user licenses Re: Xylogics 451 (3) Re: Dhrystone discrepancies tip problem WYSIWYG Editors, Graphics & Spreadsheets ksh on suns time on a Sun? hardware flow control on zs inetd and nfsd problems ------------------------------------------------------------------------ Date: Wed, 19 Feb 86 07:15:25 est From: Robert Morris <ram%umass-boston.csnet@CSNET-RELAY.ARPA> Subject: Sun multi-user licenses This astonishing price rise for multi-user licenses RAISES, rather than lowers the price differential of Sun's vs. competition for multi-user systems. Since Sun was already 20 % higher than similar unix boxes, e.g. ISI. Conceivably, it even makes an IBM RT high end system be a rational alternative to a Sun, something I thought would never happen (do RT's run multi-user with their 4BSD software?) Note further that for Sun 3's there presently appears to be only Sun's VME->Multibus adapter + Systech multibus card as a serial line cability. These seem over-priced at $4000 / 16 users (refurbished 1 board Able DH cards suitable for the VAX are selling for <$400 in the mail order market, which is cheaper than repairing broken ones). Our application is 16 terminals and 16 connections to single board microcomputers. Is Sun going to want a 32 user license to sell us 32 lines? This seems to be a message that Sun does not really want to be in this part of the business. All in all it makes it particularly hard for universities who are trying to incrementally replace their VAXen or add more 4BSD computing power - such institutions, like my own, face buying something like $50k / year of hardware over several years, instead of all at once. Bigger purchases, it is my experience, tend to induce Sun and others to offer bigger discounts; They are not interested in "dribble" purchasing such as I describe (this is especially true of startups, whose near term sales volume has a tremendous effect on their efforts to raise capital). DEC, IBM and others after the university time sharing market ought to be pleased. ----------------------------- Date: Wed, 19 Feb 86 11:03:22 mst From: dspo!tomlin@LANL.ARPA (Bob Tomlinson) Subject: Re: Xylogics 451 > Subject: Xylogics 451? > Newsgroups: mod.computers.sun > References: <1986.02.08.17.03.13.390.05518@iapetus.rice> > > I would like to try Xylogic's new disk controller board, the 451, > in my 2/170.... > ...My questions are, has any > brave soul tried the 451 on their Sun yet and did it work? We are using several of those new disks you are referring to on Suns. We're using the Fujitsu M2333K (333MB in an 8 inch form factor). (The M2333 is to the M2322 as the Eagle-2 is to the Eagle.) The Xylogics 450 will work with the new disks however it can't keep up and you blow revs. We used a borrowed 451 (no changes to software) for a couple weeks. It works exactly as if you had a 450, but fixed the performance problem associated with too fast a disk and too slow a controller. We used the 451 on a 2/120 running Sun Unix versions 2.0 & 2.1 (maybe version 1.4 also). We're also using the M2333 on 3/160s. Another disk we're using is the Hitachi DK815 which gives 525MB in a 9 inch form factor. We're getting either the Hitachi 815 or the Fuji 2333 for just over $5K. -- bob ----------------------------- From: hitchens@uo.UTEXAS.EDU Subject: Fat Eagles and Xy451s Has anyone out there attached one of the new double-density eagles to a Sun-3 (or even a Sun-2). It's my understanding that the Xylogics 451 looks the same as the 450 on the multibus (and therefore should look the same on a multibus->vme adapter). The only effective difference then, as far as the software is concerned, is that there are twice as many sectors per track, and that information is recorded in the disk label. That's my view of the universe, can anybody verify it against reality? I asked someone at Sun about this and he didn't really now for sure. He said he thought there was support for it in the 3.0 diag, which is what you need to get it formatted and labelled, but otherwise couldn't help much. He pointed out that Sun doesn't support such a configuration, but that doesn't concern us much since we do our own maintenance, and have done quite a few unsupported things to our suns already. We're about to aquire about a new gaggle of suns (~25) and would like to find out if we can plan on using the bigger eagles on our servers. They make a lot of sense in terms of space/power/money consumption per unit of storage. Has anyone tried it? The UT beauracracy makes it very tough exchange something if it doesn't work, otherwise we'd just buy one and give it a shot. Lead times for purchasing are also excruciatingly long. I'd appreciate any experience, opinions or inside info about this. It's probably best to reply to me directly and I'll summarize to this list. Thanks, Ron Hitchens University of Texas Computer Science hitchens@uo.UTEXAS.EDU or hitchens@sally.UTEXAS.EDU ...!{seismo,ihnp4,shasta}!ut-sally!hitchens ----------------------------- From: seismo!allegra!phri!roy@sally.utexas.edu (Roy Smith) Subject: Re: Dhrystone discrepancies Ken Mandelberg reported in v4n5 that Dhrystone runs 25% slower on his 3/50 than it does on his 3/160. From looking at just the clock speeds, he expected a 10% slowdown. Based on what the Sun salespeson told me, the 3/160 processor (also used in the 3/75 and 3/180) both have dedicated video memory in addition to the basic 4 Meg of user memory. The 3/50 steals its video memory from the regular 4 Meg array that comes with the machine (funny, they don't tell you this in the glossies :-)). I suspect the missing 15% is due to memory contention between the CPU and the video refresh. If this is indeed the case, I would imagine that speeding up the clock in the 3/50 won't gain you anything except more wait states. The same salesperson told me the following: Q: What's the difference between a computer salesman and a used car salesman? A: The used car salesman knows when he's lying. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----------------------------- Date: Thu, 27 Feb 86 10:02 EST From: PACE%FSU.MFENET@LLL-MFE.ARPA Subject: tip problem hi; We are having a problem installing tip,uucp,etc on our SUN-170. We have followed the instructions in the Hardware Installation Guide and have gotten to the point where modems will answer the phone and connect to the system but we can not make the phones dial out. Has anyone done this and if so have I overlooked anything that is so obvious that it is not in the manual. Also, were there any tricky operations that were not adequately presented in the book. -don pace Florida State University Computing Center P.S. this is for our Center for Music Research. ----------------------------- From: Christie Harslem <harslem@rand-unix.ARPA> Date: 19 Feb 86 08:22:54 PST (Wed) Subject: WYSIWYG Editors, Graphics & Spreadsheets Besides Interleaf and Alis, can anybody give me some leads on WYSIWYG editors, MacDraw type graphics and spreadsheets for the Suns? Send comments to me and I will summarize to the net. Thanks ----------------------------- From harvard!wanginst!ss@sally.utexas.edu Mon Feb 24 17:52:03 1986 Date: Mon, 24 Feb 86 12:48:13 est Subject: ksh on suns Hi folks, Has anyone ported ksh to a sun yet? Seems likely, but I can't recall hearing about it. Thanks, -- Sid Shapiro -- Wang Institute of Graduate Studies decvax!wanginst!ss ss%wanginst.CSNET@Csnet-Relay.ARPA (617)649-9731 ----------------------------- Date: Tue, 25 Feb 86 17:11:43 PST From: mayo@renoir.berkeley.edu (Bob N. Mayo @ U.C. Berkeley Computer Science) Phone: (415) 642-9716 Subject: time on a Sun? It turns out that Suns do really odd things if the time is set wrong. For instance, the yellow pages can get screwed up and it may not even be possible to log in (execpt as root or some other name in the actual /etc/passwd file). Also, commands like "ls -l" may hang for a certain amount of time (the time difference between the fileserver and the local machine). Does anybody have a program that sets the time correctly? RDATE doesn't count, since it can only adjust the time +/- 12 hours. How about something that will at least get the date right, which can then be followed by rdate? --Bob ----------------------------- From: harvard!wjh12!biomed!aoa!mark@sally.utexas.edu Date: Wed, 26 Feb 86 11:53:15 est Subject: hardware flow control on zs I am trying to find out some information on the zs ( serial ) driver on the Sun 2. What I want to do is very simple: I would like to use a tty port as an I/O port to a device that obeys hardware flow control. The device would be the DCE ( modem ) and the Sun's tty port would be the DTE ( terminal ). If some combination of CTS DSR and CD were made logically false the DTE ( the Sun ) would shut up and cease to send; if some combination of DTR and RTS were made false the DCE would shut up and cease to send. From the Sun's point of view these telling the DCE to shut up would be conditioned on the zs silo being full and/or inability of the software to eat characters as fast as they are coming in. The goal is that the device is uncontrollably shipping completely arbitrary bytes at 9600 baud ( but never more than 8K ). I want to prevent any lost bytes. I am sure this has been discussed before. I do not have source, nor do I have a hardware manual for the zs. What I think I have learned so far from poking around in various places is: 1) There are an extremely large number of ioctls that may or may not apply to ttys in <sys/ioctl.h>. Some do obvious and verifiable things ( TIOCCDTR and TIOCSDTR for example ), others are obscure. Most do not seem to be documented in any documentation I have. 2) Poking around the zs includes in /sys/sundev would seem to indicate that the zs device has a mode in which it uses hardware flow control ( ZSWR3_AUTO_CD_CTS bit ); 3) Looking at the terminal line during both inbound and outbound transfers shows that only TxD, RxD, and DTR are active. My question is, can a tty device be put in a mode which uses hardware flow control? If so, how? If not, what other alternatives are available? Please help; this is quite important. To qualify my question, let me say I am a Sun novice. I have been around UNIX for quite a while, and I THINK I understand the RS232 so-called standard. Please feel free to flame my ignorance and/or stupidity. Thank you in advance. Please mail responses to me. I will summarize if interest warrants. Mark Reynolds @ ( Adaptive Optics Associates ) { wjh12 | mit-vax } ! biomed ! aoa ! mark { decvax | linus | ima | ihnp4 } ! bbncca ! aoa ! mark ----------------------------- Date: Mon, 24 Feb 86 23:31:49 PST From: argv@sri-spam.ARPA (AAAARRRRGGGGv) Subject: inetd and nfsd problems Has anyone had problems with inetd and nfsd on sun 2.2 systems (or even 2.0)? The scenario: Various file servers ranging from a few 120's a 150, 160 and 170 were all (at one time) running 1.4 The 150 upgraded to 2.0 and was running just fine with about 11-12 clients. Load on the server hung around 1.5 to 2. Nothing really extraordinary... next file server to 2.0 -- a 120 with 3-4 clients. No problem. Finally, a complete 2.2 system was installed on a 120 with two maxtor 1140's, six clients alloted for but only running two. Fine. Add another client... fine. Upgrade the 2.0 120 to 2.2 and everything is running like a dream. So, we upgrade the 150 from 2.0 to 2.2 and bring it up. Immediately, the load went sky high to about 10.5 to 12 and nfsd's were eating all the cpu time. In fact, so much so that it was impossible to login on the console. Clients were running a little better, but not significantly. /usr/adm/acct fills up the entire root partition on all clients with inetd messages -- forked inetd's were occuring about 100 or so times per minute! Most clients had accounting suspended before the boot procedure was finished. So, killing the inetd completely allowed clients to work again at a reasonable rate and the server seemed a little happier. However, in only one-two days, nfsd shows (from ps) a time consumption of about 1400 minutes and some-odd seconds and all four were taking from 15 to 25% percent of cpu time per nfsd. We tried killing them and running nfsd with 8 daemons, but this did nothing. In the meantime, inetd is going crazy everywhere. Out of desparation, we downgraded back to 2.0 and ran things again. The problems still exist but at a lesser rate. It takes about 2 minutes to login as root on the console and inetd's are still going crazy and nfsd's are as well. The only difference is that it tapers off during slower times but not to an acceptable level. At one point, the server crashed when the load hit over 18. All the other 2.2 systems showed the same problems when given more than 4 clients. according to netstat, packets are going out into the net at about 100/second and we're getting collisions ranging from 1 to 8 percent on both 2.0 and 2.2 systems. What I don't understand is why the problems persisted when the 2.2 upgrade went back to 2.0. We are now installing 2.0 on a new file server with 15 or so clients and 2.0 on yet another with 15 as well. Since we didn't have the problem before the upgrade on the other servers, hopefully we won't have the problem again. But, before we can upgrade to 2.2, we need to be sure that this doesn't happen again. I haven't heard of any other people having this problem to such an extreme, altho I have heard of people having problems with inetd. In fact, I use another file server (a 130 -- vme based) with 15 clients that is running 2.2 without problems. I have examined binaries and config files, /etc files, fstabs, anything. There is nothing obviously wrong (unless it's TOO obvious) but there is something there causing all this. If anyone has any experience with the same sort of problem, please mail me -- dan argv@sri-spam.arpa ----------------------------- End of SUN-Spots Digest ***********************