Date: Fri, 23 Jan 2009 11:21:14 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Oleg Bulyzhin <oleg@FreeBSD.org> Cc: stable@FreeBSD.org, re@FreeBSD.org Subject: Re: backporting dummynet's q_time change ? (svn 184414) Message-ID: <20090123102114.GA42867@onelab2.iet.unipi.it> In-Reply-To: <20090123094420.GC54838@lath.rinet.ru> References: <20090123081028.GA38763@onelab2.iet.unipi.it> <20090123085337.GB54838@lath.rinet.ru> <20090123092312.GC40642@onelab2.iet.unipi.it> <20090123094420.GC54838@lath.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 23, 2009 at 12:44:20PM +0300, Oleg Bulyzhin wrote: > On Fri, Jan 23, 2009 at 10:23:12AM +0100, Luigi Rizzo wrote: > > > this is also in RELENG_7 but i am not sure whether this workaround > > has any drawback e.g., when curr_time passes a 32-bit boundary > > there seems to be an incorrect setting of q->numbytes > > Workaround is fine in average. It may fail for: > 1) _very_ idle flow (more than 2^32 ticks) while calculating q->avg > 2) any flow once per 2^32 ticks > then q_time will be updated and things will be ok again. understand - my question is whether there is strong objection in applying the real fix (the one in HEAD) rather than this workaround. In my opinion the MFC is quite safe as I explained. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090123102114.GA42867>