g the packets as a lower priority task, just
doing it after they're acknowledged.
When the ACK finally comes, you could do something like moving John's
entire list of packets to a "to be freed" list, and free a few every
time (say) another ACK comes in.
$0.02,
Lachlan
--
Lach
Greetings Dave,
On 12/12/2007, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Lachlan Andrew" <[EMAIL PROTECTED]>
> Date: Tue, 11 Dec 2007 16:14:36 -0800
>
> > This thread started because TCP processing interferes with RTT
> > estimation. This proble
started because TCP processing interferes with RTT
estimation. This problem would be eliminated if time-stamping were
done as soon as the packet comes off the NIC.
$0.02
Lachlan
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125,
Greetings Ilpo,
On 04/12/2007, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2007, Lachlan Andrew wrote:
> >
> > When SACK is active, the per-packet processing becomes more involved,
> > tracking the list of lost/SACKed packets. This causes a CPU spike
&
er a loss, which increases the RTTs, at least in my
experience. This is a separate issue from the fact that it is hard to
get RTT measurements from lost/retransmitted packets themselves.
Cheers,
Lachlan
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasa
nd H-TCP?
> >
> > Thanks for the help!
> > -Shao
> >
> >
> >
> > -Original Message-
> > From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 28, 2007 4:44 PM
> > To: Lachlan Andrew
> > Cc: David
ave a heuristic "RTT aging" mechanism, but
that's pretty ugly.
Cheers,
Lachlan
On 28/11/2007, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Lachlan Andrew observed that my TCP-Illinois implementation uses the
> beta value incorrectly:
> The parameter beta in the pap
ed flows to understand what is happening
vs a range of flows to test suitability for deployment), and the
benefits of repeating other people's tests vs testing in as many
scenarios as possible.
Who is interested in coming?
Cheers,
Lachlan
--
Lachlan Andrew Dept of Computer Science, Caltech
1
ose
checking that condition explicitly, as in the attached patch,
reproduced below, relative to 2.6.15.3.
I welcome people's comments on this suggestion.
Cheers,
Lachlan Andrew, FAST TCP developer.
--- net/ipv4/tcp_output.c.orig 2006-03-07 17:18:09.0 -0800
+++ net/ipv4/tcp_output.c
