Date: Wed, 07 Oct 1998 14:36:02 +0100 From: Brian Somers <brian@Awfulhak.org> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: current@FreeBSD.ORG Subject: Re: Improper sharing of modem bandwidth Message-ID: <199810071336.OAA01091@woof.lan.awfulhak.org> In-Reply-To: Your message of "Wed, 07 Oct 1998 01:31:46 %2B0930." <Pine.OSF.4.03.9810070120160.32491-100000@mercury.physics.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Recently I've noticed my system behaving differently during downloads; when I
> initiate a file download it tends to consume all available modem bandwidth, to
> the exclusion of all other things like open telnet sessions. Once the download
> has started, my telnet sessions will usually freeze (during a download of a
> 1.5MB file just then over my 14.4k modem I didnt get a single character back
> from one of my telnets open for more than 10 minutes, and another one was
> giving me huge delays (a minute or more, to a host which is ~400ms away under
> normal usage). I could also not manage to talk to the DNS (the modem dialin
> server) to initiate any new connections during the download; the requests were
> timing out.
>
> Until recently, I was not experiencing anywhere near this kind of lag during a
> single file transfer.
The only change in this area lately was a ``fix'' that stops ppp from
reading too many packets from the tun device - in case it ends up not
being able to send them anywhere. Without this fix, it was possible
to feed ppp packets 'till it explodes (ever seen those experiments
with the ``full'' sensor in a flys stomach ?).
Ppp now stops reading packets from the tun device when it's got 20
buffered packets (this number is dynamic in multilink mode) and won't
read any more 'till one of two things happen; either a packet is
successfully sent somewhere, or the ``choked timer'' expires. The
``choked timer'' defaults to 2 minutes.
Once ppp has read a packet, anything that's considered interactive
will skip ahead of non-interactive packets - thus prioritising
interactive traffic.
<disclaimer>
I know very little about tcp
</disclaimer>
I would think that some protocols such as rcp that take full
advantage of TCP sliding windows would have a harmful effect on the
interactive traffic where it didn't previously. If they queue up
(say) 50 packets before waiting for an ACK, ppp will read 20 and
start sending the first. When a telnet (or whatever) session tries
to send a packet, it sits behind the 30 packets that are still queued
in the tun device, and will only get into ppp 30 packets later - it
will then skip to the head of the queue and get sent immediately....
but you've already waited a long time at this point.
If you're interested, you could try doing a ``s/20/100/'' in bundle.c
in src/usr.sbin/ppp and rebuilding & installing ppp. Perhaps the
``20'' is a bit light.
Opinions ?
[.....]
> Kris
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....
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?199810071336.OAA01091>