netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH?] tcp and delayed acks
Date: Wed, 16 Aug 2006 12:11:12 -0700	[thread overview]
Message-ID: <20060816121112.0c181ac3@localhost.localdomain> (raw)
In-Reply-To: <20060816205532.GF9519@kvack.org>

On Wed, 16 Aug 2006 16:55:32 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:

> Hello folks,
> 
> In looking at a few benchmarks (especially netperf) run locally, it seems 
> that tcp is unable to make full use of available CPU cycles as the sender 
> is throttled waiting for ACKs to arrive.  The problem is exacerbated when 
> the sender is using a small send buffer -- running netperf -C -c -- -s 1024 
> show a miserable 420Kbit/s at essentially 0% CPU usage.  Tests over gige 
> are similarly constrained to a mere 96Mbit/s.

What ethernet hardware? The defaults are often not big enough
for full speed on gigabit hardware. I need increase rmem/wmem to allow
for more buffering. 

> Since there is no way for the receiver to know if the sender is being 
> blocked on transmit space, would it not make sense for the receiver to 
> send out any delayed ACKs when it is clear that the receiving process is 
> waiting for more data?  The patch below attempts this (I make no guarantees 
> of its correctness with respect to the rest of the delayed ack code).  One 
> point I'm still contemplating is what to do if the receiver is waiting in 
> poll/select/epoll.

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.

> [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
> 
> from a remote system over gigabit ethernet
> netperf -H woody -C -c
>  87380  16384  16384    10.03       936.23   19.32    20.47    3.382   1.791 
>  87380  16384  16384    10.03       936.27   17.67    20.95    3.091   1.833 
>  87380  16384  16384    10.03       936.17   19.18    20.77    3.356   1.817 
>  87380  16384  16384    10.03       936.26   18.22    20.26    3.188   1.773 
>  87380  16384  16384    10.03       936.26   17.35    20.54    3.036   1.797 
> 
> netperf -H woody -C -c -- -s 1024
>  87380   2048   2048    10.00        95.72   10.04    6.64     17.188  5.683 
>  87380   2048   2048    10.00        95.94   9.47     6.42     16.170  5.478 
>  87380   2048   2048    10.00        96.83   9.62     5.72     16.283  4.840 
>  87380   2048   2048    10.00        95.91   9.58     6.13     16.368  5.236 
>  87380   2048   2048    10.00        95.91   9.58     6.13     16.368  5.236 
> 
> 
> Patched:
> default send buffer size
> netperf -C -c
>  87380  16384  16384    10.01      13923.16   99.90    99.90    0.588   0.588 
>  87380  16384  16384    10.01      13854.59   99.90    99.90    0.591   0.591 
>  87380  16384  16384    10.02      13840.42   99.90    99.90    0.591   0.591 
>  87380  16384  16384    10.01      13810.96   99.90    99.90    0.593   0.593 
>  87380  16384  16384    10.01      13771.27   99.90    99.90    0.594   0.594 
> 
> netperf -C -c -- -s 1024
>  87380   2048   2048    10.02      2473.48   99.90    99.90    3.309   3.309 
>  87380   2048   2048    10.02      2421.46   99.90    99.90    3.380   3.380 
>  87380   2048   2048    10.02      2288.07   99.90    99.90    3.577   3.577 
>  87380   2048   2048    10.02      2405.41   99.90    99.90    3.402   3.402 
>  87380   2048   2048    10.02      2284.41   99.90    99.90    3.582   3.582 
> 
> netperf -H woody -C -c
>  87380  16384  16384    10.04       936.10   23.04    21.60    4.033   1.890 
>  87380  16384  16384    10.03       936.20   18.52    21.06    3.242   1.843 
>  87380  16384  16384    10.03       936.52   17.61    21.05    3.082   1.841 
>  87380  16384  16384    10.03       936.18   18.24    20.73    3.191   1.814 
>  87380  16384  16384    10.03       936.28   18.30    21.04    3.202   1.841 
> 
> netperf -H woody -C -c -- -s 1024
>  87380   2048   2048    10.00       142.46   10.19    7.53     11.714  4.332 
>  87380   2048   2048    10.00       147.28   9.73     7.93     10.829  4.412 
>  87380   2048   2048    10.00       143.37   10.64    6.54     12.161  3.738 
>  87380   2048   2048    10.00       146.41   9.18     7.43     10.277  4.158 
>  87380   2048   2048    10.01       145.58   9.80     7.25     11.032  4.081 
> 
> Comments/thoughts?
> 
> 		-ben

  reply	other threads:[~2006-08-16 21:12 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 [this message]
2006-08-16 21:15   ` David Miller
2006-08-16 21:37   ` Rick Jones
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=20060816121112.0c181ac3@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=bcrl@kvack.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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).