From owner-freebsd-current Tue Nov 14 20:36:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09146 for current-outgoing; Tue, 14 Nov 1995 20:36:51 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09138 for ; Tue, 14 Nov 1995 20:36:49 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA00712; Tue, 14 Nov 1995 21:34:53 -0700 From: Terry Lambert Message-Id: <199511150434.VAA00712@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Tue, 14 Nov 1995 21:34:53 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG In-Reply-To: <199511150359.IAA01506@hq.icb.chel.su> from "Serge A. Babkin" at Nov 15, 95 08:59:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3516 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I was thinking more in terms of an "email database". It wants the write > > guarantees to be honored so the locking protocol functions correctly. > > The closing of file may be used as an implicit "sync" request for this file, > IMHO it should help for UUCP-like locking. > Or if they use fsync() it is an explicit request to "sync" the file. Are > there some other locking methods ? Well, NFS lockd, for one. > > The other being lack of long file name support and DOS's inability to > > operate multiple I/O instances and/or drives as multiple session > > instances and issue async requests. > > Async requests need more buffers and the main DOS idea is "save this 1K > or die". Tell that to Novell; they do client caching. 8-). > > DOS has the same problem with NetWare or SMB, both of which are > > request/response in nature. Another request can't be issued until the > > previous one is satisfied. NetWare has fixed windows for binary downloads > > ("packet burst") to partly alleviate the problem in trade for congesting > > the bejesus out of your network in certain circumstances. > > But the syncronous writes in NFS makes wery big overhead. The write throughput > for DOS and different networking systems is like (on empty network): > > Netware - about 700 K/s (may be Netware client has more buffers ? but it takes > less of memory than NFS client) Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed window, needs an ack every burst run. > BSDI NFS - about 300K/s > HP/UX 9.04 NFS - about 200K/s > SCO NFS - about 80K/s > FreeBSD NFS - about 12K/s One wonders what BSDI does... maybe implements pcnfsd in kernel code? > FreeBSD immediately writes every block it gets from DOS and reports about it > only after write is completed. Yep. File-based IPC won't work any other way. Consider a print job that you cause the file to be deleted after it's put in the queue -- a lot of email systems, like CC:Mail, do this. > > OS/2 fixes this by using seperate sessions. As does NT and Windows95. > > I think I've seen a Win3.1 client that did this as well. > > Most of time Windows has only one active task with which the user works, > all other tasks are often just waiting until the user switches to them. > So the problem is the same as in DOS, although, obviously it is not so big. > > > The easy answer is: don't use DOS, it sucks. > > Yes :-( But the numbers above is one of reasons why people are using Netware, > not NFS. Well, these figures were current as of last year... You can license NUC (NetWare UNIX Client) source code for $100,000. You can license NWU (NetWare 4.x for UNIX Server) source code for $150,000. Or you can license both + UnixWare source code for $250,000 (hmmmm... I wonder what value UNIX source code has... $250,000 - $150,000 - $100,000. 8-) 8-)). With IPX stack latency corrected (mostly an artifact of the Streams implementation on UnixWare), NWU will outperform Native NetWare on identical hardware. By as much as 30%. > > I think the issue was multple news reader processes and I/O being > > bottlenecked by requestst being queued for too few service engines. > > OK, sorry... The low DOS+NFS performance is one of my problems and I ask > about it when I see something about NFS performance. :-) Change the PCNFS server, and if possible, the PCNFS client. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.