Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!uunet!mcsun!cernvax!chx400!urz.unibas.ch!doelz From: doelz@urz.unibas.ch Newsgroups: comp.protocols.appletalk Subject: Re: MacNFS vs AppleShare Message-ID: <1990Nov13.091518.1171@urz.unibas.ch> Date: 13 Nov 90 08:15:17 GMT References: <4665@husc6.harvard.edu> <1990Nov10.100943.1166@urz.unibas.ch> <273EDDB5.40D1@intercon.com> Organization: University of Basel, Switzerland Lines: 86 In article <273EDDB5.40D1@intercon.com>, kdb@macaw.intercon.com (Kurt Baumann) writes: > In article <1990Nov10.100943.1166@urz.unibas.ch>, doelz@urz.unibas.ch writes: .. >> The drawback is that the host is bothered quite a bit. Further, the >> mac-like storage of resource and data forks makes it necessary to >> either split the files or to convert them somehow on the fly. Both >> is computationally expensive. > > First off, the host is not bothered as much as you might think. And it is > usually only "bothered" once in a while. Our software allows the use of Depends on what you say is bother. We made a micro VAX use 40% of kernel for it :-) It is strictly not true that the host is unaffected. As long as you use such a model, the host WILL have to do some work, and, depending on load, it *will* bother you quite a bit. Alternatively, you can set the resources for the appletalk to low values, but, then, the users on the apple side complain. Vice versa, your VAX turns out to be a damned expensive Mac, and cant do much else. I agree on the fact that larger processors are not that much affected, but some load will be always there. One thing which is severely to be considered are parameters like the nonpaged pool, affected by the high load of extremely small packets on the controllers. > either AppleSingle or AppleDouble formats on the remote disk, this allows you > to edit files with your favorite Mac word processor without screwing the > remote file up, yes it does create a seperate file containing the formating > information, but it only does that for those files that you actually go and Allright, and others have single/double options as well. Even, for VMS, some have the translation option to STR_LF... But then, copy a folder containing 8000 files, and the RMS needs to create 1600 files. That will take its time ! > edit. There is only one file, a desktop file, created at the outset of your > connection. This file contains the information that the Mac finder needs in > order to display the information you have come to expect on the Mac. This one file is a beast in some implementations, and needs to be accomodated with file structure, protection, etc. On VMS its not that easy. > > As far as computationaly expensive for the Mac, what do you mean? Our software > only handles file information upon initial startup and then whenever you > actually do something to the file. This is not that great of a task. The wait times for transferring a dir information in icon style is tremendous. Same applies if you empty trash etc. This is because all Macs (exceptional the fx) use their motherboard for I/O. > it would if there were an AppleShare sever out there. The GatorBox is doing > all of the work for you. Sure it might be slow at times, but that isn't > the Mac being slow. It's the Mac waiting for the GatorBox to catchup. Sorry, this is a misunderstanding, you are correct at this point. > > If the above were true, no one would ever use AppleShare for anything. > You are perfectly right. AppleShare has its limitations. The issues given above apply severely on VAXes currently (Havent seen LANWorks so far - maybe its better) but also apply for UNIX hosts to some extent. We need to admit that AppleShare was meant for PCs and that better protocols for other machines are more suited for some purposes. > -- > Kurt Baumann InterCon Systems Corporation > 703.709.9890 Creators of fine TCP/IP products > 703.709.9896 FAX for the Macintosh. My benefit is that I have the choice between DECnet, NFS, FTP, AppleTalk, LAT, and a serial line (Kermit :-) ) if I need to transfer files - and, you won't believe it - I take whatever seems to be most appropriate to me. Each of the protocols and methods has advantages, and drawbacks, so I think its fair to play most effective as needed. ************************************************************************ Dr. Reinhard Doelz * EAN doelz@urz.unibas.ch Biocomputing * DECNET 48130::doelz Biozentrum der Universitaet * X25 psi%46211142::embnet Klingelbergstrasse 70 * FAX x41 61 256760 CH 4056 Basel * TEL x41 61 253880 ext 888 ************************************************************************