netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 :(



  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).