On Tue, May 16, 2006 at 02:21:27AM +0200, Patrick McHardy wrote:
> David S. Miller wrote:
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 16:41:01 -0700
> >
> >
> >>kfree_skb(NULL) is legal so the conditional here is unneeded.
> >>
> >>But the increased calls to kfree_s
On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> congestion avoidance code additions and changes. I was wondering if
> there are any tools folks can recommend for testing the kernel to make
> sure the congestion avoidan
On Tue, 2006-01-10 at 16:09 +0100, Tarjan Peter wrote:
> Hello,
>
> We have done some measurements on kernel v2.6.14.2 and v2.6.15 with TCP
> Vegas. It seems that Vegas implementation in v2.6.15 is broken: it stops
> increasing congestion window after reaching a certain limit. For example
> in
On Tue, 2006-01-03 at 21:22 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Wed, 04 Jan 2006 14:23:47 +1100
>
> > Vegas' slow start was only adding one MSS per RTT rather than one for
> > every ack. Slow start behavior should now ma
Vegas' slow start was only adding one MSS per RTT rather than one for
every ack. Slow start behavior should now match Reno.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
net/ipv4/tcp_vegas.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
aa4db8a59aede2955461910e1516826fd8
On Tue, 2005-12-06 at 17:04 -0800, David S. Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Tue, 6 Dec 2005 10:52:09 -0800
>
> > Fixing Vegas was on my TODO list, thanks for attacking it.
> > It never really worked well.
>
> Indeed, thanks a lot Tom.
>
> I've integrated the t
On Mon, 2005-12-05 at 21:43 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Tue, 06 Dec 2005 15:40:57 +1100
>
> > Remove unneeded call to tcp_vegas_rtt_calc. The more accurate
> > microsecond value has already been registered prior to calli
On Mon, 2005-12-05 at 21:40 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Tue, 06 Dec 2005 15:38:39 +1100
>
> > Do timestamping before cloneing.
> > This fixes the bug where the timestamp was performed in tcp_transmit_skb
> > on
Remove unneeded call to tcp_vegas_rtt_calc. The more accurate
microsecond value has already been registered prior to calling
tcp_vegas_cong_avoid.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4
Move the resetting of rtt measurements to inside the once per RTT block
of
code.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -333,11 +333,11 @@ static void tcp_vegas_cong_avoi
Do timestamping before cloneing.
This fixes the bug where the timestamp was performed in tcp_transmit_skb
on
the cloned skb leading to the timestamp being lost.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output
Vegas RTT measurement currently seems quite broken.
I've identified three issues.
1) The reseting the rtt stats is for every call to cong_avoid rather
than at the end of the rtt.
2) Also, timestamping is being performed after the skb clone, leading
to non-sensical RTT estimates. The patch below
On Mon, 2005-11-07 at 16:16 -0800, David S. Miller wrote:
> TCP ends up setting it to 1 but other protocols do not.
>
> But other protocols use ip_queue_xmit() as well, such as DCCP
> and SCTP, and they won't change it from it's alloc_skb() time
> value of "0".
Thanks for clearing that up, I see
On Mon, 2005-11-07 at 10:01 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Mon, 07 Nov 2005 15:59:49 +1100
>
> > The socket ip id currently gets incremented by 1 + the number of
> > segments leading to an increment of 2 in the standard n
I'm resubmitting this as I think while its effect is minimal in most
cases, it does still fix a bug. The current implemenation effectly halfs
the ip id space because of the off by one error. This could lead to
problems on LFNs.
The socket ip id currently gets incremented by 1 + the number of
seg
15 matches
Mail list logo
