From: Olof Johansson <olof@austin.ibm.com>
To: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>
Cc: trond.myklebust@fys.uio.no, nfs@lists.sourceforge.net
Subject: Re: [PATCH] SVC sockets don't disable Nagle
Date: Tue, 29 Apr 2003 19:07:21 -0500 [thread overview]
Message-ID: <3EAF13B9.8040402@austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304300029360.8473-100000@kenzo.iwr.uni-heidelberg.de>
Bogdan Costescu wrote:
> On Tue, 29 Apr 2003, Olof Johansson wrote:
>
>>Below patch disables it on the server side as well. For latency reasons,
>>this should be the desired behaviour NFS at both client and server.
>
>
> I disagree with this general statement. Nagle is there in the TCP protocol
> for a specific reason and enabling or disabling it gives the opportunity
> to better tune the connection.
Yes, Nagle is there to reduce overhead by aggregating data into segments
and piggybacking them with ACKs. Most significant differences will be
when dealing with a steady but slow pace of characters, say text being
typed over a 9600bps serial line.
> It seems like disabling Nagle is the bolierplate answer for anyone who
> encounters GigEth or better networking simply because the TCP protocol was
> not designed for such fast networks. But what happens to others that do
> not have GigEth ? What is the impact of this change for a slower/congested
> network ?
There is a chance that small requests and replies (~100 bytes) will not
be aggregated into the same segments but instead sent out separately. In
essence, this will result in some additional network overhead due to
headers, but the response times will be perceived as faster even for
slower networks.
Since NFS traffic is bursty, it is unlikely that any individual request
or reply will be split up between two segments when it didn't need to.
> If anything, I would like to see this as a per-mount-point and
> per-export-entry option...
I think it would just clutter the documentation and list of options,
since I don't forsee any practical scenarios in which anyone would have
a positive performance impact from having Nagle enabled.
On a side note: As far as I know, most (all?) other NFS implementations
out there already disable Nagle.
-Olof
--
Olof Johansson Office: 4E002/905
pSeries Linux Development IBM Systems Group
Email: olof@austin.ibm.com Phone: 512-838-9858
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-04-30 0:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-29 22:03 [PATCH] SVC sockets don't disable Nagle Olof Johansson
2003-04-29 22:42 ` Bogdan Costescu
2003-04-30 0:07 ` Olof Johansson [this message]
2003-04-30 12:06 ` Bogdan Costescu
2003-04-30 12:45 ` Trond Myklebust
2003-04-30 14:58 ` Olof Johansson
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=3EAF13B9.8040402@austin.ibm.com \
--to=olof@austin.ibm.com \
--cc=bogdan.costescu@iwr.uni-heidelberg.de \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.