Skip site navigation (1)Skip section navigation (2)
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>