Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!intercon!news From: kdb@macaw.intercon.com (Kurt Baumann) Newsgroups: comp.protocols.appletalk Subject: Re: MacNFS vs AppleShare Message-ID: <274043EF.4F0E@intercon.com> Date: 13 Nov 90 19:05:19 GMT References: <4665@husc6.harvard.edu> <1990Nov10.100943.1166@urz.unibas.ch> <273EDDB5.40D1@intercon.com> <1990Nov13.091518.1171@urz.unibas.ch> Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: kdb@macaw.intercon.com (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Lines: 107 In article <1990Nov13.091518.1171@urz.unibas.ch>, doelz@urz.unibas.ch writes: > 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. > If your micro VAX is doing NFS for anyone else then you are adding no more than more users to your system. I don't think that you will be affected by a high load of small packets, as we send 8K packets, most of the time (dependant upon gateways, etc.). We are not using AppleTalk, unless you are talking about AppleTalk encapsulation of IP. This is why NFS and TCP/IP are better in this situation than AppleShare and AppleTalk. Let's use those standards that are already out there and running on most machines. You are correct in stating that it is not strictly true that the host will not be affected to some degree. The point I should have made was that if you are already using your host for NFS, adding Macs using NFS does not really bog the host down any more than it would be if you added more SUN users. On the other hand if you added AppleShare to your VMS or UNIX machine and you also had NFS running on it, yes you would experience an additional load to your host. Thats why we feel that in mixed environments you should use NFS on the Mac instead of AppleShare, it just makes more sense to us. > > 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 ! > This is the whole point of what I was trying to say. We only create two files for text files, and only when they are edited from the Mac. You are not really copying 16000 files if you have 8000. We don't go out and create a new file for every file on the disk, only those that you need to be doing something with. And if it is a file that you are only going to be using on the Mac, and not messing with from another system, then you can create it as an AppleSingle, so it is one file. So I agree, if we went out and created another file for every file on the system that we were going to look at then yes, you would have a point here. But that is not what happens with our NFS product, perhaps some implementations of AppleShare do this... > > 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. > How is this handled with a UNIX to VMS NFS connection currently? You need no more than that. The Mac specific information is all that goes in here. With AppleShare you have more to do. Not that it is easy with NFS mind you. > > > > 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. > Minimal the way we do it. > > > > 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. > Right you are. AppleShare is for PC type machines, and should be put onto UNIX/VMS/etc.. That is why we are offering an NFS client for the Mac. Hope this is helpful to everyone. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.