This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: TCP/IP write() buffering question
On Thu, Sep 21, 2000 at 03:42:14PM +0200, Andrew Lunn wrote:
> > It looks like the delays between successive write() calls (a
> > few tens of milliseconds) is long enough that the stack is
> > shoving data out in small chunks. I need to spend some more
> > time trying to profile the server and figuring out where the
> > delays are coming from.
>
> Whats on the other end? Linux? NT? IE, Netscape, Lynx?
Linux (RH 6.2) Netscape 4.something. I don't think I've ever
re-compiled the kernel on this machine, so it's a vanilla Intel
RH system (kernel is 2.2.14-6.1.1).
Behavior is same with lynx and w3m.
> If you are not using TCP_NODELAY, the Nagle algorithm should be
> enabled. If TCP trys to send a packet which is smaller than the MSS,
> normal about 1Kbytes, it will delay the packet and try to clump it
> together. It will send the small packet when it gets an ACK from the
> other end. Now the other end should be doing delayed ACKs.
That's what I thought. I noticed the non-delayed ACKs once
before when debugging something else. I thought it odd at the
time, but didn't look into it any further.
> It should not send the ACK for between 50-200ms.
In the tcpdump trace The ACKs from the Linux box (traced from
that same Linux box) show up 10-20ms after each packet from the
eCos board. There is generally around 16-17ms between the data
packet and the ACK.
[Pauses to try IE5 under NT]
NT delays ACKs the way I expect. This results in about 15
packets instead of 50, but the load still takes 2 seconds.
Apparently, the GoAhead JavaScript interpreter is _really_ slow.
> So if your server is taking tens of milliseconds it should be
> able to generate a number of writes before the ACK comes back.
> This is strange.
Yup.
--
Grant Edwards
grante@visi.com