Date: Fri, 14 Feb 2003 09:36:30 -0800 From: Gianluca Iannaccone <gianluca@sprintlabs.com> To: "'freebsd-ipfw@freebsd.org'" <freebsd-ipfw@freebsd.org> Subject: FW: Is the RED implementation correct? Message-ID: <49D9473417F1234C9C86886EE8353FAA0650F8@mailman.sprintlabs.com>
next in thread | raw e-mail | index | archive | help
sorry but it seems that this one didn't make it through the first time. -gianluca -----Original Message----- From: Gianluca Iannaccone Sent: Sunday, February 09, 2003 12:37 PM To: 'Peter.Ewert@ewetel.de'; freebsd-ipfw@FreeBSD.ORG Subject: RE: Is the RED implementation correct? peter, > I would have expected something like: > > weight = 1 - w_q; > for (t = (int)(3. / (w_q*lookup_depth)); t > 0; --t) > weight *= (1 - w_q); > pipe.fs.lookup_weight = (int)(weight * (1 << SCALE_RED)); > > which calculates weight as 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. on the other hand, according to the specs the 'weight *= weight' should be as you say 'weight *= (1 - w_q)'. > 2) > The line > s = clock.hz * avg_pkt_size * 8 / pipe.bandwidth; > in ipfw.c/ipfw2.c > should give a "better" accuracy for s using floating point division: > s = clock.hz * avg_pkt_size * 8 / (double)pipe.bandwidth; this part of the RED specs is inherently inaccurate, so i don't think having s more accurate would make any difference. however, i don't see any harm in using floating point division here. > > 3) > In ip_dummynet.c: > I think in > q->avg=(t < fs->lookup_depth) ? > SCALE_MUL(q->avg,fs->w_q_lookup[t]) : 0; > > the 32Bit multiply overflows. Using > SCALE_MUL((int64_t) q->avg, (int64_t)(fs->w_q_lookup[t])) > should solve the problem. yes, SCALE_MUL should always be done on 64bits. indeed in the RED code all the SCALE_MUL operations use 64 bits but this one... thanks, gianluca ---------------------------------------------------------- Gianluca Iannaccone ' gianluca@sprintlabs.com Sprint ATL ' tel +1 (650) 375-4198 1 Adrian Court ' fax +1 (650) 375-4079 Burlingame, CA 94010 ' www.sprintlabs.com/people/gianluca 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?49D9473417F1234C9C86886EE8353FAA0650F8>