Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans Subject: Re: How would *you* upgrade this network? Keywords: ethernet, FDDI, Proteon, TCP/IP, Bridge, Sun Message-ID: Date: 6 Oct 88 02:19:12 GMT References: <281@fed.FRB.GOV> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 63 To: rcd@fed.frb.gov First, you would need far more than 240 terminal users before the traffic from your terminal servers becomes a bandwidth issue. So I wouldn't worry about where your terminal servers are. The obvious first place to attack is your diskless workstations. I would avoid putting more than 30 or so on one Ethernet, though it depends upon how much memory they have, what sort of applications they run, etc. So the idea is to put them in clusters separated from the rest of the network by at least a bridge, if not a router. Assuming you're using Unix sytems as file servers, the cheapest way to do this is to add an Ethernet card to your file server. Then you create a subnet just for the clients of one or more file servers, and use one of the file servers to gateway to the main Ethernet. I don't much like this, because I don't really think Unix software is quite optimal for acting as a gateway, but maybe I'm spoiled. I'd still split things into groups of a few dozen machines with their file servers, but use a real router (e.g. cisco or Proteon) to connect to a backbone Ethernet. It's likely to be less expensive to put your diskless clusters on separate subnets than to go to local disks on everything. It's also likely to be easier to administer. (Do you *really* want to have to worry about corrupted file systems due to a power failure on every one of your workstations?) Also, you should take a look at broadcast rates on your networks. You've got a big network using only bridges. Since you have a limited number of vendors, and probably one group responsible for maintaining the stuff, this may be OK, but you're beginning to be near the upper bound of the size network I'd construct without some real routers to keep the broadcast traffic confined. Make sure you don't run rwhod or anything else that routinely broadcasts. Beyond this, your ability to gain bandwidth depends upon how well you can predict who talks to whom. If you can predict that certain groups talk only to certain other groups, then you can try to keep them on a single Ethernet, and use bridges or routers to isolate the groups. The fact that everybody wants to talk to the mainframe may not alone sink you. It's unlikely that any NFS implementation is going to be able to deliver more than the a few Mbits/sec. No matter how many people might potentially want to use your mainframe data, I'll bet you won't overrun an Ethernet. However you will certainly want to be careful how you arrange things so that not much else is going on with that Ethernet. If the mainframe is the main resource that every department is using, then put it directly on your highest level backbone. My intuition is that with some careful thought you can probably survive using just Ethernet technology, by moving some cables around and adding a few bridges or routers at critical locations. You don't have any supercomputers or interactive 24-bit network graphics, so my intuition is that you should be able to survive without FDDI bandwidths for the moment. I understand that you'd feel safer with bridges that could handle most of the bandwidth of an Ethernet. On the other hand, if they can really handle 20 to 30%, that may well be good enough. The whole point of a bridge is to increase overall capacity by separating local and non-local traffic. You'd hope that even on a 100% loaded Ethernet, no more than 20 to 30% of the traffic would be going to destinations off the Ethernet. I'm betting it's going to be about a year before FDDI is practical except for the adventuresome, and it's going to be very expensive at the start.