home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.aix:11509 comp.protocols.nfs:2755
- Newsgroups: comp.unix.aix,comp.protocols.nfs
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sgigate!sgi!rhyolite!vjs
- From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
- Subject: Re: UDP Checksum on NFS in AIX 3.2?
- Message-ID: <s8k5lao@rhyolite.wpd.sgi.com>
- Keywords: NFS udp checksum
- Organization: Silicon Graphics, Inc. Mountain View, CA
- References: <BxKvzC.5p9@well.sf.ca.us>
- Date: Thu, 12 Nov 1992 04:17:45 GMT
- Lines: 32
-
- In article <BxKvzC.5p9@well.sf.ca.us>, nlane@well.sf.ca.us (Nathan D. Lane) writes:
- >I am attempting to run NFS over a slip link on AIX 3.2.2 at 19.2K. Now, I know
- >that slip is no way to run NFS, but I am conducting reliability and feasibility
- >tests for the VERY occassional use of this access method. ...
-
-
- On the contrary. NFS over SLIP over v.32bis/v.42/v.42bis works fine
- and frequently for me, and at the tail of a 1200 mile 56K link, which
- is in turn hooked to a chain of ethernets and FDDI rings. Many hops.
-
- It's not as fast as over FDDI, but what do you expect?
-
- > I am using mount -o rsize=512,wsize=512 to keep the bandwidth of the line
- > conserved as much as possible. ...
-
- Each to their own. I prefer a block size 4096, but I also use a SLIP
- implemenation that does a TOS hack of moving small packets to the front
- to minimize the harm done to simultaneous rlogin's. I prefer bigger
- blocks to conserve bandwidth, since a small rsize implies more UDP and
- (much, much worse) RPC-XDR headers per byte of data. I don't use 8192
- or larger, because losing a single IP fragment means waiting for a long
- NFS timeout and then retransmitting the whole thing. At 1.6-3.4KByte/sec,
- a retransmission takes a while.
-
-
- Of course, I only use NFS between machines that are shipped with UDP
- checksums on by default. If you don't have that luxury, then you might
- hack your own version of slip to add a checksum of the packet. It's
- not a big deal, at least with some systems.
-
-
- Vernon Schryver, vjs@sgi.com
-