On Wed, Aug 16, 2006 at 12:11:12PM -0700, Stephen Hemminger wrote:
> > 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.
This is for small buffer transmit buffer sizes over either loopback or
e1000. The artifact also shows up over localhost for somewhat larger buffer
sizes, although it is much more difficult to get results that don't have
large fluctuations because of other scheduling issues. Pinning the tasks to
CPUs is on my list of things to try, but something in the multiple variants
of sched_setaffinity() has resulted in it being broken in netperf.
> 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.
I would like to see what sort of effect this change has on higher latency.
Ideally, quick ack mode should be doing the right thing, but it might need
more input about the receiver's intent.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[EMAIL PROTECTED]>.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
