Date: Sat, 24 Oct 1998 23:03:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kkennawa@physics.adelaide.edu.au (Kris Kennaway) Cc: brian@awfulhak.org, current@FreeBSD.ORG Subject: Re: Improper sharing of modem bandwidth Message-ID: <199810242303.QAA28873@usr01.primenet.com> In-Reply-To: <Pine.OSF.4.05.9810250042340.197-100000@mercury.physics.adelaide.edu.au> from "Kris Kennaway" at Oct 25, 98 00:43:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Making the suggested change from 20 to 100 in bundle.c didnt seem to have > a noticeable effect; to recap my problem, if I start up a binary transfer > which runs at full throttle (~1.65k/s on my 14.4k modem, usually), then it > starves all other network connections to the point of exclusion. I've done > some more checking and perhaps some of this will be helpful. > > If I ^Z the ftp (or http, or whatever the binary transfer is that's > hogging the modem) process, the modem continues to transfer for ~11 > seconds (~18k) before coming to a stop; immediately thereafter my other > network sessions (telnet, ping, etc) "unfreeze" and I get normal > performance from them. Restarting the FTP transfer immediately excludes > everything else again. > > If I start a ping of a host which is ~400ms away at normal usage, > restarting the FTP transfer will cause no further packets to be returned. I assume (by the http reference) that this is a transfer *to* your machine, instead of a transfer *from* your machine? It appears to me that the problem is that your ISP's buffers for your port are about 16k, and that data in transit from the remote host is monopolizing them. There are two remedies that are immediately obvious; one is to use Julian Elisher's version of the bandwidth control code, and the other is to set a smaller MTU and end-to-end window size, and then delay FTP ACK's. In any case, it appears that the problem is that there is no remaining buffer space for inbound (to you) packets at the ISP, and that controlling the monopolization of that space by FTP data is the only remedy that will work to resolve your problem. That's actually best done by the ISP by setting port/priority bands for various protocols, with emphasis placed on protocols most likely to have a human on the other end of them. This means that HTTP would probably still be capable of knocking you out, and that FTP in a URL in a browser would be unexpectedly slow, but at least your telnet would be more responsive (your ping does not establish a virtual circuit, so it can't reserve bandwidth). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810242303.QAA28873>