ugogan@ecsvax.uncecs.edu (Jim Gogan) (11/16/88)
A question about PhoneNet Passive Star topology:
I'd like to know what the most number of branches people have gotten
to work in a passive star, without having to go to a star
controller. (Yeah, I know the documentation says "six branches";
what I want to know is what REALLY works!) In the instance we're
looking at, each branch/trunk would go to one and only one Mac
(except for one or two offices with a LaserWriter daisy-chained off
that Mac).
Also, have gotten conflicting info about termination in the passive
star. One source has told me to terminate all branches; another
source (and the PhoneNet documentation) says to terminate only the
four longest branches. What works best? Thanks in advance.
-- Jim Gogan (ugogan@ecsvax.uncecs.edu)
Univ. of North Carolina at Chapel Hill
--
Jim Gogan mail:ugogan@ecsvax (UUCP/BITNET)
Microcomputing Support Center
University of North Carolina at Chapel Hill
Chapel Hill, NC 27599wnn@DSUNX1.DSRD.ORNL.GOV (W. N. Naegeli) (11/18/88)
In my experience there is no way to predict precisely what will work in terms of outlandish LocalTalk/PhoneNet topologies. Certainly, the recommendations about a maximum of four long and two short branches in a passive star are fairly conservative. It depends on the type of cabling you use, i.e. its gauge and shielding -- don't use shielded cable, except if you pass by a microwave source, etc. (shielding reduces the reach by about 30 %) -- but if you run the cable through a metal pipe you may get some degree of incidental shielding; the effective total length of the network (which is affected by gauge, shielding, and termination) as well as the star pattern (often each branch has a different lenght); sources of reflections, particularly un- terminated branches, connections between branches, contacts in the attached drop cables and daisy chaines -- don't cut the wires at the hub of the star, run them from the end of one branch through the hub and out to the end of another branch, strip the isolation at the hub and solder the loops together; the attached devices themselves, e.g. their sensitivity for detecting the incoming signals and for distinguishing it from noise, and the strength of their output signals and the amount of noise that they put on the network -- there are differences for example between the various AppleTalk boards for PCs and PostScript printers (we have lots of trouble with the NEC SilentWriter for example); and finally termination, which seems to be more an art than a science, unless you have very fancy instruments to watch signal propagation on your network. Some people say you should have no more than four terminating resistors, others say five. We have some particularly troublesome network segment that was supposed to be a trunk topology, but the electricians cut corners and in effect installed a multi-passive-star topology. We use two 120 Ohm terminating resistors at the far ends of the longest branches and TuboNet ST (self terminating) connectors at several of the longer remaining branches and at all printers, which tend to be noisier than the Macs. Nuvo Tech claims that you don't have to bother with termination if you use the TurboNet ST, but we have found that in more complex networks the termination it provides is insufficient. I have not measured how much it will privide at the maximum, but it must be less than 120 Ohms. However placing these connectors in places where a 120 Ohm resistor would be too much, they seem to be beneficial since they provide a variable amount of resistance that is dynamically adjusted to prevailing condition. Many things work that are not mentioned in the "book." For example, we have one network using LocalTalk cabling with over 40 nodes (rather than the maximum 32 according to Apple) and it works fine though it is overloaded and slow. However, if you have a marginal network, simply adding or removin one device or even turning one on or off can cause problems for one or more other users, and it can often be very difficult to distinguis such problems from software bugs or software incompatibilities. Wolfgang N. Naegeli Oak Ridge National Laboratory 615-574-6143