Robin@turbo.RAY.COM (Robin Alston) (01/20/88)
With the low cost of 386 based machines with what looks like good performance I would like to ask the world for some help on a system I am being asked to configure. I want to support a community of 60 programmers. I would like to have available certified ada. Is there a unix clone with nfs or something similar out there that allows me to buy say 20 386 machines (compaqs or similar) with some having big (200 mb+) disks and some having IBM mainframe link hardware. The reason I ask is that it appears to me that such a system would provide pretty good performance without the reliance on a single central node that causes us a lot of grief at the moment with system load problems. I appreciate that I could probably look at sun stuff and maybe others but I get the impression that economically a suite of 386 machiens would be cheaper (with some coming in for under $4000 with 60 mb disks). Anyt body any thoughts on this. Is it a realistic idea? Need: UNIX with certified ada NFS or something to make the filesystem look like one big one. IBM comms and terminal emulators. -- ------------------------------------------------- # Whats worse than two MA drivers on a freeway? # Dr. Robin the REAL # Answer: One Toronto driver # SuperUser Atilla! ------------------------------------------------- (617)-460-8225 Robin@turbo.ray.com .....!rayssd!turbo!Robin
jeg@ptsfa.UUCP (John Girard) (01/21/88)
I administrate a SUN 3/260C which is used as a PC-NFS controller
and Yellow Pages Gateway. We have several Compac 386s connected at
this time, via Ungermann/Bass broadband. The approach we have
taken to this point is to use the SUN as a standard multiuser
development environment via Telnet, and to use the NFS "DOS" disk
drives for shared PC file systems. In this fashion, we have high
performance development environments for both DOS & UNIX applications.
Things are working out pretty well. Here's a summary of the
interesting things we have learned.
It makes sense to back up the PC shared file systems
to a large hard drive on one of the PCs. After all,
if the network goes down, how can you access those
files?
PC-NFS is very poor at diagnosing its own problems.
In fact, it cannot even tell whether or not the
ethernet carrier is present. The utilities, such
as "nfsping" are less than satisfactory. The majority
of our transmission problems have turned out to be due
to low signal strength. When you get hooked up, drag
someone with a signal analyzer out and make sure you
have sufficient DBs to meet your network standard.
We were dissatisfied with the lack of good pc-to-pc
utilities supplied with NFS and have written many
of our own. This is simple to do with DOS batch and
a few auxiliary programs.
If you want to use a PC type printer on the network,
such as an HP Laserjet+, be warned that (in our
experience), the SUN strips the 8th bit off of data
going to the printer in "cooked" and CBREAK mode. If
you want to be able to send rasters and graphic characters,
you will have to put the printer in raw mode. Unfortunately
you will lose flow control in raw mode, so you have to
slow the baud rate down to 2400 or so (and don't run
out of paper). Someone from HP suggested configuring the
printer as a *modem* ... it's on our list to try.
PC-NFS does fight with some software packages, but there
are workarounds. The major problem is that its drivers
gobble up a terrific amount of memory and are not relocatable
in extended memory. We are looking at using DESQview or
Windows to allow us to open up application windows with
reasonable amounts of memory.
If you have a Microsoft Bus mouse, try setting it for
interrupt 5 and set your NFS interface card for interrupt 7.
Telnet bypasses the local screen drivers, which means you
can't write your own ANSI, X, or other escape coded
command sequences. Telnet only recognizes vt100 sequences.
Richard Spellman of SUN PC NFS product support says this
is a "feature."
Our attempts to get advice and assistance from SUN have
been unsatisfactory. They tend not to answer mail and not
to call back. They have broken all committments with me
to respond to our questions.
Overall impression: It's a pretty good file system even though the
support is lousy. Hope this helps people who are considering NFS.
BTW, I am thinking about writing some articles about the utilities
we have developed. Any suggestions for the best magazines to pursue?
John Girard
{ihnp4,pyramid,cbosgd}ptsfa!jegcramer@optilink.UUCP (Clayton Cramer) (01/22/88)
> > I administrate a SUN 3/260C which is used as a PC-NFS controller > and Yellow Pages Gateway. We have several Compac 386s connected at > this time, via Ungermann/Bass broadband. The approach we have > taken to this point is to use the SUN as a standard multiuser > development environment via Telnet, and to use the NFS "DOS" disk > drives for shared PC file systems. In this fashion, we have high > performance development environments for both DOS & UNIX applications. > > Things are working out pretty well. Here's a summary of the > interesting things we have learned. > > PC-NFS is very poor at diagnosing its own problems. > In fact, it cannot even tell whether or not the > ethernet carrier is present. The utilities, such > as "nfsping" are less than satisfactory. The majority > of our transmission problems have turned out to be due > to low signal strength. When you get hooked up, drag > someone with a signal analyzer out and make sure you > have sufficient DBs to meet your network standard. Ditto. We had several systems that allowed network file server access, but when you printed a file from Microsoft Word, then exited Word, the PC locked up. It turned out the problem was we had used the DOS APPEND command to add directories to our PATH. I suspect that PC-NFS MAY pick up a pointer to the PATH when it starts, and that APPEND is changing the location of the PATH. In any case, PC-NFS is not at all good about figuring this out. > PC-NFS does fight with some software packages, but there > are workarounds. The major problem is that its drivers > gobble up a terrific amount of memory and are not relocatable > in extended memory. We are looking at using DESQview or > Windows to allow us to open up application windows with > reasonable amounts of memory. I'm currently trying to get the InSet text/graphics integrator working with Microsoft Word and PC-NFS. InSet grabs the printer interrupt (17H), but so does PC-NFS. No problem, I say, I'll install InSet first, then PC-NFS. That way they will chain together. (At least Inset Systems says it works with other networks). Nope. Doesn't work with PC-NFS, though I still have determined who the most guilty party is. > Our attempts to get advice and assistance from SUN have > been unsatisfactory. They tend not to answer mail and not > to call back. They have broken all committments with me > to respond to our questions. Our experience has been that Sun answers mail and calls back, and really tries to help us solve the problems -- but the PC-NFS guys know nothing about the Sun side of networking, and the Sun networking people are almost completely ignorant of PC-DOS -- to say nothing of the PC-NFS stuff. My impression is that the PC-NFS guys are principally useful as facilitators -- they talk you through the process by which YOU figure out what's broken -- they didn't figure out that APPEND was blowing us out of the water -- we did. > John Girard Clayton E. Cramer
guy@gorodish.Sun.COM (Guy Harris) (01/23/88)
> If you want to use a PC type printer on the network, > such as an HP Laserjet+, be warned that (in our > experience), the SUN strips the 8th bit off of data > going to the printer in "cooked" and CBREAK mode. If > you want to be able to send rasters and graphic characters, > you will have to put the printer in raw mode. Unfortunately > you will lose flow control in raw mode, so you have to > slow the baud rate down to 2400 or so (and don't run > out of paper). Someone from HP suggested configuring the > printer as a *modem* ... it's on our list to try. Someone from Sun is now suggesting using LITOUT mode rather than RAW mode. The Berkeley manuals, from which the Sun manuals are derived, unfortunately don't mention that LITOUT not only turns off output translation but also turns off stripping of the 8th bit and puts the port into 8 bits, no parity mode. LITOUT mode *does* leave XON/XOFF flow control on; the tty line discipline will still do stripping of characters on input, so if the printer doesn't put out 8 bit, no parity XONs or XOFFs it should still work. This should work on most systems with 4BSD tty drivers, although there are bugs in the 4.2BSD version of the VAX serial port drivers that require you to do a TIOCSETP after doing the TIOCLSET because the drivers forget to jam the new settings into the serial port hardwire after you do the TIOCLSET. This bug is not present in SunOS 3.2 or later, and may never have been present. (L)LITOUT is in the "local mode" word; PRINTCAP(5) should say how to change flags in this word, and TTY(4) should say which bit this is. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
keithe@tekgvs.TEK.COM (Keith Ericson) (01/26/88)
< < I administrate a SUN 3/260C which is used as a PC-NFS controller < and Yellow Pages Gateway. We have several Compac 386s connected at < this time... < < Things are working out pretty well. Here's a summary of the < interesting things we have learned. < I haven't yet gotten PC-NFS to "work and play well together" with the MKS Shell, either. Anyone had any better luck? (A BSD4.3 machine is the "other end.") keith