HDTenEightyP/NetNews huggingface dataset:
From: brad@Cayman.COM (Brad Parker)
Newsgroups: comp.protocols.ppp
Subject: Re: Is the PPP driver for 386BDS ready
Date: 23 Jul 92 20:51:56 GMT
Organization: Cayman Systems Inc., Cambridge, MA
In-reply-to: briana@sharebase.com's message of 22 Jul 92 22:15:19 GMT

In article <1992Jul22.221519.7739@sharebase.com> briana@sharebase.com (Brian G. Anderson </>) writes:

   I would like to get a copy of the PPP driver for the BSD NET2 (386BSD)
   kernel.  I saw a message fly by about 2-3 weeks ago about someone working
   on this.

Look on ftp.cayman.com.  I ported the PD PPP to 386BSD and made a few 
(very minor) enhancements.  It ran ok under v0.0 (but, the com drivers
have problems). I just got v0.1 up but have not installed PPP yet. 
It should work fine, however.

Also note that Morningstar has a supported version for BSDI's BSD/386.
We use there sparc versions (and like them a lot).

-brad
--
A metaphor is like a simile.

Brad Parker	Cayman Systems, Inc., Cambridge, Ma.	brad@cayman.com
Newsgroups: comp.protocols.ppp
Subject: Using CUTCP over SLIP
From: <PVJQC@CUNYVM.BITNET>
Date: Thursday, 30 Jul 1992 12:03:32 EDT
Organization: City University of New York/ University Computer Center

Hi,
I have CUTCP telnet/ftp running on our PCs-PS/2s in the dept with lot of
Suns and NeXTs, etc.  I recently configured public-domain SLIP on the
Sun sparcstn and now wish to dial into the sparcstn from PCs at home
using SLIP.  I seem to have the driver called SLIP8250.com which
I downloaded sometime back.  I do not know how to make use of it
to configure CUTCP to go over serial-line (dialout over the phone to the
Sparcstn with SLIP).  Does any one have any suggestions? Or is my
question an absurd one?
Thanks a lot.
Prashant
-------

         *********************************************************
         *  PRASHANT V. JOSHI                                    *
         *  COMPUTER SCIENCE DEPARTMENT                          *
         *  CITY UNIVERSITY OF NEW YORK.                         *
         *  INTERNET ADDRESS: PVJQC@CUNYVM.CUNY.EDU,             *
         *  BITNET ADDRESS  : PRASHANT@QCVAX.BITNET              *
         *                                                       *
         *********************************************************
From: briana@sharebase.com (Brian G. Anderson </>)
Newsgroups: comp.protocols.ppp
Subject: Is the PPP driver for 386BDS ready
Date: 22 Jul 92 22:15:19 GMT
Organization: ShareBase Corporation

I would like to get a copy of the PPP driver for the BSD NET2 (386BSD)
kernel.  I saw a message fly by about 2-3 weeks ago about someone working
on this.  What's the status? Is it available?  I looked at MorningStar's
ppp driver for BSD4.3, but it seems quite different then their Sun
driver: no VJ compression, no statistics.



-- 
Brian G. Anderson          -      o    Internet: briana@sharebase.com
NCR/Sharebase             -    _ /-_      Voice: (510) 548-3211
1919 Addison St.         -    (_)>(_)
Berkeley, CA 94704      -----------------------------------------------------
Newsgroups: comp.protocols.ppp
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: Is the PPP driver for 386BDS ready
Organization: Morning Star Technologies
Date: Thu, 23 Jul 1992 02:28:58 GMT

In article <1992Jul22.221519.7739@sharebase.com> briana@sharebase.com (Brian G. Anderson </>) writes:
   I looked at MorningStar's ppp driver for BSD4.3, but it seems quite
   different then their Sun driver: no VJ compression, no statistics.

Huh?  Our BSDI PPP daemon is built from the same sources as all the
rest, and provides the same features.  After a port is done, we don't
want to do anything more complicated with Yet Another Unix Box than to
say rdist and make.
From: dale@cec1.wustl.edu (Dale Frye)
Newsgroups: comp.protocols.nfs
Subject: Re: Network license managers with PC-NFS
Keywords: license managers PC-NFS
Date: 30 Jul 92 15:32:55 GMT
Organization: Washington University, St. Louis Mo.

In article <hz01930.712245204@cygnus> hz01930@hx.deere.com (Jay D. Anderson) writes:
>We would like to use PC-NFS to provide access to applications for our PC network.  Certainly some one is doing this already, but how is license management being handled?  Are there license manager programs available to use under PC-NFS?
>


We don't practice control but do track when software is being used. We could
easily start control if needed. We do this using batch files (for DOS programs)
and batch runner (from Norton) files (for Windows Apps). We use a specially 
mounted partition that had perms for write only for anyone. The batch files
append logging data to the end of a logging file for each machine.

Dale Frye
Newsgroups: comp.protocols.nfs
From: kurz.1@ipa.fhg.de (Hermann Kurz)
Subject: Problems with NFS-server on VMS
Organization: IPA Stuttgart
Date: Fri, 24 Jul 1992 08:17:34 GMT

Hello,

i have problems getting acces to a NFS-Server on a VMS machine. The client
software is Interdrive.
The problem is: if i try to mount a file system my client tells me:
"Authentication server failed to respond, filesystem not mounted"
if i change the user to "nobody" the error message is:
"ERROR: RPC Authentication Error, filesystem not mounted"

NFS$SERVER is running, so - what am i doing wrong ???

thanks for any help
-----
ern
Xref: sparky comp.protocols.nfs:1924 comp.sys.sun.hardware:3479
From: hz01930@hx.deere.com (Jay D. Anderson)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: Network license managers with PC-NFS
Summary: Application license managing using PC-NFS, availability, experiences?
Keywords: license managers PC-NFS
Date: 27 Jul 92 13:53:24 GMT
Followup-To: comp.protocols.nfs

We would like to use PC-NFS to provide access to applications for our PC network.  Certainly some one is doing this already, but how is license management being handled?  Are there license manager programs available to use under PC-NFS?

Thank you.


--

         / 
        /   ___ /   /   /
       /   __  /   /   / Jay D. Anderson	hz01930@hx.deere.com
  /   /   /   /   /   / John Deere Harvester	...uunet!deere!cygnus!hz01930
_____/  _____/  ___  / 1100 13th Avenue		(309)765-6063
                    / E. Moline, Illinois 61244
                   /
             _____/
Newsgroups: comp.protocols.nfs
From: jim@kn5f.jsc.nasa.gov
Subject: NFS service for dissimilar file structures
Organization: EIC
Distribution: usa
Date: Thu, 30 Jul 1992 16:54:45 GMT

I would like to hear from anyone with experience in mounting an NFS server from
platforms with different OSs like VMS, MVS, Macintosh, Unix, etc. These OSs all
have different file structures and I would like to know if it is possible to
share text files across all these platforms via NFS. Since it involves several
NFS client products and since the client is responsible for interpreting the
data from the server, I am concerned that a given client won't recognize the
file structure that another client placed on the server. 
Also, do all NFS servers/clients create a separate attributes file and are they
compatible with each other?

Thanks, 
Jim Dickerson  
Xref: sparky comp.protocols.nfs:1973 comp.protocols.tcp-ip.ibmpc:4513
From: kjw@doc.ic.ac.uk (Kevin J Walters)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: PC-NFS 4.0, RTM, Heap size
Date: 30 Jul 92 14:33:20 GMT
Organization: Dept. of Computing, Imperial College, University of London, UK.


There are quite a few computers i've come across which are loading rtm
with the parameter '/heap 64'. I had a look in the manuals and found 
the value to be 64k, as i suspected, so basically rtm is using up 64k
plus the resident portion of that oh-so-precious ram.

The manual gives a defualt of 22k if the heap option isn't specified - is
there any reason for a heap as large as 64k?

I suspect it all comes down to efficiency, but there must be a more
reasonable balance between memory use and nfs performance.


|<evin

-- 
Kevin J. Walters           Dept of Computing, Imperial College, London SW7 2BZ
kjw@doc.ic.ac.uk           Sysop of The Spooky Ghost BBS 2:250/403.0@fidonet
kjw@icdoc.uucp             Data : 0245-494010 V21,V22,V22bis,V23
(kjw01@cc.ic.ac.uk)        Voice: 071-589-5111 Extn 4900
Xref: sparky comp.protocols.nfs:1949 comp.sys.sun.hardware:3536
From: wai@csuvax1.csu.murdoch.edu.au (Julian Wai)
Subject: RPC/XDR
Organization: Murdoch University
Date: Mon, 27 Jul 92 07:00:14 GMT

Hi,

Does anyone have any references to Remote Procedur Call and eXternal Data Representation?  Please email to me, Any information will be appreciated.

Thanks in advance.

Julian
wai@csuvax1.csu.murdoch.edu.au
Newsgroups: comp.protocols.nfs
From: per@teknologi.agderforskning.no (Per Sigmond)
Subject: Keyboard-mapping with PC-NFS 4.0
Organization: Agderforskning
Date: Thu, 30 Jul 1992 07:03:16 GMT

Sun have changed their telnet-implementation from 3.5 to 4.0 versions, and the
method for keyboard-mapping and character-translation changed with it. I have
found out that the mapout-command does character-translation, but how do I map
certain characters to be sent from certain keys? (I know about the altkey-command
but it doesn't quite do the job.)

Thanks. Per.
-- 
Per Sigmond
Agderforskning Teknologi
Televeien 1
4890 Grimstad
Norway

Internet: Per.Sigmond@teknologi.agderforskning.no
From: curt@ekhadafi.austin.ibm.com (Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806)
Newsgroups: comp.protocols.nfs
Subject: Re: lockd
Date: 26 Jul 92 04:21:58 GMT
Organization: IBM AWD, Austin

In article <1992Jul21.174721.26888@nntpd.lkg.dec.com> uresh@ovrbid.lkg.dec.com (Uresh Vahalia) writes:
>
>I have a few questions about the lockd protocol, which I am trying to
>implement:
>
>1.  There seem to be 3 flavors of each request - eg. for the lock
>request, there is 
>    nlm_lock, nlm_lock_msg and nlm_lock_res.  Why?  What are the differences?
nlm_lock is not used in my experience
nlm_lock_msgs says, "hey server, can i have this lock?"
	the rpc reply may say block, yes ,no, whatever
	if it says blocked, then later, when it is available, you'll get
	a ...
nlm_lock_res, which means "result", which will say granted

>2.  What are the version 3 requests for (share, unshare, nm_lock and free_all?)

PCNFS, which has no statd, and there fore no way to get informed when
the server reboots.

>3.  What is the function of the cookie argument in all the calls?

sort of like a filehandle in regular NFS, but instead  you might call it
a "lock handle"  or better yet a "request handle".  the RPC XID isn't good
enough since it can change after multiple retries and since the nlm_....RES
will came back for sure on a different XID.

>4.  What does the svid argument mean?

server id?

>
>Can anyone point me to any document which gives me a high level description of
>the protocol (besides just the uncommented spec?).

the code is all you get as far as i know
and it ain't much help
not well doc'd

sniffers or snoop on suns or iptrace/ipreport on AIX are your only help
really for figuring all this out.  you just have to watch the transactions
and try to guess what's going on w/ code in hand

p.s.  don't ever try to write your own lockd.  buy the code.


-- 

curt@aixwiz.austin.ibm.com (Curt L. Finch) | AIX NFS/NIS Field Quality 
My views are unrelated to those of IBM     |        Austin, TX
 There'll be too many elderly in 30 years for your kids to afford all the FICA.
Newsgroups: comp.protocols.nfs
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: what locking techniques work over NFS?
Keywords: file locking
Organization: Twin Sun, Inc
Date: Fri, 31 Jul 1992 00:39:03 GMT

rod@philips.oz.au (Rod Roberts) writes:

>which of the following file locking techniques work with multiple hosts
>accessing the same filesystem over NFS.

>1. lockf()  (System V)
This works only if lockd works.  lockd's bugs are legendary.

>2. flock()  (BSD)
This isn't even advertised to work.

>3. link()   (generic) fails if new link already exists
This doesn't always work.  E.g. suppose a client finishes an operation
and unlocks by issuing an unlink request, and suppose the unlink
executes on the server, but the response is lost.  Eventually the
client will retry the unlink request, and (assuming the idempotency cache
overflows) the server will unlink the file again -- even if someone
else has linked it in the meantime and is in the middle of an operation.

>4. create() (generic) fails if file exists and caller does no have write
>             permission
This doesn't always work, using a scenario similar to the above.
Also, watch out if you're `root'.

>5. open()   (POSIX) fails if O_CREAT and O_EXCL flags are present an the file
>             exists.
This doesn't work; NFS has no notion of O_EXCL.


They don't call it ``Not a File System'' for nothing.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Date: 27 Jul 92 15:16:24 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <JIM.92Jul27122141@hunter.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
> In article <noe56po@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
>    An NFS server or client on FDDI is intrinsically faster than a similar
>    machine over ethernet.  This is because it takes significantly fewer
>    host cycles to generate 1 or 2 UDP/IP datagrams for a 4K or 8K read or
>    write than to generate 3 or 6.  
> 
> Yes, but..... 
> 
> 4K or 8K reads and writes tend not to be the most commonly used NFS
> operations. Typically, 70-80% of the NFS requests will be lookups and
> getattrs. These generate itty-bitty packets - 2-300 bytes or so -
> which will fit quite comfortably in the maximum packet "frame" for
> just about any network. Therefore, fragmentation of NFS requests is No
> Big Deal.
> 
> While what you say is true, the benefits of lower protocol processing
> are negligible. This maybe saves 1000 instructions or so (a whole 30
> microseconds of CPU on the average workstation these days) for perhaps
> 20% of the server's NFS operations. I suspect that this will be lost
> in the noise when compared with the CPU overhead of actually servicing
> the NFS request and/or waiting for the disk.
> 
> 		Jim


Well, you're right about the effects of the mix.  However, you're wrong
about the potential of saving only 1000 instructions.

If 
     -your system uses 4KByte pages, 
     -if your NFS implementation happens to use 4K blocks,
     -if your file system happens to like to use 4K buffers,
and  -if your FDDI hardware handles UDP checksums,
then you can avoid around 1024 cache-missing loads and stores by using
"page flipping".  That is the equivalent of 10,000 to 100,000
instructions per packet.  (The cache miss penalty for an R4K at
50/100MHz is awesome.)

I also don't think saving 1000 instructions is anything to sneeze at.
Saving 1000 instructions would produce a large speed up in SGI NFS
server.  (We don't yet page-flip.)  Also, remember that 1000
instructions is not necessarly even close to 30 usec even at 33 MHz,
unless your primary instruction cache is very large.


Vernon Schryver,  vjs@sgi.com
From: ycrdi@world.std.com (Young Chang)
Newsgroups: comp.protocols.nfs
Subject: NFS Server for Mac:  Helios?
Date: 29 Jul 92 19:23:17 GMT
Organization: The World Public Access UNIX, Brookline, MA

Hi, all!  I'm looking for an NFS server that'll run under MacOS 7.x.
Someone here mentioned a company called Helios, and said that they make
such a product.  However, he didn't have any other info on them.

Has anyone else heard of Helios?  Is this true that thay make the product
I'm looking for?  How can I get in touch with them to get more info?

Please use Email if at all possible.

Thanks!
-TimK
--NetMan
--
Tim King / Network Manager
Young Chang R&D Institute
ycrdi@world.std.com
timk@world.std.com
-- 
Young Chang R&D Institute                       Makers  of         <>
ycrdi@world.std.com                   |\   Kurzweil Music Systems  | >
Voice: (617) 890-2929                 | >        Technology        |/
  Fax: (617) 890-2014                <>
Newsgroups: comp.protocols.nfs
From: fwp@CC.MsState.Edu (Frank Peters)
Subject: Re: NFS I/O Ops/seconds
Organization: Computing Center, Mississippi State University
Distribution: usa
Date: Wed, 22 Jul 1992 18:47:38 GMT

In article <64081@hydra.gatech.EDU> gt1111a@prism.gatech.EDU (Vincent Fox) says:
: In <1992Jul22.061146.15641@u.washington.edu> kint@rio.engr.washington.edu (Rick Kint) writes:
: >	We're buying a Sun to serve as an NFS server in one of our departments.
: >The Sun rep commented that a typical Ethernet allows 300 NFS ops per second,
: >so if you're on a single wire any server bandwidth beyond that is wasted. 
: 
: Hmmm. I'm a bit skeptical. All NFS operations are not created equal.
: A write obviously takes a lot longer to complete than a getattr. I've seen
: claims up to 1,000 or better. Auspex claims this I feel certain.

Keep in mind that the 300 NFS ops per second refers to the number of
operations for a single ethernet wire.  Given a fairly usual mix of
reads, writes, getattrs and lookups this is indeed a reasonable rough
estimate of a maximum.

If you run on a network with a higher bandwidth than ethernet then that
maximum will be higher.

If you have a server that will do 1,000 NFS ops/second and it is
driving machines on four different ethernets then it can do more than
300 ops...but not on any one segment.

So the significance of a such NFS limitations depends very much upon
the nature and topology of your network.
--
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: fwp@CC.MsState.Edu  -  Phone: (601)325-7030  -  FAX: (601)325-8921
Xref: sparky comp.protocols.nfs:1948 comp.sys.sun.hardware:3533
From: mfineman@cadev5.intel.com ( Mark S. Fineman )
Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
Subject: Re: NFS I/O Ops/seconds
Date: 24 Jul 92 22:25:44 GMT
Reply-To: mfineman@cadev5.UUCP ( Mark S. Fineman )
Organization: Intel Corporation, Santa Clara, CA

In article <l6r4uvINNf0p@exodus.Eng.Sun.COM> beepy@tabitha.Eng.Sun.COM (Brian Pawlowski) writes:
>...
>The number "300 NFS ops/s per ether" is a rule-of-thumb
>(that's not quite the right word) maximum NFS ops/s as
>generated by nhfsstone (Legato) or PRE-LADDIS (SPEC)
>benchmark. I'll assume an equivalence of "NFS ops/s"
>and "NFS I/O ops/s". [Is there a difference?]

From what I've heard from various people at various vendors of
file servers the PRE-LADDIS OP/S are about 2 times the
nhfsstone OP/S for equivalent mixes.

 150 or so would be fair for nhfsstone,
 300 or so would be fair for PRE-LADDIS.

 340 using PRE-LADDIS and the equivalent mix to the default
 mix in nhfsstone would be pretty good.  I don't think
 you could get 340 using nhfssone and that mix.

I haven't looked at the PRE-LADDIS stuff in detail so I
can't say why the 2x difference.
>
(408) 765-4277; MS SC3-36, 2220 Mission College Blvd.,
P.O. Box 58119, Santa Clara, CA 95052-8119
 mfineman@scdt.intel.com
From: numb@root.co.uk (Matthew Newman)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Date: 24 Jul 92 09:22:11 GMT
Organization: UniSoft Ltd., London, England
X-Address: Spa House, Chapel Pl, Rivington St, London EC2A 3DQ
X-Organisation: UniSoft Ltd
X-Quote: To imagine is everything. - Albert Einstein
X-Job: Systems Engineer
X-Phone: +44 71 729 3773 x215, Fax: +44 71 729 3273

In <nkok0p0@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <l6r4uvINNf0p@exodus.Eng.Sun.COM>, beepy@tabitha.Eng.Sun.COM (Brian Pawlowski) writes:
>> The number "300 NFS ops/s per ether" is a rule-of-thumb
>Yes, everyone keeps saying, for ethernet.
>One can hope to do significantly better on FDDI.
>Imagine a multi-homed FDDI NFS server (>1 FDDI link), with FDDI-to-ether
>routers or bridges that can run at ethernet speeds.
This is misleading, there are two different issues here:-

1)	Number of NFS ops to saturate the Ethernet/FDDI

2)      Max number of NFS ops a given client/server arrangement
	can achieve on a given network.

In some fairly detailed tests on our FDDI network and our departmental
Ether, we found little increase in NFS ops over FDDI as the
clients/server/disks were the bottleneck, not the network.

FDDI has a higher bandwidth and therefore can support more simultaneous
NFS servers at full speed, but in practice each server/client is
not any faster.
-- 

Matt Newman
From: raj@cup.hp.com (Rick Jones)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Date: 24 Jul 92 17:07:35 GMT
Article-I.D.: cup.BrwKwn.4nD
Distribution: usa
Organization: The Place Where Packets Go To Die
X-Newsreader: Tin 1.1 PL4

coolidge@speaker.wpd.sgi.com (Don Coolidge) writes:
: Seems like some summary is in order.
: 
: 2) Sun (among others) has from time to time reported very
: high IOPS numbers by changing the mix to have even fewer reads
: and writes. This is not dishonest...it just means that the
: reporting requirements for the test should make some mention
: of the mix.
: 

My understanding is that the number of reads and writes remained the same,
just that the sizes are changed. This is particularly true if you try to
make comparisons between nhfsstone 1.22 (which I beleive was the last  of
the nhfsstones that was supposed to be distributed) and nhfstone 2.0.X.
(which really wasn't supposed to be distributed, but does get quoted by some 
folks...)

: 4) LADDIS reccommends adding another Ethernet for every 200 IOPS.
: 
: 5) However, that's not really necessary...our own tests have shown
: that nhfsstones are at least as client-bound as they are server-bound
: and media-bound. We've seen well over 400 IOPS over a single Ethernet
: using nhfsstones with the default mix and with UDP checksumming
: enabled, between a Crimson server and a single Crimson client. We
: also see well over 500 IOPS with the same setup, but with two
: Crimson clients on the single Ethernet. Multiple Ethernets
: give an additional boost. So does use of FDDI instead of Ethernet
: (a big boost).
: 

400 and 500 IOPS on a single Ethernet? Neat. I suppose that was nhfsstone
2.0.X, or were there modifications to the benchmark (read/write) sizes?
Or were all the volumes mounted "private"?  

: 6) To be able to make reasonable NFS performance comparisons, I
: think that at least the following need to be specified in the
: performance report (there may well be more; this is just off the
: top of my head):
: 
:...
: LADDIS is supposed to allow us to compare apples and apples. But it
: seems to have gotten a tad too political to do so, as many of the
: items I mentioned above were suggested and rejected as part of
: the output report. Too bad.
: 

Really? Which suggestsions were rejected? The list you gave sounded like
the reporting requirements for LADDIS. Admittedly, I didn't make it to the
last SPEC meeting, but all the previous meetings at which LADDIS was discussed,
seemed to follow that thrust for reporting. Then again, having things happen
at SPEC meetings is generally helped by attending. Some vendors don't get
to the meetings. Too bad. Certainly happened the last time I didn't make it
to a meeting.


rick jones
raj@cup.hp.com
HP SPEC Rep for LADDIS
Newsgroups: comp.protocols.nfs