From owner-freebsd-ipfw Sat Feb 15 7: 7:37 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B304837B401 for ; Sat, 15 Feb 2003 07:07:35 -0800 (PST) Received: from mail1.ewetel.de (mail1.ewetel.de [212.6.122.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46ED943FB1 for ; Sat, 15 Feb 2003 07:07:34 -0800 (PST) (envelope-from Peter.Ewert@ewetel.de) Received: from ewetel.de (dynadsl-080-228-67-233.ewetel.net [80.228.67.233]) by mail1.ewetel.de (8.12.1/8.12.1) with ESMTP id h1FF7TGF024355 for ; Sat, 15 Feb 2003 16:07:30 +0100 (MET) Message-ID: <3E4E57A6.7050403@ewetel.de> Date: Sat, 15 Feb 2003 16:07:18 +0100 From: Peter Ewert Reply-To: Peter.Ewert@ewetel.de User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Is the RED implementation correct? References: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com> In-Reply-To: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CheckCompat: OK Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Im sorry answering so late. ... >>weight=(1-w_q)^(3/(w_q*lookup_depth)). >>This would make more sense to me as weight should not depend >>on s (ticks for sending medium-sized packet). > > i don't think that removing the dependency on the ticks needed to send > a medium size packet is correct. the idea here is that when the queue > becomes empty you need to decide for how long your average queue size > is a valid estimator of the congestion on the link. > > thus, you want to have that slow links have much more "memory" of > previous congestion phases when compared to fast links. that's why you > need to keep some notion of link speed in the weights. My idea was that the lookuptable always should look the same. It is used this way: new_avg = avg * w_q_lookup[(Nr. of Packets which could have been transfered)] The implementation in ip_dummynet.c: u_int t = (curr_time - q->q_time) / fs->lookup_step; ... if (t < fs->lookup_depth){ q->avg = SCALE_MUL((int64_t) q->avg, (int64_t)(fs->w_q_lookup[t])); } else { q->avg = 0; } The "memory" is always the same in respect to the speed of the link. Its true that it is "bigger" in meanings of ticks but this doesnt matter because the idle time is normalized by the step size (fs->lookup_step). I think this is the dependency you meant. >>2) ... >>3) ... Regards, Peter Ewert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message