From: Rick Jones <rick.jones2@hp.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH?] tcp and delayed acks
Date: Wed, 16 Aug 2006 14:37:00 -0700 [thread overview]
Message-ID: <44E38FFC.6000108@hp.com> (raw)
In-Reply-To: <20060816121112.0c181ac3@localhost.localdomain>
> The point of delayed ack's was to merge the response and the ack on request/response
> protocols like NFS or telnet. It does make sense to get it out sooner though.
Well, to a point at least - I wouldn't go so far as to suggest immediate
ACKs.
However, I was always under the impression that ACKs were sent (in the
mythical generic TCP stack) when:
a) there was data going the other way
b) there was a window update going the other way
c) the standalone ACK timer expired.
Does this patch then implement b? Were there perhaps "holes" in the
logic when things were smaller than the MTU/MSS? (-v 2 on the netperf
command line should show what the MSS was for the connection)
rick jones
BTW, many points scored for including CPU utilization and service demand
figures with the netperf output :)
>
>
>>[All tests run with maxcpus=1 on a 2.67GHz Woodcrest system.]
>>
>>Recv Send Send Utilization Service Demand
>>Socket Socket Message Elapsed Send Recv Send Recv
>>Size Size Size Time Throughput local remote local remote
>>bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>>
>>Base (2.6.17-rc4):
>>default send buffer size
>>netperf -C -c
>> 87380 16384 16384 10.02 14127.79 99.90 99.90 0.579 0.579
>> 87380 16384 16384 10.02 13875.28 99.90 99.90 0.590 0.590
>> 87380 16384 16384 10.01 13777.25 99.90 99.90 0.594 0.594
>> 87380 16384 16384 10.02 13796.31 99.90 99.90 0.593 0.593
>> 87380 16384 16384 10.01 13801.97 99.90 99.90 0.593 0.593
>>
>>netperf -C -c -- -s 1024
>> 87380 2048 2048 10.02 0.43 -0.04 -0.04 -7.105 -7.377
>> 87380 2048 2048 10.02 0.43 -0.01 -0.01 -2.337 -2.620
>> 87380 2048 2048 10.02 0.43 -0.03 -0.03 -5.683 -5.940
>> 87380 2048 2048 10.02 0.43 -0.05 -0.05 -9.373 -9.625
>> 87380 2048 2048 10.02 0.43 -0.05 -0.05 -9.373 -9.625
Hmm, those CPU numbers don't look right. I guess there must still be
some holes in the procstat CPU method code in netperf :(
next prev parent reply other threads:[~2006-08-16 21:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-16 20:55 [PATCH?] tcp and delayed acks Benjamin LaHaise
2006-08-16 19:11 ` Stephen Hemminger
2006-08-16 21:15 ` David Miller
2006-08-16 21:37 ` Rick Jones [this message]
2006-08-16 21:41 ` Benjamin LaHaise
2006-08-16 22:39 ` Alexey Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44E38FFC.6000108@hp.com \
--to=rick.jones2@hp.com \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).