Date: Mon, 17 Jun 1996 18:13:07 -0400 From: dennis@etinc.com (Dennis) To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: BSDI 2.0 vs. FreeBSD 2.x Message-ID: <199606172213.SAA01955@etinc.com>
next 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. Ok....I'll buy that. :-) Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606172213.SAA01955>