Date: Mon, 17 Jun 1996 13:57:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kevin@NDA.COM (Kevin Lyda) Cc: dennis@etinc.com, hackers@freebsd.org Subject: Re: BSDI 2.0 vs. FreeBSD 2.x Message-ID: <199606172057.NAA08544@phaeton.artisoft.com> In-Reply-To: <199606171958.PAA26484@nda.nda.com> from "Kevin Lyda" at Jun 17, 96 03:58:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > True, however BSD is marketing themselves as an internet gateway, where > > NFS is not as important. And now that FreeBSD has a Netware compatible > > server available....the option to dump NFS (which I really dont want to use > > on my Windows workstations anyways) is more than viable. The Netware > > stuff (although not free) is a lot nicer (and faster) than NFS. > > how can you justify that? is netware an inherently faster protocol > than nfs? or is this just an implementation issue? DOS networking is based on a request/response architecture, especially for directory searches and similar operations. The DOS clients for NetWare and SMB group large amounts of directory entries in a single response, but the NFS is still one-packet-per-entry. In addition, the DOS clients do not have the concept of a "stat" sperate from a lookup. The search for "path without search characters" is converted into an iteration of the directory on the client until it gets to the entry, and then a stat (which it does for each entry, regardless). The correct method of dealing with this would be to push the DOS pattern matching into the UNIX kernel, and shove the requests over the wire to the server that was (this is how SMB and NetWare servers operate), so that the only traffic accross the domain boundry (user/kernel or network/kernel) is files which match the search criteria. The issue is exacerbated by the NFS client behavior that a search initiated by a DOS program must be "continuable" if they use a non-Win32 interface (the DOS search semantics don't have a "I'm done with this search context" indicator until Win32). At the IFS level, Win32 could provide an NFS client that was *vastly* more efficient in its use of the protocol. This has two problems: (1) You can't force poeple to use Win32 apps instead of DOS or Win16 apps if the OS allows them to be run in the first place, and (2) without the ability to provide the performance advantage to anything more than a subset of the programs, you can't make any significant marketing claims, so you might as well bail on the idea anyway. The PCNFSD, especially the Beame and Whiteside, *does* offload some of the client work + traffic onto the server as server work + less traffic, but it requires that you run it. Finally, the B&W PCNFSD is a user space daemon. For a search with stat, there is a requirement for multiple crossings of the user/kernel protection domain. This is probably a place where "UNIX did the wrong thing". You most likely want stat information for all search returns, and you want it on open, and maybe even on close. This is 50% higher call overhead than you would see from a "corrected" implementation, and 100% higher call overhead than a kernel implementation. In addition, the NetWare server will, if correctly written, support "packet burst", which is basically a fixed window multiple packet download to, or upload from, the client (up to 32k, depending on negotiated packet size). This averages one request/response latency over up to 32 packets, instead of one per packet, like te NFS -- this is a failure of the client to perfom caching and predicition on read-ahead to avoid non-interleaved I/O as a result of not sending the next read request until it has run the application program that made the last read, the application program has processed the return data, and then set up the next read to take place. So, in general, NetWare is faster to DOS clients, but it's DOS's fault, not that of the server, and much of the problem is correctable, though there's little short term economic incentive to actually do the correction. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606172057.NAA08544>