remaker@icarus.amd.com (Phillip Remaker) (01/30/91)
Greetings! Bureaucrats and other network illiterate types are demanding to run NFS traffic over a T1 between campuses (about a 6 mile run). This link is already congested with LAT, LAST, FTP, and DECENT traffic. Well, not really congested, about 10-20% utilized. Since NFS is UDP based, I *know* that it is not a "good idea" to run it over low bandwidth lines, but I need references, testimonials, etc. so that I can present my case without having to "burn to learn." Also, if there are ways to sanely do NFS over slow links, I am interested. Kernel mods, secrets, tweaks, black art, all welcomed. Another alternatibe is to install a >= 10 Mbit link in the form of T3 or dedicated fiber/microwave. The distance is about 6-7 miles. We have bandwidth now, but will latency then be an issue? We are using cisco routers on both ends of the link, so there is more delay. I am under the impression that NFS is for machines only in geographically close proximity. Correct me if I am wrong. All tips, pointers, hints, flames, tweaks, twiddles, and frobs welcome. I will post a summary if there is sufficient interest. -- Phillip A. Remaker A.M.D. M/S 167 P.O. Box 3453 Sunnyvale, CA 94088-3000 TCP/IP internetworking from hell. DoD #185 remaker@amd.com 408-749-2552 Things to do today: 1) Get a clue. 2) Get a job. 3) Get a life.
thurlow@convex.com (Robert Thurlow) (01/30/91)
In <1991Jan30.023832.24723@amd.com> remaker@icarus.amd.com (Phillip Remaker) writes: >Since NFS is UDP based, I *know* that it is not a "good idea" to run >it over low bandwidth lines, but I need references, testimonials, etc. so >that I can present my case without having to "burn to learn." The numbers shown at USENIX by a speaker from the University of Guelph in Ontario, Canada showed that unmodified NFS over UDP would manage about a quarter the throughput of TCP over a 56Kbit line. Your losses should be less severe, but you'll still have pretty awful performance. Bandwidth is also less important than latency a lot of the time; I some of our servers in-house get beaten to death because of duplicate requests. >Also, if there are ways to sanely do NFS over slow links, I am >interested. Kernel mods, secrets, tweaks, black art, all welcomed. That's easy to hand-wave about. There are mods to make at the client and at the server end that really make a difference. First, the client should keep a record of how long each operation from each server takes, and adjust its retransmission timeouts based on that delay. Doing this right keeps the line clear of retransmission traffic and lets the server do more real work. On the server side, the NFS dispatch routine should keep track of duplicate requests and either send back cached responses or drop the duplicates for a finite amount of time. My feeling is that caching the replies is unnecessary since a lot of the retransmissions are due to client impatience and UDP socket buffer overflows on busy servers, not due to lost replies. With just a smart client implementation, the USENIX speaker (damnit, I wish I had my proceedings here!) got UDP performing better than TCP due to lighter computation overhead on his Microvax II. >I will post a summary if there is sufficient interest. Please do. I think a lot of people are playing with these issues; I know I hope to test this exact code at Connectathon this year. Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu "The Canadian rock singer, Ronnie Hawkins, has it all figured out. 'Believe in God?' he says, "Man, I believe in God like nobody else. It's the fucking ground crew I don't trust." - "Running Risks", Angela Issajenko