Date: Sat, 15 Feb 2003 16:07:18 +0100 From: Peter Ewert <Peter.Ewert@ewetel.de> To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Is the RED implementation correct? Message-ID: <3E4E57A6.7050403@ewetel.de> In-Reply-To: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com> References: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4E57A6.7050403>