From owner-freebsd-current Tue Feb 17 17:38:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13585 for freebsd-current-outgoing; Tue, 17 Feb 1998 17:38:03 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13443 for ; Tue, 17 Feb 1998 17:37:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id BAA20152; Wed, 18 Feb 1998 01:32:35 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA20147; Wed, 18 Feb 1998 02:32:35 +0100 (MET) Message-ID: <19980218023234.65072@follo.net> Date: Wed, 18 Feb 1998 02:32:34 +0100 From: Eivind Eklund To: Brian Somers , Luigi Rizzo Cc: Eivind Eklund , plm@xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/ppp command.c datalink.c datalink.h defs.h vars.c vars.h References: <199802172010.VAA01212@labinfo.iet.unipi.it> <199802180108.BAA24538@awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199802180108.BAA24538@awfulhak.org>; from Brian Somers on Wed, Feb 18, 1998 at 01:08:30AM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 18, 1998 at 01:08:30AM +0000, Brian Somers wrote: > At the moment, ppp has four queues. Two IP queues and two modem > queues. The IP queues are `interactive' and `normal', and the modem > queues are `fast' and `normal'. LCP and `interactive IP' traffic > goes into the `fast' modem queue. `fast' data gets delivered first. > > Wouldn't this be best approached by just having a dynamic MTU - one > that varies based on the number of packets in the interactive queue ? The basic idea is sound, but it's the wrong variation parameter. You should vary it based on what number of packets there has been in the interactive queue recently - what is there right now isn't a good enough heuristic. An OK heuristic might e.g. be n_heuristic = C*n_heuristic + length_of_interactive_queue*(1-C) re-evaluated for every packet sent out, with C a constant < 1. I'd guess C should be somewhere between 0.9 and 0.99 to get both crispy feel while working interactively and quick transfers when not working interactively anymore, but this depend a bit on how much fragmenetation is done. The basic point is that you keep a logithmic, never-disappearing memory of all prior events. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message