Date: Tue, 14 Nov 1995 21:34:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511150434.VAA00712@phaeton.artisoft.com> In-Reply-To: <199511150359.IAA01506@hq.icb.chel.su> from "Serge A. Babkin" at Nov 15, 95 08:59:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511150434.VAA00712>