[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <649aecc70801091014u50d1be26ndf5e59e0492ce9cd@mail.gmail.com>
Date: Wed, 9 Jan 2008 13:14:22 -0500
From: "SANGTAE HA" <sangtae.ha@...il.com>
To: "John Heffner" <jheffner@....edu>
Cc: "David Miller" <davem@...emloft.net>, andi@...stfloor.org,
ilpo.jarvinen@...sinki.fi, lachlan.andrew@...il.com,
netdev@...r.kernel.org, quetchen@...tech.edu
Subject: Re: SACK scoreboard
On Jan 9, 2008 9:56 AM, John Heffner <jheffner@....edu> wrote:
> >> I also wonder how much of a problem this is (for now, with window sizes
> >> of order 10000 packets. My understanding is that the biggest problems
> >> arise from O(N^2) time for recovery because every ack was expensive.
> >> Have current tests shown the final ack to be a major source of problems?
> >
> > Yes, several people have reported this.
>
> I may have missed some of this. Does anyone have a link to some recent
> data?
I had some testing on this a month ago.
A small set of recent results with linux 2.6.23.9 are at
http://netsrv.csc.ncsu.edu/net-2.6.23.9/sack_efficiency
One of serious cases with a large number of packet losses (initial
loss is around 8000 packets) is at
http://netsrv.csc.ncsu.edu/net-2.6.23.9/sack_efficiency/600--TCP-TCP-NONE--400-3-1.0--1000-120-0-0-1-1-5-500--1.0-0.5-133000-73-3000000-0.93-150--3/
Also, there is a comparison among three Linux kernels (2.6.13,
2.6.18-rc4, 2.6.20.3) at
http://netsrv.csc.ncsu.edu/wiki/index.php/Efficiency_of_SACK_processing
Sangtae
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists