humtech@ucschu.ucsc.edu (Mark Frost) (08/23/89)
In article <4YwfMBm00UoB0CA1wF@andrew.cmu.edu> tjh+@ANDREW.CMU.EDU (Tom Holodnik) writes: > > We've recently run some tests that indicated that the Chooser we're >running nearly everywhere (version 3.4, System 6.0.2) has serious >troubles handling more than 16 entries of any network entity. This >includes LaserWriters and machines running Broadcast. > > Over repeated trials, we observed that if there were 21 LaserWriters >queried, all 21 NBP replies could be seen bound for the receipient node. >Using Peek, we saw all replies coming back from the printers on the >receiving network. However, the node running Chooser didn't show all 21 >printers. We never saw more than 16 LaserWriters under Chooser. >Furthermore, running Inter*Poll, we observed no more than 1% packet >loss, so the underlying network was reliably carrying data, once the >entity had been resolved with NBP. > > Has anyone else seen this behavior? While this is a little different >than the behavior Mark Frost observed, I think that it might be the same >problem. I wish I could be more help to Mark, but perhaps someone else >from Apple could comment on the state of Chooser. > >Regards, >Tom Holodnik I just did another test and here are the results... According to CheckNet, there are 18 LaserWriter devices on our zone (11 CAP LaserWriter Spoolers, 7 LaserWriters). When I go into Chooser (we use version 3.3.1 - this is what we get with System 6.0.3; I've never seen version 3.4) on my IICX I am never able to see more than 13 devices. Some of the devices never show up even if I wait for a while. The "missing" devices are both spoolers and "real" laserwriters with no apparent relation. Mark Frost Office of the the Computing Coordinator Humanities Division University of California at Santa Cruz (408) 429-4603 Internet: humtech@ucschu.UCSC.EDU Bitnet: humtech@ucschu.bitnet Uucp: ...!ucbvax!ucscc!ucschu!humtech
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (08/24/89)
In article <10508@claris.com> peirce@claris.com (Michael Peirce) writes: >In article <13321.619876292@GNOME.CS.CMU.EDU> Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) writes: >>Chooser has a (in my opinion) extremely bad implementation in terms of >>finding services on fully populated networks. While Chooser shouldn't have >>any problems with 12 hosts, it certainly can't deal with more than about 25. >> >I REALLY hope that Apple upgrades the Chooser in system 7. I've got an >application that's used by almost everyone here at Claris. It registers >an NBP name at boot time. We've got sometimes 40 or 50 names registered >[remainder of problem description deleted] >Knowing what I know now, I wouldn't have relied on the Chooser to do my >connecting. It works fine for small configurations, but just isn't >usable in large, dense networks... > Granted, AppleTalk and its appendages were not envisioned to handle more than a few machines in a local environment at reasonable (<1Mb/s) speeds. However, one thing that (IMHO) MUST NOT BE FORGOTTEN is that it works remarkably well (and SIMPLY) for those who do not have the extensive network/high speed requirements of the writers above. What I'm getting at here is this: I hope that Apple DOES NOT "improve" the Chooser. For me, it works just fine the way it is (for now). What I would hope they would to is offer an ALTERNATIVE to the Chooser to address the problems mentioned above. This alternative may require more memory, more processor cycles, more configuration by the user, etc., etc., etc., in order to be able to provide the additional service that these people need. But, back to my original point: Let ME (the user) choose which of these solutions I need. While I'm at it, I think that this approach should be used for alot of the pieces of the System. With System 7.0, it's almost as bad as OS/2 (needs gobs of memory just to LOAD!). For those who NEED the features of System 7.0, this is OK -- they can probably afford the memory. WHAT ABOUT THE REST OF US? OK, I'm done now...... M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <1468@ncrcce.StPaul.NCR.COM>, pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) writes: > I hope that Apple DOES NOT "improve" the > Chooser. For me, it works just fine the way it is (for now). One thing that I think some of us are looking for is not so much any changes in the user interface (which is a separate issue), but changes in the code to help it cope better with large networks, much along the lines of adding zone support a while back. Users on small networks wouldn't see any difference, and the growing numbers of users on larger networks would be much happier... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) (08/24/89)
>From: ncrlnk!ncrcce!pasek@uunet.uu.net (Michael A. Pasek) >Subject: Re: Chooser/atis registration problem? > >Granted, AppleTalk and its appendages were not envisioned to handle more than >a few machines in a local environment at reasonable (<1Mb/s) speeds. However, >one thing that (IMHO) MUST NOT BE FORGOTTEN is that it works remarkably well >(and SIMPLY) for those who do not have the extensive network/high speed >requirements of the writers above. The bug/feature we have all been attesting to has nothing to do with the speed of the network, and very little to do with an extensive network. The basic problem is that Chooser has some artificial limits that result in non-intuitive behavior. If Chooser only allocates 512 bytes for its name buffer, then bumping that to 2K bytes should help everyone, and I can't imagine very many systems where you don't have 2K around when you are running chooser. In any case, Chooser should try and grab a bigger buffer, and ask for less *only* if it can't have the big chunk. A 512 byte bufer might be needed on a 512K Mac, but it really is a shame when someone is too worried about bytes to see the user interface/functionality ramifications. I don't think anything I suggested was ripping on AppleTalk and its wonderful capability to "plug-and-play". I happen to like AppleTalk. I don't like sloppy programming :-) . Rob