home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / nfs / 2276 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  1.4 KB
  1. Xref: sparky comp.protocols.nfs:2276 comp.protocols.tcp-ip:4356
  2. Path: sparky!uunet!gatech!purdue!yuma!csn!news.den.mmc.com!pgl-devsvr.den.mmc.com!jzwiebel
  3. From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel (303)977-1480)
  4. Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip
  5. Subject: Re: NFS Over Satellite Link
  6. Message-ID: <1992Sep9.152948.17119@den.mmc.com>
  7. Date: 9 Sep 92 15:29:48 GMT
  8. References: <1992Sep9.121006.14055@udel.edu>
  9. Sender: news@den.mmc.com (News)
  10. Organization: PAGE @ Martin-Marietta
  11. Lines: 14
  12.  
  13. In article <1992Sep9.121006.14055@udel.edu>, pahountis@ncf.al.alcoa.com (Julia Pahountis) writes:
  14. |> Has anyone, or do you know of anyone, who has done NFS over a satellite link?  (Can it be done?)
  15.  
  16. Haven't done it but I think the turn around time to a geostationary satellite
  17. would be a major problem since its up there at 24,000 miles.  Multiply that 
  18. times 4 to include all your links and you start approaching the RPC time out.
  19. You'd have to increase the number of biods on the clients and nfsd on the 
  20. servers to increase "window" size (the number of outstanding nfs requests)
  21. and have to increase the default timeout for retransmission to avoid too many
  22. repeat requests on your links.  Both of these cause a decrease in NFS
  23. performance on a "normal" NFS path.  (Too many nfsd waste CPU cycles on the
  24. server, too many biods does the same thing on the client)
  25.  
  26. John Zwiebel
  27.