[Top] [All Lists]

Re: your mail

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: your mail
From: Matt Sottile <matt@xxxxxxxx>
Date: Tue, 5 Feb 2002 14:00:17 -0700 (MST)
Cc: Ronald G Minnich <rminnich@xxxxxxxx>, <kuznet@xxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>, <nivedita@xxxxxxxxxxx>, <hendriks@xxxxxxxx>
In-reply-to: <>
Sender: owner-netdev@xxxxxxxxxxx
Ron should be sending the TCP dump along soon.  For your information, the
application we're encountering this problem with is one where we are
sending data periodically across the network at the highest possible rate
-- a client sends a request to a server, the server responds with a
result.  This we call a "sample" -- now, we want to get as many samples as
we can in one second.  Now, we know we can poll the data source that we're
getting the data from inside a single box at ~3.5 Khz (~3500
samples/second).  Now, as soon as we move from a single box to a two box
sampling across the network,  we immediately hit a ceiling of 25Hz...
Amazingly enough, if you dive into the 2.4 kernel sources and find the
delayed ack code, we notice that some brilliant programmer decided the
delay is related to.... HZ/25.  Now, taking that into account and looking
at the tcpdump that Ron will shortly pass along, we have lots of reason to
believe that this delay stuff is limiting our sampling rates across the

(Now be patient and don't tell me that I'm imagining things until you get
Ron's tcpdump data...)


On Tue, 5 Feb 2002, Andi Kleen wrote:

> On Tue, Feb 05, 2002 at 01:36:22PM -0700, Ronald G Minnich wrote:
> > On Tue, 5 Feb 2002, Andi Kleen wrote:
> >
> > > I also have a hard time to see how delayed acks should introduce user
> > > visible delays (assuming your send/receive buffers are big enough)
> >
> > I know. That's the whole problem. People have a hard time seeing
> > something, so they deny its existence.
> When you claim something that fails the sanity checks of several other
> people and you blame Linux it is your duty to provide evidence for it.
> In TCP world the standard evidence is a tcpdump. tcpdumps don't lie.
> Without a tcpdump we can as well assume that the problem doesn't exist.
> -Andi

 Matt Sottile                    |  Phone:  1 (505) 665-6057
 CCS-1 : Advanced Computing      |  Email:  matt@xxxxxxxx
 MS B287                         |
 Los Alamos National Laboratory  |  If you're not part of the solution,
 Los Alamos, NM 87545            |  you're part of the precipitate.

<Prev in Thread] Current Thread [Next in Thread>