Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Dec 2004 16:24:52 -0600
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Uwe Doering <gemini@geminix.org>
Cc:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   Re: kern/75122: [PATCH] Incorrect inflight bandwidth calculation on first packet
Message-ID:  <20041222222452.GD36639@dan.emsphone.com>
In-Reply-To: <41C806FC.7080500@geminix.org>
References:  <200412151827.iBFIRqDB019997@dan.emsphone.com> <200412151830.iBFIUVwE052799@freefall.freebsd.org> <20041216190608.GA21382@dan.emsphone.com> <41C41DEA.9000504@geminix.org> <20041221065531.GA78451@dan.emsphone.com> <41C7F1D6.7020108@geminix.org> <41C806FC.7080500@geminix.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Dec 21), Uwe Doering said:
> Uwe Doering wrote:
> >Dan Nelson wrote:
> >>In the last episode (Dec 18), Uwe Doering said:
> >>>Dan Nelson wrote:
> >>>
> >>>>Updated patch including Matt's recommended fix:
> >>>>
> >>>>+    /*
> >>>>+     * Sanity check, plus ignore pure window update acks.
> >>>>+     */
> >>>>+    if ((int)(ack_seq - tp->t_bw_rtseq) <= 0)
> >>>>+        return;
>
> On second thought, checking for less than zero (by means of the 'int' 
> cast) might have its merits.  This may be a protection against 
> out-of-order ACKs, which could in fact be valid, but calculating a byte 
> count from an ACK for an earlier packet when we've already processed a 
> later ACK would be bogus.

I am pretty sure only useful acks get to this point.  I've changed that
bit of code to just be

+       /*
+        * Ignore pure window update acks.
+        */
+       if (ack_seq == tp->t_bw_rtseq)
+               return;

and added another check for negative sequences that increments a sysctl
counter.  So far netstat -s has counted 567 out-of-order packets but my
counter is still at 0.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041222222452.GD36639>